Re: #295: Applying original fragment to "plain" redirected URI (also #43)

On 2012-02-13 05:59, Mark Nottingham wrote:
> Assigned for -19.

Proposed patch here: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/295/295.diff>

This changes the description of the header field to:

9.5.  Location

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

      Location = URI-reference

    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).  If the original URI, as navigated to by the
    user agent, did contain a fragment identifier, and the final value
    does not, then the original URI's fragment identifier is added to the
    final value.

    For example, the original URI "http://www.example.org/~tim", combined
    with a field value given as:

      Location: /pub/WWW/People.html#tim

    would result in a final value of
    "http://www.example.org/pub/WWW/People.html#tim"

    An original URI "http://www.example.org/index.html#larry", combined
    with a field value given as:

      Location: http://www.example.net/index.html

    would result in a final value of
    "http://www.example.net/index.html#larry", preserving the original
    fragment identifier.

       Note: Some recipients attempt to recover from Location fields that
       are not valid URI references.  This specification does not mandate
       or define such processing, but does allow it (see Section 1.1).

    There are circumstances in which a fragment identifier in a Location
    URI would not be appropriate.  For instance, when it appears in a 201
    Created response, where the Location header field specifies the URI
    for the entire created resource.

       Note: The Content-Location header field (Section 6.7 of [Part3])
       differs from Location in that the Content-Location identifies the
       most specific resource corresponding to the enclosed
       representation.  It is therefore possible for a response to
       contain header fields for both Location and Content-Location.


And also adds the following Security Consideration:

    Furthermore, appending the fragment identifier from one URI to
    another one obtained from a Location header field might leak
    confidential information to the target server -- although the
    fragment identifier is not transmitted in the final request, it might
    be visible to the user agent through other means, such as scripting).

Best regards, Julian


> On 01/02/2012, at 4:13 PM, Mark Nottingham wrote:
>
>>
>> On 08/01/2012, at 2:28 AM, Julian Reschke wrote:
>>
>>> To make this change we could add to:
>>>
>>> "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)."
>>>
>>> saying
>>>
>>> "... If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, then the original URI's fragment identifier is added to the final value."
>>>
>>>
>>> (and also we would kill<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-18.html#rfc.section.9.5.p.9>).
>>
>> Works for me; +1. Some examples wouldn't go astray.
>
>
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>

Received on Wednesday, 15 February 2012 21:45:37 UTC