Changeset 2237


Ignore:
Timestamp:
May 6, 2013, 11:24:08 PM (6 years ago)
Author:
mnot@…
Message:

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

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r2236 r2237  
    604604                  </ul>
    605605               </li>
    606                <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Using Negotiated Responses</a></li>
     606               <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>
    607607               <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li>
    608608            </ul>
     
    801801      </p>
    802802      <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
    803          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>).
     803         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>).
    804804      </p>
    805805      <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>
     
    864864         </li>
    865865         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
    866          <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
     866         <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
    867867         </li>
    868868         <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
     
    10461046      <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>
    10471047      <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
    1048          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
     1048         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
    10491049         update it. This process is known as "validating" or "revalidating" the stored response.
    10501050      </p>
    1051       <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.
     1051      <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.
    10521052      </p>
    10531053      <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
     
    10951095         </li>
    10961096      </ul>
    1097       <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>
     1097      <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>
    10981098      <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
    10991099         request (i.e., that associated with the stored response), and the presented request.
     
    11411141         a body. This property of HEAD responses is used to both invalidate and update cached GET responses.
    11421142      </p>
    1143       <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.
    1144       </p>
    1145       <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:
     1143      <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.
     1144      </p>
     1145      <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:
    11461146      </p>
    11471147      <ul>
     
    19031903      </p>
    19041904      <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
    1905          explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>)
     1905         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>)
    19061906      </p>
    19071907      <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>)
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2236 r2237  
    925925
    926926<section anchor="caching.negotiated.responses"
    927    title="Using Negotiated Responses">
     927   title="Calculating Secondary Keys with Vary">
    928928<t>
    929929   When a cache receives a request that can be satisfied by a stored response
Note: See TracChangeset for help on using the changeset viewer.