[whatwg] Relative URL plan

I've been trying to figure out a better data model for URLs so we can
handle relative URLs for any scheme. The motivation for supporting
relative URLs for any scheme can be found here:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=27233

Per my testing the URL parser would still need special handling for
what the URL Standard currently calls relative schemes. I will rename
those special schemes since any URL would now in principle be able to
handle relative URLs.

Testing of Chrome and Safari shows that even data and javascript URLs
have no special handling here. E.g.

  input     | base URL     | output
  test      | javascript:/ | javascript:/test
  data:/../ | (none)       | data:/

If fore the first example you then set host to "test:81" you get
"javascript://test:81/test" in Safari. (Though if you set host to
"/test:81" you get "javascript:///test:81/test" which seems bad. I
will treat that as a bug.)

This gives us three types of URLs:

* Special URLs. file/http/https/etc. These need to handle three
slashes after the scheme as two, can treat lack of slashes as
relative, etc.
* Relative URLs. All non-special URLs where the scheme is followed by a slash.
* Non-relative URLs. All non-special-non-relative URLs.

Non-relative URLs consist of {scheme, scheme data, query, fragment}.
Relative URLs and special URLs consist of {scheme, username, password,
host, port, path, query, fragment}. Special URLs cannot have an empty
host (as that would lead to reparsing issues), relative URLs can.
Relative URLs can also have a missing host (see javascript:/ above).

I think we should try to restrict backslash replacement and the
encoding override to special URLs.

I also think we should change the API such that you cannot change
anything for non-relative URLs (setters are no-ops, already largely
the case). And that you cannot change the scheme from a special URL to
a relative URL. Given the different handling of hosts that might lead
to security issues.

I will start rolling this out and write a bunch of tests. Even though
both Chrome and Safari implement this they have differences and some
logical inconsistencies that I think would be great to remove. I hope
to get feedback on what we cannot do from the above. Hopefully Firefox
not implementing any of this provides some wiggle room.


-- 
https://annevankesteren.nl/

Received on Tuesday, 16 June 2015 12:07:22 UTC