Changeset 1536 for draft-ietf-httpbis/latest/p2-semantics.html

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)

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (10 diffs)

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

@@ -460 +460 @@
   } 
   @bottom-center {
-       content: "Expires August 11, 2012"; 
+       content: "Expires August 19, 2012"; 
   } 
   @bottom-right {
@@ -512 +512 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-02-08">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-02-16">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -543 +543 @@
             </tr>
             <tr>
-               <td class="left">Expires: August 11, 2012</td>
+               <td class="left">Expires: August 19, 2012</td>
                <td class="right">HP</td>
             </tr>
@@ -596 +596 @@
             <tr>
                <td class="left"></td>
-               <td class="right">February 8, 2012</td>
+               <td class="right">February 16, 2012</td>
             </tr>
          </tbody>
@@ -626 +626 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on August 11, 2012.</p>
+      <p>This Internet-Draft will expire on August 19, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -775 +775 @@
                <li>11.1&nbsp;&nbsp;&nbsp;<a href="#security.sensitive">Transfer of Sensitive Information</a></li>
                <li>11.2&nbsp;&nbsp;&nbsp;<a href="#encoding.sensitive.information.in.uris">Encoding Sensitive Information in URIs</a></li>
-               <li>11.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing">Location Headers and Spoofing</a></li>
+               <li>11.3&nbsp;&nbsp;&nbsp;<a href="#location.spoofing-leakage">Location Header Fields: Spoofing and Information Leakage</a></li>
                <li>11.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.11.4">Security Considerations for CONNECT</a></li>
             </ul>
@@ -2343 +2343 @@
       <div id="rfc.iref.h.6"></div>
       <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>
-      <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
-         for completion of the request.
-      </p>
-      <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,
+      <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.
+      </p>
+      <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>
+</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,
          the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
       </p>
-      <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>).
-      </p>
-      <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>
-</pre><div id="rfc.figure.u.24"></div> 
-      <p>Examples are:</p>  <pre class="text">  Location: http://www.example.org/pub/WWW/People.html#tim
-</pre><div id="rfc.figure.u.25"></div><pre class="text">  Location: /index.html
-</pre><div class="note" id="rfc.section.9.5.p.7"> 
+      <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,
+         then the original URI's fragment identifier is added to the final value.
+      </p>
+      <div id="rfc.figure.u.24"></div> 
+      <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
+</pre>  <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> 
+      <div id="rfc.figure.u.25"></div> 
+      <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
+</pre>  <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 
+      <div class="note" id="rfc.section.9.5.p.7"> 
          <p> <b>Note:</b> 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 <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section&nbsp;1.1</a>).
@@ -2364 +2367 @@
       </p>
       <div class="note" id="rfc.section.9.5.p.9"> 
-         <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,
-            and the Location header field value both contain fragment identifiers. Thus be aware that including fragment identifiers might
-            inconvenience anyone relying on the semantics of the original URI's fragment identifier.
-         </p> 
-      </div>
-      <div class="note" id="rfc.section.9.5.p.10"> 
          <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.
             It is therefore possible for a response to contain header fields for both Location and Content-Location.
@@ -2904 +2901 @@
          Such services can use POST-based form submission instead.
       </p>
-      <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>
+      <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>
       <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
          to make sure that they do not attempt to invalidate resources over which they have no authority.
+      </p>
+      <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
+         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.
       </p>
       <h2 id="rfc.section.11.4"><a href="#rfc.section.11.4">11.4</a>&nbsp;Security Considerations for CONNECT
@@ -3491 +3492 @@
       <ul>
          <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"
+         </li>
+         <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"
          </li>
          <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"