Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments)

On 10.03.2010 18:20, Julian Reschke wrote:
> ...
> double-check them, given your confidence (the tests were written in a
> hurry during a conference).
>
> Turns out they relied on Apache/mod_asis to treat Location headers as
> opaque data, which apparently is not the case. So the test cases at
> <http://greenbytes.de/tech/tc2231/redirects.html> work only for those
> four tests where the redirect target is a full URI. In the other cases,
> mod_asis apparently resolves the path internally, and never sends the
> redirect.
>
> Summary: please ignore this for now; I will have to produce test cases
> that actually test what I wanted to test.
> ...

In the meantime we've got fixed test cases (thanks, Mark); the results 
are attached as HTML.

The good news is that the UAs indeed treat fragments in URIs and 
relative references consistently (as Jonas reported for Firefox).

The other good news is that Firefox, IE and Chrome handle them the same 
way, and that happens to be what makes most sense (IMHO):

1) given an original URI containing a fragment identifier

2) resolve the redirect URI-reference against the original URI

3) if the resulting URI does not have a fragment identifier, use the one 
from the original URI instead

Deviations:

- Opera gives precedence to the original URI's fragment, if present

- Safari doesn't seem to implement step 3.

So compared to what I thought previously the situation is much better, 
as the most widely implemented behavior actually makes sense.

Rephrased request for feedback:

Should we recommend the behavior we see implemented (SHOULD? MUST?)? 
Note that this would make current implementations of Opera and Safari 
non-compliant.

Best regards, Julian