Changeset 771 for draft-ietf-httpbis/latest/p6-cache.html

Timestamp:

Mar 5, 2010, 2:05:58 AM (10 years ago)

Author:

julian.reschke@…

Message:

clarify header normalization vs matching request headers (see #147)

File:

• draft-ietf-httpbis/latest/p6-cache.html (modified) (6 diffs)

draft-ietf-httpbis/latest/p6-cache.html

@@ -402 +402 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-03-04">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-03-05">
       <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, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -428 +428 @@
             </tr>
             <tr>
-               <td class="left">Expires: September 5, 2010</td>
+               <td class="left">Expires: September 6, 2010</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -489 +489 @@
             <tr>
                <td class="left"></td>
-               <td class="right">March 4, 2010</td>
+               <td class="right">March 5, 2010</td>
             </tr>
          </tbody>
@@ -519 +519 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
       </p>
-      <p>This Internet-Draft will expire in September 5, 2010.</p>
+      <p>This Internet-Draft will expire in September 6, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -952 +952 @@
          (i.e., that associated with the stored response), and the presented request.
       </p>
-      <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
-         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="TODO-missing-ref">[<a href="#TODO-missing-ref" class="smpl">TODO-missing-ref</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
-         name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
-      </p>
-      <p id="rfc.section.2.6.p.3">If a header field is absent from a request, it can only match another request if it is also absent there.</p>
+      <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if those in the first request can be transformed
+         to those in the second request by applying any of the following: 
+      </p>
+      <ul>
+         <li>adding or removing whitespace, where allowed in the header's syntax</li>
+         <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
+         </li>
+         <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification
+            (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)
+         </li>
+      </ul>
+      <p id="rfc.section.2.6.p.3">If (after any normalisation that may take place) a header field is absent from a request, it can only match another request
+         if it is also absent there.
+      </p>
       <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
          by the origin server.
@@ -1735 +1744 @@
       <p id="rfc.section.C.10.p.1">Closed issues: </p>
       <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/147">http://tools.ietf.org/wg/httpbis/trac/ticket/147</a>&gt;: "serving negotiated responses from cache: header-specific canonicalization"
+         </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/197">http://tools.ietf.org/wg/httpbis/trac/ticket/197</a>&gt;: "Effect of CC directives on history lists"
          </li>