Re: Issue 43 (combining fragments)

Julian Reschke wrote:
> 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!).
> ...

OK, let's summarize:

1) HTTPbis, in a very early draft, has fixed the ABNF of the Location 
header to allow fragment identifiers 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6>)

2) What it did not is define what a recipient should do when the 
referring URI contained a fragment identifier, and the Location header 
does as well. This is issue 43 
(<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>)

3) In the meantime, people have asked for an even less strict ABNF, 
allowing relative URIs (Issue 185: 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>)

With respect to 2), we essentially have two choices:

2a) Point out that this is ambiguous, and leave it undefined.

2b) Document what many UAs do, as that happens to be sensible: in case 
both URIs contain a fragment id, the one from the Location header 
overrides the original URI, otherwise the original fragment identifier 
is appended to the new location.

This is what was tested in the first four table entries at 
<http://greenbytes.de/tech/tc2231/redirects.html>; and it shows that UAs 
seem to be consistent here with the exception of Opera.

But. For strange reasons, when seeing just an absolute path in the 
Location header, the UAs appear to ignore the fragment identifier. This 
really doesn't make any sense, because it appears that the 
implementations follow a completely different code path here.

So for 3) the choices are:

3a) Leave the behavior undefined (possible even not allowing it in the ABNF)

3b) Document what makes sense (consistent with 2b), but point out that 
current implementations fail to do this

3c) Document what they do, even though it doesn't make any sense.


I'm currently leaning to 2b/3b, but I could be convinced to do 2a/3a 
instead. However, I don't see how I could do 2b/3c.

Feedback appreciated,

Julian




3b)

Received on Wednesday, 7 October 2009 17:28:06 UTC