[whatwg] New URL Standard

Julian Reschke julian.reschke at gmx.de
Fri Sep 21 08:44:20 PDT 2012


On 2012-09-21 17:16, Anne van Kesteren wrote:
> I took a crack at defining URLs: http://url.spec.whatwg.org/
>
> At the moment it defines parsing (minus domain names / IP addresses)
> and the JavaScript API (minus the query manipulation methods proposed
> by Adam Barth). It defines things like setting .pathname to "hello
> world" (notice the space), it defines what happens if you resolve
> "http:test" against a data URL (you get "http://test/") or

As per RFC 3986, Section 5.2 ("Relative Resolution"), the answer IMHO is 
"http:test".

Fetching from that URI indeed used http://test/ (just checked in 
Mozilla), so it appears we have a terminology problem. It would be good 
if we could avoid confusing "relative reference resolution" with what 
you try to define here.

Note that the term "resolve" is widely used for what RFC 3986 Section 
5.2 defines; see, for instance, 
<http://docs.oracle.com/javase/1.4.2/docs/api/java/net/URI.html#resolve%28java.lang.String%29>.

 > ...

> http://teehee (you get "http://teehee/test"). It is based on the
> various URL code paths found in WebKit and Gecko and supports the \ as
> / in various places because it seemed better for compatibility.
>
> I'm looking for some feedback/ideas on how to handle various aspects, e.g.:
>
> * data URLs; in Gecko these appear to be parsed as part of the URL
> layer, because they can turn a URL invalid. Other browsers do not do
> this. Opinions? Should data URLs support .search?
 > ...

I believe the behavior should be predictable and consistent no matter 
what the URI scheme is.

Best regards, Julian

PS: and no, I don't think "URL Standard" is a good name for this document.




More information about the whatwg mailing list