Re: Progress on URL spec

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