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

Timestamp:

07/05/13 06:24:08 (10 years ago)

Author:

mnot@…

Message:

Using Negotiated Reponses -> Calculating Secondary Keys with Vary; see #469

File:

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

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

@@ -604 +604 @@
                   </ul>
                </li>
-               <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Using Negotiated Responses</a></li>
+               <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></li>
                <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li>
             </ul>
@@ -801 +801 @@
       </p>
       <p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated
-         by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>).
+         by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>).
       </p>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Storing Responses in Caches</a></h1>
@@ -864 +864 @@
          </li>
          <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
-         <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>), and
+         <li>selecting header fields nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>), and
          </li>
          <li>the presented request does not contain the no-cache pragma (<a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;7.4</a>), nor the no-cache cache directive (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>), unless the stored response is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.2</a>), and
@@ -1046 +1046 @@
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="validation.model" href="#validation.model">Validation</a></h2>
       <p id="rfc.section.4.2.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not
-         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to
+         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to
          update it. This process is known as "validating" or "revalidating" the stored response.
       </p>
-      <p id="rfc.section.4.2.p.2">When sending such a conditional request, a cache adds an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>) stored response, if available.
+      <p id="rfc.section.4.2.p.2">When sending such a conditional request, a cache adds an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>) stored response, if available.
       </p>
       <p id="rfc.section.4.2.p.3">Additionally, a cache can add an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field whose value is that of the <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field(s) from relevant responses stored for the primary cache key, if present. However, if any of the stored responses
@@ -1095 +1095 @@
          </li>
       </ul>
-      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Using Negotiated Responses</a></h2>
+      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></h2>
       <p id="rfc.section.4.3.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 7.1.4</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
          request (i.e., that associated with the stored response), and the presented request.
@@ -1141 +1141 @@
          a body. This property of HEAD responses is used to both invalidate and update cached GET responses.
       </p>
-      <p id="rfc.section.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
-      </p>
-      <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules: 
+      <p id="rfc.section.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
+      </p>
+      <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules: 
       </p>
       <ul>
@@ -1903 +1903 @@
       </p>
       <p id="rfc.section.A.p.5">The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now
-         explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>)
+         explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>)
       </p>
       <p id="rfc.section.A.p.6">Requirements regarding denial of service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;6</a>)