This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From the parsing algorithm: ---- If buffer is ".." and c is one of EOF code point, "/", and "\", set the last string in url's path to the empty string. Otherwise, if buffer is "..", remove the last string from url's path. ---- For URLs like: http://example.com/../../filename , when there are no strings in the path yet, after the first "../" is read, it's undefined what happens. Does it trigger an error? Does the parser return failure? Or is that step just simply ignored? This may also affect this rule, found elsewhere in the algorithm: ----- Set url's host to base's host, url's port to base's port, url's path to base's path, then remove url's path's last string, set state to relative path state, and decrease pointer by one. -----
Yeah, I suppose this should all just become pop url's path and append to url's path, with replace being that combination.
https://github.com/whatwg/url/commit/33b15c97d762e9f100126f66e2bec4234a3779df
Thanks for your change. I think having it say "pop url's path if possible" would make it better, to further make it clear.
Fair enough: https://github.com/whatwg/url/commit/a421bbc781d923e6cfb84f10bc5c21cd4a164882