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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 03 May 2011 10:43:58 +0200
Message-ID: <4DBFC04E.7000500@gmx.de>
To: Adam Barth <ietf@adambarth.com>
CC: Maciej Stachowiak <mjs@apple.com>, "Roy T. Fielding" <fielding@gbiv.com>, public-iri@w3.org
On 03.05.2011 03:08, Adam Barth wrote:
> ...
> Yes.  One example, is included at the beginning of the thread:
> <base href="data://foo/bar?baz#qux">
> <a href="taco.html">hello</a>
> <script>
> alert(document.getElementsByTagName('a')[0].href)
> </script>
> ...

Well, we discussed this already and have seen that there isn't any 
interop for this in browsers.

> There are also examples related to the different classes of URLs that
> Boris mentioned.  One of the reasons that browsers have different
> classes of URLs is because parsing and resolving relative references
> isn't uniform across different schemes.  Another problematic area is
> the treatment of fragments because the RFCs claim that fragments
> behave uniformly across URL schemes, which isn't true either.

It's true that fragments *should* behave uniformly.

I'm aware that lot's of browsers do something else for "data" URIs, 
which probably is caused by an early bad implementation, and content 
relying on that.

(Note that many URI parsers *do* the right thing, including the one in 
IE9 as observed on URL decomposition attributes).

It would be good to come up with a precise description of the problem, 
maybe leading to a revision of RFC 2397 which at least should clarify 
the parsing, and also could give advice on what current implementations 
do, such as:

- when "#" is part of the content, *always* %-escape it, and

- some UA do not treat "#" as starting the fragment, so be careful with 
fragment identifiers in data URIs.

> I'd prefer to live in a world where that wasn't true because it causes
> problems when folks introduce new URLs schemes, and I suspect that
> folks who don't feel as constrained as browser vendors could decide to
> live in that world without feeling too much pain.  Unfortunately, I
> believe this constraint is real for some folks.

One thing we absolutely need to do is to fix UAs so that whatever 
workarounds they feel they need are *only* applied to existing schemes, 
so that at least new schemes can be introduces painlessly.

Best regards, Julian
Received on Tuesday, 3 May 2011 08:44:53 UTC

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