- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 21 Sep 2012 17:44:20 +0200
- 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