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

Julian Reschke <julian.reschke@gmx.de> Wed, 15 February 2012 21:47 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973E321E809B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 15 Feb 2012 13:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.213
X-Spam-Level:
X-Spam-Status: No, score=-8.213 tagged_above=-999 required=5 tests=[AWL=2.386, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aW0hUZnVwxG for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 15 Feb 2012 13:47:42 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C9A8A21F8504 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 15 Feb 2012 13:47:42 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Rxmfx-0001hO-DF for ietf-http-wg-dist@listhub.w3.org; Wed, 15 Feb 2012 21:46:09 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <julian.reschke@gmx.de>) id 1RxmfR-000056-FU for ietf-http-wg@listhub.w3.org; Wed, 15 Feb 2012 21:45:37 +0000
Received: from mailout-de.gmx.net ([213.165.64.23]) by maggie.w3.org with smtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1RxmfL-000235-VI for ietf-http-wg@w3.org; Wed, 15 Feb 2012 21:45:36 +0000
Received: (qmail invoked by alias); 15 Feb 2012 21:45:05 -0000
Received: from p3EE26B95.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.107.149] by mail.gmx.net (mp041) with SMTP; 15 Feb 2012 22:45:05 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/UayJqdDvUkyNl6LAThmWtc0Z9AkJ25XjJELT2jk cAlEIoqIYNO9BL
Message-ID: <4F3C275E.8000201@gmx.de>
Date: Wed, 15 Feb 2012 22:45:02 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Larry Masinter <masinter@adobe.com>, httpbis Group <ietf-http-wg@w3.org>, Adam Barth <ietf@adambarth.com>
References: <6A53E99A-019D-4F6D-A33D-24524CD34E17@mnot.net> <4EFDFA17.4080804@gmx.de> <4F031419.1050708@gmx.de> <C68CB012D9182D408CED7B884F441D4D06121B5AE5@nambxv01a.corp.adobe.com> <4F0608AB.20808@gmx.de> <EDB1544B-C4AE-41CA-806A-15FD1956D467@gbiv.com> <4F08649E.6060107@gmx.de> <5AD13674-95D2-4B8B-AB84-30FBD5B45348@mnot.net> <F5646201-718C-4BA5-A644-9828186B88B0@mnot.net>
In-Reply-To: <F5646201-718C-4BA5-A644-9828186B88B0@mnot.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Received-SPF: pass client-ip=213.165.64.23; envelope-from=julian.reschke@gmx.de; helo=mailout-de.gmx.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1RxmfL-000235-VI 71efed29fb0ce4af5a6aaa5f22ca484b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: #295: Applying original fragment to "plain" redirected URI (also #43)
Archived-At: <http://www.w3.org/mid/4F3C275E.8000201@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/12437
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1Rxmfx-0001hO-DF@frink.w3.org>
Resent-Date: Wed, 15 Feb 2012 21:46:09 +0000

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