Issues 43 and 185, was: Issue 43 (combining fragments)

On 03.03.2010 17:59, Julian Reschke wrote:
> ...
> 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
> ...

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:

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

The "Changes from RFC 2616" section would be modified to say:

-- snip --
    Correct syntax of Location header to allow URI references (including
    relative references and fragments), as referred symbol "absoluteURI"
    wasn't what was expected, and add some clarifications as to when use
    of fragments would not be appropriate.  (Section 9.4)
-- snip --

Feedback appreciated,

Julian

Received on Tuesday, 9 March 2010 16:55:22 UTC