W3C home > Mailing lists > Public > public-iri@w3.org > September 2010

Re: Progress on URL spec

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 10 Sep 2010 13:14:49 +0200
Message-ID: <4C8A1329.1030108@gmx.de>
To: Adam Barth <ietf@adambarth.com>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, public-iri@w3.org, Peter Saint-Andre <stpeter@stpeter.im>
On 05.09.2010 02:01, Adam Barth wrote:
> On Sat, Sep 4, 2010 at 4:28 PM, Bjoern Hoehrmann<derhoermi@gmx.net>  wrote:
>> * Adam Barth wrote:
>>> I've started by trying to separate the concerns of parsing absolute
>>> URLs and resolving relative URLs.  We might come to find that such a
>>> distinction is foolish, but it seems plausible at this time.
>> I don't think there is anything plausible about defining how to parse
>> an absolute reference that contains no colon and thus isn't absolute,
>> much like it is not plausible to define that the scheme in "#:" is "#".
> Plausible?  I don't understand what you mean by that term.
>>> As for the parsing definition in RFC 3986 Appendix B, is this the
>>> regular expression that you're referring to?
>>>       ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
>>> This doesn't appear to get even simple examples correct.  For example,
>>> that regular expression doesn't produce a match for the following
>>> string, but browsers do, in fact, behave as if this string represents
>>> a particular URL:
>>> http:///example.com/
>> That's a perfectly valid reference per the generic syntax and it has a
>> scheme of 'http', undefined query and fragment parts, an empty authority
>> and a path of '/example.com/' as mandated by RFC 3986 and as the regular
>> expression matches [1].
> Unfortunately, Firefox, Chrome, and Safari interpret that string as if
> it were a URL with an authority of "example.com".
> ...

Fortunately, IE8, IE9 (platform preview) and Opera 10.62 do what the 
spec says (*), so maybe the easy answer is to fix the other implementations.

Best regards, Julian

(*) checked using the decomposition attributes in the DOM.
Received on Friday, 10 September 2010 11:15:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:41 UTC