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

I wonder if the semantics of the proposed solution to ticket 43 below have
implications for httpRange-14?

---------------------------- Original Message ----------------------------
Subject: Request for feedback on HTTP Location header syntax + semantics, 
Re: Issues 43 and 185, was: Issue 43 (combining fragments)
From:    "Julian Reschke" <julian.reschke@gmx.de>
Date:    Wed, March 10, 2010 1:06 pm
To:      "HTTP Working Group" <ietf-http-wg@w3.org>
         "public-html@w3.org" <public-html@w3.org>
--------------------------------------------------------------------------

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).

The new text for "Location" is:

-- snip --
9.4.  Location

    The "Location" response-header field is used to identify a newly
    created resource, or to redirect the recipient to a different
    location for completion of the request.

    For 201 (Created) responses, the Location is the URI of the new
    resource which was created by the request.  For 3xx responses, the
    location SHOULD indicate the server's preferred URI for automatic
    redirection to the resource.

    The field value consists of a single URI-reference.  When it has the
    form of a relative reference ([RFC3986], Section 4.2), the final
    value is computed by resolving it against the effective request URI
    ([RFC3986], Section 5).

      Location       = "Location" ":" OWS Location-v
      Location-v     = URI-reference

    Examples are:

      Location: http://www.example.org/pub/WWW/People.html#tim

      Location: /index.html

    There are circumstances in which a fragment identifier in a Location
    URI would not be appropriate:

    o  With a 201 Created response, because in this usage the Location
       header specifies the URI for the entire created resource.

    o  With 305 Use Proxy.

       Note: This specification does not define precedence rules for the
       case where the original URI, as navigated to be the user agent,
       and the Location header field value both contain fragment
       identifiers.

       Note: The Content-Location header field (Section 5.7 of [Part3])
       differs from Location in that the Content-Location identifies the
       original location of the entity enclosed in the response.  It is
       therefore possible for a response to contain header fields for
       both Location and Content-Location.
-- snip --

(see also
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#header.location>).

Of course it would be nice if we *could* recommend a specific behavior
that makes sense, so I would be very grateful to get feedback from UA
implementers about whether they'd consider treating relative references
and absolute URIs consistently.


Best regards, Julian

(*) We'll look at *that* issue separately.


On 10.03.2010 13:19, Julian Reschke wrote:
> On 09.03.2010 17:54, Julian Reschke wrote:
>> ...
>> OK, here's a proposal
>> (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/43/i43.diff>):
>>
>>
>>
>> - allow relative references
>>
>> - state that we do not specify fragment recombination
>>
>> - stay silent on invalid URI-references (I think we should discuss this
>> as an orthogonal issue).
>>
>> The changed text for the Location header would be:
>> ...
>
> Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/785>.
>
> I'll send a separate summary, and cc' the W3C HTML WG, trying (yet
> again) to get feedback from browser vendors about whether they're
> willing to go further than that.
>
> Best regards, Julian
>

Received on Wednesday, 10 March 2010 13:35:08 UTC