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.
