URLs containing no host and a path starting with ./ or ../ are not serialized idempotently

[jdm]

Parsing a url like scheme:/.//path internally removes the ./ in the serialization (per the spec), so parsing the serialized URL of scheme://path yields a URL that is parsed differently than the original one (ie. path is treated as a host now, instead of part of the URL's path).

Cases to consider:

• scheme:/.//path
• scheme:/..//path
• scheme:/./..//path (any leading mixed collection of ./ and ../)

My reading of the spec is that this might be a shortcoming that needs to be addressed there, rather than just an implementation bug. I can envision a couple possible solutions:

• don't truncate ./ or ../ if it's the first component of a path, avoiding the issue entirely
• truncate / when the previous segment is empty (resulting in scheme:/path)

[SimonSapin]

Should this be filed in https://github.com/whatwg/url/issues ?

[jdm]

Maybe! I haven't spent a lot of time verifying that the spec doesn't handle it yet.

[dan-da]

possibly related: I am noticing today that "../" are normalized in (to me) a strange way, ie:

http://host/somedir/../file.txt   --->  /file.txt         (ok)
http://host/somedir/../../file.txt   --->  /file.txt         (seems wrong)
http://host/somedir/../../../file.txt   --->  /file.txt         (seems wrong)
http://host/../../../file.txt   --->  /file.txt         (seems wrong)
http://host/../file.txt   --->  /file.txt         (seems wrong)

I haven't checked the spec, maybe this is correct behavior. Personally I would expect a parse error for the "seems wrong" cases.

edit: I checked the spec. The behavior appears "correct".

I am wanting/needing a way to access the "raw" path without any such normalization. Filed #602

[valenting]

Probably a dupe of #459

Anne pointed me to whatwg/url#505

[djc]

whatwg/url#505 just landed, tests in web-platform-tests/wpt#25113. @valenting has some patches in https://github.com/valenting/rust-url/tree/non-special-idempotent -- I will see about rebasing these onto current master.

[djc]

I've pulled in the new tests and rebased @valenting's patch on top of current master. Unfortunately the patch increases the number of failed tests by 1 rather than improving the situation, so this will still need some more work.

Draft PR here: #629. Any help is appreciated!

[qsantos]

I think this is the same thing as #799, which was resolved by #817

[valenting]

Yes, thank you @qsantos