Re: [whatwg/url] Change host parser for non-special schemes (#148)

I agree that the rules are strange, but they're the most compatible and logical rules I can think of.  We need to keep the case sensitivity which matches all browsers, we need to keep the no '/' which matches all browsers (yes, only if the path is empty), and we need to do something with non-ASCII code points.  I haven't seen any such URLs that have non-ASCII code points, so I'm not sure what the compatibility problems might be if there are any.  Safari fails to parse such URLs, while Chrome and Firefox percent-encode them because they are considered to be in the path.

An alternative would be to match the behavior of Chrome and Firefox with all non-special URLs. That would be replacing this:
`Otherwise, if remaining starts with an "/", set state to path or authority state, and increase pointer by one.`
with this:
`Otherwise, if url’s scheme is a special scheme and remaining starts with a "/", set state to path state, and increase pointer by one.
Otherwise, if url’s scheme is not a special scheme and remaining starts with a "/", set state to path or authority state, and increase pointer by one.`
Which would match behavior of Chrome, Firefox, and Safari for some reason with urls like `a://` but with URLs like `a://b/c` Safari treats b as the host and /c as the path, while Chrome and Firefox treats //b/c as the path.  Maybe I'm biased in thinking Safari has more reasonable behavior here.  I don't like that Chrome and Firefox don't seem to allow having a host in non-special URLs.  If we aligned the spec with this behavior it would lead to strange behavior, like developers asking why are the host and path of `a://b/c` so different from `http://b/c`.  I'm curious if there is a reason Chrome and Firefox have such behavior.  The compatibility issues I've run into only uses the entire serialized URL, and I wonder if Chrome or Firefox have any tests that verify non-special URLs don't have a host.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/148#issuecomment-253785391

Received on Friday, 14 October 2016 12:24:46 UTC