W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] New URL Standard

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 21 Sep 2012 17:44:20 +0200
Message-ID: <505C8B54.7090803@gmx.de>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@whatwg.org>
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.
Received on Friday, 21 September 2012 15:44:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC