Ignore:
Timestamp:
16/02/12 22:26:09 (9 years ago)
Author:
julian.reschke@…
Message:

Location header field: define header field recombination in presence of fragment identifiers, mention security impact, rephrase main definition (see #295)

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1534 r1536  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 11, 2012";
     462       content: "Expires August 19, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    512512      <meta name="dct.creator" content="Reschke, J. F.">
    513513      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    514       <meta name="dct.issued" scheme="ISO8601" content="2012-02-08">
     514      <meta name="dct.issued" scheme="ISO8601" content="2012-02-16">
    515515      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    516516      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    … …  
    543543            </tr>
    544544            <tr>
    545                <td class="left">Expires: August 11, 2012</td>
     545               <td class="left">Expires: August 19, 2012</td>
    546546               <td class="right">HP</td>
    547547            </tr>
    … …  
    596596            <tr>
    597597               <td class="left"></td>
    598                <td class="right">February 8, 2012</td>
     598               <td class="right">February 16, 2012</td>
    599599            </tr>
    600600         </tbody>
    … …  
    626626         in progress”.
    627627      </p>
    628       <p>This Internet-Draft will expire on August 11, 2012.</p>
     628      <p>This Internet-Draft will expire on August 19, 2012.</p>
    629629      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    630630      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    775775               <li>11.1&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
    776776               <li>11.2&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
    777                <li>11.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing">Location Headers and Spoofing</a></li>
     777               <li>11.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
    778778               <li>11.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.11.4">Security Considerations for CONNECT</a></li>
    779779            </ul>
    … …  
    23432343      <div id="rfc.iref.h.6"></div>
    23442344      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h2>
    2345       <p id="rfc.section.9.5.p.1">The "Location" header field is used to identify a newly created resource, or to redirect the recipient to a different location
    2346          for completion of the request.
    2347       </p>
    2348       <p id="rfc.section.9.5.p.2">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
     2345      <p id="rfc.section.9.5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.
     2346      </p>
     2347      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
     2348</pre><p id="rfc.section.9.5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,
    23492349         the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
    23502350      </p>
    2351       <p id="rfc.section.9.5.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>).
    2352       </p>
    2353       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
    2354 </pre><div id="rfc.figure.u.24"></div>
    2355       <p>Examples are:</p>  <pre class="text">  Location: http://www.example.org/pub/WWW/People.html#tim
    2356 </pre><div id="rfc.figure.u.25"></div><pre class="text">  Location: /index.html
    2357 </pre><div class="note" id="rfc.section.9.5.p.7">
     2351      <p id="rfc.section.9.5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
     2352         then the original URI's fragment identifier is added to the final value.
     2353      </p>
     2354      <div id="rfc.figure.u.24"></div>
     2355      <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p>  <pre class="text">  Location: /pub/WWW/People.html#tim
     2356</pre>  <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p>
     2357      <div id="rfc.figure.u.25"></div>
     2358      <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p>  <pre class="text">  Location: http://www.example.net/index.html
     2359</pre>  <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p>
     2360      <div class="note" id="rfc.section.9.5.p.7">
    23582361         <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate
    23592362            or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section&nbsp;1.1</a>).
    … …  
    23642367      </p>
    23652368      <div class="note" id="rfc.section.9.5.p.9">
    2366          <p> <b>Note:</b> This specification does not define precedence rules for the case where the original URI, as navigated to by the user agent,
    2367             and the Location header field value both contain fragment identifiers. Thus be aware that including fragment identifiers might
    2368             inconvenience anyone relying on the semantics of the original URI's fragment identifier.
    2369          </p>
    2370       </div>
    2371       <div class="note" id="rfc.section.9.5.p.10">
    23722369         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.13"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    23732370            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    … …  
    29042901         Such services can use POST-based form submission instead.
    29052902      </p>
    2906       <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>
     2903      <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing-leakage" href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></h2>
    29072904      <p id="rfc.section.11.3.p.1">If a single server supports multiple organizations that do not trust one another, then it <em class="bcp14">MUST</em> check the values of Location and Content-Location header fields in responses that are generated under control of said organizations
    29082905         to make sure that they do not attempt to invalidate resources over which they have no authority.
     2906      </p>
     2907      <p id="rfc.section.11.3.p.2">Furthermore, appending the fragment identifier from one URI to another one obtained from a Location header field might leak
     2908         confidential information to the target server — although the fragment identifier is not transmitted in the final request,
     2909         it might be visible to the user agent through other means, such as scripting.
    29092910      </p>
    29102911      <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a>&nbsp;Security Considerations for CONNECT
    … …  
    34913492      <ul>
    34923493         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/238">http://tools.ietf.org/wg/httpbis/trac/ticket/238</a>&gt;: "Requirements for user intervention during redirects"
     3494         </li>
     3495         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/295">http://tools.ietf.org/wg/httpbis/trac/ticket/295</a>&gt;: "Applying original fragment to 'plain' redirected URI"
    34933496         </li>
    34943497         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/302">http://tools.ietf.org/wg/httpbis/trac/ticket/302</a>&gt;: "Misplaced text on connection handling in p2"

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1534 r1536  
    25862586  <x:anchor-alias value="Location"/>
    25872587<t>
    2588    The "Location" header field is used to identify a newly created
    2589    resource, or to redirect the recipient to a different location for
    2590    completion of the request.
    2591 </t>
     2588   The "Location" header field &MAY; be sent in responses to refer to
     2589   a specific resource in accordance with the semantics of the status
     2590   code.
     2591</t>
     2592<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/>
     2593  <x:ref>Location</x:ref> = <x:ref>URI-reference</x:ref>
     2594</artwork></figure>
    25922595<t>
    25932596   For 201 (Created) responses, the Location is the URI of the new resource
    … …  
    26002603   of a relative reference (<xref target="RFC3986" x:fmt="," x:sec="4.2"/>),
    26012604   the final value is computed by resolving it against the effective request
    2602    URI (<xref target="RFC3986" x:fmt="," x:sec="5"/>).
    2603 </t>
    2604 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/>
    2605   <x:ref>Location</x:ref> = <x:ref>URI-reference</x:ref>
    2606 </artwork></figure>
     2605   URI (<xref target="RFC3986" x:fmt="," x:sec="5"/>). If the original URI, as
     2606   navigated to by the user agent, did contain a fragment identifier, and the
     2607   final value does not, then the original URI's fragment identifier is added
     2608   to the final value.
     2609</t>
    26072610<figure>
    2608 <preamble>Examples are:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
     2611<preamble>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
    26092612<artwork type="example">
    2610   Location: http://www.example.org/pub/WWW/People.html#tim
    2611 </artwork></figure><figure><artwork type="example">  Location: /index.html
    2612 </artwork></figure>
     2613  Location: /pub/WWW/People.html#tim
     2614</artwork>
     2615<postamble>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</postamble>
     2616</figure>
     2617<figure>
     2618<preamble>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
     2619<artwork type="example">
     2620  Location: http://www.example.net/index.html
     2621</artwork>
     2622<postamble>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</postamble>
     2623</figure>
    26132624<x:note>
    26142625  <t>
    … …  
    26242635   created resource.
    26252636</t>
    2626 <x:note>
    2627   <t>
    2628     <x:h>Note:</x:h> This specification does not define precedence rules
    2629     for the case where the original URI, as navigated to by the user
    2630     agent, and the Location header field value both contain fragment
    2631     identifiers. Thus be aware that including fragment identifiers might
    2632     inconvenience anyone relying on the semantics of the original URI's
    2633     fragment identifier.
    2634   </t>
    2635 </x:note>
    26362637<x:note>
    26372638  <t>
    … …  
    32843285</section>
    32853286
    3286 <section title="Location Headers and Spoofing" anchor="location.spoofing">
     3287<section title="Location Header Fields: Spoofing and Information Leakage" anchor="location.spoofing-leakage">
    32873288<t>
    32883289   If a single server supports multiple organizations that do not trust
    … …  
    32913292   said organizations to make sure that they do not attempt to
    32923293   invalidate resources over which they have no authority.
     3294</t>
     3295<t>
     3296   Furthermore, appending the fragment identifier from one URI to another
     3297   one obtained from a Location header field might leak confidential
     3298   information to the target server &mdash; although the fragment identifier is
     3299   not transmitted in the final request, it might be visible to the user agent
     3300   through other means, such as scripting.
    32933301</t>
    32943302</section>
    … …  
    46584666    </t>
    46594667    <t>
     4668      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/295"/>:
     4669      "Applying original fragment to 'plain' redirected URI"
     4670    </t>
     4671    <t>
    46604672      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/302"/>:
    46614673      "Misplaced text on connection handling in p2"
Note: See TracChangeset for help on using the changeset viewer.