Re: Issue 43 (combining fragments)

On 07.10.2009 19:27, Julian Reschke wrote:
> 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

OK,

this issue has been open since the dawn of time, or actually, since 2616 
was published.

It would be great if we finally could make progress here.

A) The conservative choice is: allow fragments & relative-refs, state 
that fragment combination is undefined, and indeed differs between clients

B) The more ambitious approach: allow fragments & relative-refs, but 
pick the behavior we consider sane (my proposal: 2b/3b), and point out 
that some aspects of this aren't currently implemented properly

Feedback appreciated,

Julian

Received on Wednesday, 3 March 2010 16:59:49 UTC