W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Issue 43 (combining fragments)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 30 Jul 2009 11:35:08 +0200
Message-ID: <4A71694C.6050609@gmx.de>
To: "Yngve N. Pettersen" <yngve@opera.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
Yngve N. Pettersen wrote:
> On Tue, 28 Jul 2009 12:25:27 +0200, Julian Reschke 
> <julian.reschke@gmx.de> wrote:
> 
>> - Opera uses the fragment from the source URI, when present, otherwise 
>> the fragment from the redirect location
> 
> Regarding Opera:
> 
> We changed the behaviour in 2003 (about v7.20) because we got several 
> reports requesting that particular change, and apparently the reporters 
> were able to accomplish what they wanted in other browsers at the time, 
> one claimed also that our old behaviour was not according to 2616.
> 
> If you clarify the entry, you should be very clear on the point that any 
> and all anchors (including no anchor) overrides any anchor used by the 
> initial resource when presenting the URL to the user or using it to 
> process the resource, or under which conditions an override should be 
> allowed, alternatively that it is not specified (which would probably be 
> unsatisfactory).
> 
> This is another area which could benefit from actual examples in the 
> specification (as I have metioned for cache directives).

Indeed.

So I just put together a set of tests that use absolute URIs, paths (see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>), and combined 
them with frag ids. See <http://greenbytes.de/tech/tc2231/redirects.html>.

The UAs I tested behaved consistently, except for the Opera issue noted 
above.

That being said, the UAs unfortunately are also consistent in ignoring 
the fragment when it appears in a relative-ref, not a URI; this is 
really bad as I wouldn't want to require different behaviors depending 
on where the fragment identifier was in.

Thus, *if* we address issue 43 by mandating that the fragment from the 
Location header overrides a previous one, that should also apply for the 
case of relative-refs, in which case all UAs would need to be fixed (sigh!).

BR, Julian
Received on Thursday, 30 July 2009 09:35:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT