W3C home > Mailing lists > Public > public-iri@w3.org > April 2011

Re: Non-hierarchical base URLs (was Re: draft-abarth-url-01 uploaded)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 26 Apr 2011 18:03:23 +0200
Message-ID: <4DB6ECCB.6050705@gmx.de>
To: Adam Barth <ietf@adambarth.com>
CC: public-iri@w3.org
On 25.04.2011 10:27, Julian Reschke wrote:
> On 25.04.2011 10:18, Julian Reschke wrote:
>> ...
>> By my reading of RFC 3986 it should be
>>
>> data://foo/taco.html
>>
>> I tried with four browsers and got three different answers, all of them
>> not the one above.
>> ...
>
> Actually, Safari *does* the right thing here.
>
> Best regards, Julian
 > ...

...after some more testing...

First, a general statement: for an unknown URI scheme, there's no way to 
even detect whether it's hierarchical or not. The distinction is 
meaningless for parsing and resolving. And, furthermore, URI processors 
need to work consistently for unknown URI schemes, otherwise introducing 
new schemes will be even less fun than it already is :-)

Adam's example was:

<base href="data://foo/bar?baz#qux">
<a href="taco.html">hello</a>
<script>
alert(document.getElementsByTagName('a')[0].href)
</script>

The results are:

A: Firefox 4, IE 9: ignore the <base> element, and resolve "taco.html" 
against where the document was served from

B: Safari 5, Konqueror 4.6: resolve against the base URI, thus display 
"data://foo/taco.html"

C: Chrome: empty string

D: Opera: just "taco.html"

Observations:

- This is an edge case; unless I'm missing something, using "data:" as a 
base URI is meaningless. This is what FF and IE seem to think.

- There's no interop here at all. So it appears we could recommend 
something that is actually based by the specs.

- A can be defended by tuning the semantics of <base>, which is 
out-of-scope for *this* WG

- B is exactly what RFC 3986 says

Best regards, Julian
Received on Tuesday, 26 April 2011 16:03:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:14:39 UTC