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

On Wed, Mar 10, 2010 at 5:06 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> Hi,
>
> the HTTPbis WG has two open tickets with respect to the syntax and semantics
> of the Location header (not to be confused with Content-Location!):
>
> a) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
> combination / precedence during redirects"
>
> This is about how to handle the case when both the original URI and the
> value of the Location header contain a fragment identifier.
>
> b) <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location header
> payload handling"
>
> This is about allowing relative references (in addition to full URIs), and
> also about treating broken values (*).
>
> Some time ago I created a few tests, see
> <http://greenbytes.de/tech/tc2231/redirects.html>.
>
> What I found was that
>
> - UAs appear to treat those consistently (with the exception of Opera, but
> Yngwe already signaled that he's willing to adapt), *but*
>
> - the behavior I found unfortunately doesn't make sense (treating the cases
> for absolute URIs and relative references differently).
>
> Specifically, I would expect UAs to let the fragment ID found in the
> Location header (when present) override the original URI's. But we found
> this to be only the case for absolute URIs.
>
> At this point, and with no further feedback from browser vendors about
> whether they'd consider changing the behavior for relative references, we
> changed the spec to clarify that the fragment recombination behavior is
> undefined (previously, the spec didn't say anything about this).

Leaving things undefined seems like a very bad idea. If it really
doesn't matter today what UAs do, then my experience is that sometime
in the future sites will start depending on it one way or another.

That said. I don't see that firefox treats relative and absolute URIs
any differently. The code at [1], which handles redirects, seems to
forward the fragment ID from the original uri if the new uri doesn't
have a fragment, and otherwise use the fragment ID of the new
location. No distinction is made based on if the location header
contained a relative or absolute URI.

Do you have a testcase where we can test the behavior?

/ Jonas

Received on Wednesday, 10 March 2010 16:16:33 UTC