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

+1


On 16/02/2012, at 8:45 AM, Julian Reschke wrote:

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

--
Mark Nottingham   http://www.mnot.net/

Received on Thursday, 16 February 2012 05:19:17 UTC