Changeset 2371


Ignore:
Timestamp:
07/09/13 19:26:15 (9 years ago)
Author:
fielding@…
Message:

(editorial) move the discussion of secondary keys next to primary keys before moving p4 cache requirements; fix typo

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

Legend:

Unmodified
Added
Removed

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

    r2369 r2371  
    449449  }
    450450  @bottom-center {
    451        content: "Expires March 8, 2014";
     451       content: "Expires March 11, 2014";
    452452  }
    453453  @bottom-right {
    … …  
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2013-09-04">
     497      <meta name="dct.issued" scheme="ISO8601" content="2013-09-07">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    521521            </tr>
    522522            <tr>
    523                <td class="left">Expires: March 8, 2014</td>
     523               <td class="left">Expires: March 11, 2014</td>
    524524               <td class="right">J. Reschke, Editor</td>
    525525            </tr>
    … …  
    530530            <tr>
    531531               <td class="left"></td>
    532                <td class="right">September 4, 2013</td>
     532               <td class="right">September 7, 2013</td>
    533533            </tr>
    534534         </tbody>
    … …  
    556556         in progress”.
    557557      </p>
    558       <p>This Internet-Draft will expire on March 8, 2014.</p>
     558      <p>This Internet-Draft will expire on March 11, 2014.</p>
    559559      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    560560      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    590590         </li>
    591591         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a><ul>
    592                <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness</a><ul>
    593                      <li><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></li>
    594                      <li><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li>
    595                      <li><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li>
    596                      <li><a href="#rfc.section.4.1.4">4.1.4</a>&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li>
     592               <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></li>
     593               <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness</a><ul>
     594                     <li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></li>
     595                     <li><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li>
     596                     <li><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#age.calculations">Calculating Age</a></li>
     597                     <li><a href="#rfc.section.4.2.4">4.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#serving.stale.responses">Serving Stale Responses</a></li>
    597598                  </ul>
    598599               </li>
    599                <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation</a><ul>
    600                      <li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li>
     600               <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation</a><ul>
     601                     <li><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Stored Responses upon Validation</a></li>
    601602                  </ul>
    602603               </li>
    603                <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>
    604604            </ul>
    605605         </li>
    … …  
    703703      </div>
    704704      <p id="rfc.section.1.p.4">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current
    705          request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains
     705         request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains
    706706         valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When
    707          a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation">Section&nbsp;4.2</a>) or if the origin is unavailable (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.1.4</a>).
     707         a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>) or if the origin is unavailable (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).
    708708      </p>
    709709      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
    … …  
    739739      </p>
    740740      <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
    741          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>).
     741         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.1</a>).
    742742      </p>
    743743      <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>
    … …  
    763763               <li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>) that allows it to be cached, or
    764764               </li>
    765                <li>has a status code that is defined as cacheable (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>), or
     765               <li>has a status code that is defined as cacheable (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>), or
    766766               </li>
    767767               <li>contains a public response cache directive (see <a href="#cache-response-directive.public" title="public">Section&nbsp;7.2.2.5</a>).
    … …  
    792792      </p>
    793793      <p id="rfc.section.3.2.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be
    794          served stale (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.1.4</a>) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy
     794         served stale (<a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>) by shared caches. In particular, a response with either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to satisfy
    795795         a subsequent request without revalidating it on the origin server.
    796796      </p>
    … …  
    817817         </li>
    818818         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
    819          <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
    820          </li>
    821          <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
    822          </li>
    823          <li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;7.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.2</a>), and
     819         <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.1</a>), and
     820         </li>
     821         <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.3</a>), and
     822         </li>
     823         <li>the stored response does not contain the no-cache cache directive (<a href="#cache-response-directive.no-cache" title="no-cache">Section&nbsp;7.2.2.2</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>), and
    824824         </li>
    825825         <li>the stored response is either:
    826826            <ul>
    827                <li>fresh (see <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>), or
     827               <li>fresh (see <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>), or
    828828               </li>
    829                <li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.1.4</a>), or
     829               <li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>), or
    830830               </li>
    831                <li>successfully validated (see <a href="#validation.model" title="Validation">Section&nbsp;4.2</a>).
     831               <li>successfully validated (see <a href="#validation.model" title="Validation">Section&nbsp;4.3</a>).
    832832               </li>
    833833            </ul>
    … …  
    836836      <p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>.
    837837      </p>
    838       <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
     838      <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> generate an <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>), replacing any present in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>.
    839839      </p>
    840840      <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
    … …  
    848848      <p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them upon every use.
    849849      </p>
     850      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Calculating Secondary Keys with Vary</a></h2>
     851      <p id="rfc.section.4.1.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.4"><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
     852         request (i.e., that associated with the stored response), and the presented request.
     853      </p>
     854      <p id="rfc.section.4.1.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed
     855         to those in the second request by applying any of the following:
     856      </p>
     857      <ul>
     858         <li>adding or removing whitespace, where allowed in the header field's syntax</li>
     859         <li>combining multiple 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.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>)
     860         </li>
     861         <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification
     862            (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)
     863         </li>
     864      </ul>
     865      <p id="rfc.section.4.1.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request
     866         if it is also absent there.
     867      </p>
     868      <p id="rfc.section.4.1.p.4">A <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match.
     869      </p>
     870      <p id="rfc.section.4.1.p.5">The stored response with matching selecting header fields is known as the selected response.</p>
     871      <p id="rfc.section.4.1.p.6">If multiple selected responses are available (potentially including responses without a Vary header field), the cache will
     872         need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on <a href="p2-semantics.html#header.accept" class="smpl">Accept</a> and similar request header fields), that mechanism <em class="bcp14">MAY</em> be used to select preferred responses; of the remainder, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used, as per <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;4</a>.
     873      </p>
     874      <p id="rfc.section.4.1.p.7">If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin
     875         server in a (possibly conditional; see <a href="#validation.model" title="Validation">Section&nbsp;4.3</a>) request.
     876      </p>
    850877      <div id="rfc.iref.f.1"></div>
    851878      <div id="rfc.iref.s.2"></div>
    852       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness</a></h2>
    853       <p id="rfc.section.4.1.p.1">A <dfn>fresh</dfn> response is one whose age has not yet exceeded its freshness lifetime. Conversely, a <dfn>stale</dfn> response is one where it has.
     879      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness</a></h2>
     880      <p id="rfc.section.4.2.p.1">A <dfn>fresh</dfn> response is one whose age has not yet exceeded its freshness lifetime. Conversely, a <dfn>stale</dfn> response is one where it has.
    854881      </p>
    855882      <div id="rfc.iref.f.2"></div>
    856883      <div id="rfc.iref.e.1"></div>
    857884      <div id="rfc.iref.h.1"></div>
    858       <p id="rfc.section.4.1.p.2">A response's <dfn>freshness lifetime</dfn> is the length of time between its generation by the origin server and its expiration time. An <dfn>explicit expiration time</dfn> is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation,
    859          whereas a <dfn>heuristic expiration time</dfn> is assigned by a cache when no explicit expiriation time is available.
     885      <p id="rfc.section.4.2.p.2">A response's <dfn>freshness lifetime</dfn> is the length of time between its generation by the origin server and its expiration time. An <dfn>explicit expiration time</dfn> is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation,
     886         whereas a <dfn>heuristic expiration time</dfn> is assigned by a cache when no explicit expiration time is available.
    860887      </p>
    861888      <div id="rfc.iref.a.1"></div>
    862       <p id="rfc.section.4.1.p.3">A response's <dfn>age</dfn> is the time that has passed since it was generated by, or successfully validated with, the origin server.
    863       </p>
    864       <p id="rfc.section.4.1.p.4">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server,
     889      <p id="rfc.section.4.2.p.3">A response's <dfn>age</dfn> is the time that has passed since it was generated by, or successfully validated with, the origin server.
     890      </p>
     891      <p id="rfc.section.4.2.p.4">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server,
    865892         thereby improving efficiency.
    866893      </p>
    867       <p id="rfc.section.4.1.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
     894      <p id="rfc.section.4.2.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
    868895         using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;7.3</a>) or the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
    869896         is not likely to change in a semantically significant way before the expiration time is reached.
    870897      </p>
    871       <p id="rfc.section.4.1.p.6">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past
     898      <p id="rfc.section.4.2.p.6">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past
    872899         to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing
    873          it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.1.4</a>).
    874       </p>
    875       <p id="rfc.section.4.1.p.7">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine
    876          an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>).
     900         it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).
     901      </p>
     902      <p id="rfc.section.4.2.p.7">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine
     903         an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>).
    877904      </p>
    878905      <div id="rfc.figure.u.2"></div>
    879906      <p>The calculation to determine if a response is fresh is:</p><pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
    880 </pre><p id="rfc.section.4.1.p.9">freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;4.1.1</a>; current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
    881       </p>
    882       <p id="rfc.section.4.1.p.10">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the
     907</pre><p id="rfc.section.4.2.p.9">freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;4.2.1</a>; current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>.
     908      </p>
     909      <p id="rfc.section.4.2.p.10">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the
    883910         corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
    884911      </p>
    885       <p id="rfc.section.4.1.p.11">When calculating freshness, to avoid common problems in date parsing:</p>
    886       <p id="rfc.section.4.1.p.12"></p>
     912      <p id="rfc.section.4.2.p.11">When calculating freshness, to avoid common problems in date parsing:</p>
     913      <p id="rfc.section.4.2.p.12"></p>
    887914      <ul>
    888915         <li>Although all date formats are specified to be case-sensitive, cache recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
    … …  
    895922         </li>
    896923      </ul>
    897       <p id="rfc.section.4.1.p.13">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
     924      <p id="rfc.section.4.2.p.13">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
    898925         a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;8</a> for an explanation of the difference between caches and history mechanisms.
    899926      </p>
    900       <h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a>&nbsp;<a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>
    901       <p id="rfc.section.4.1.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p>
     927      <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>
     928      <p id="rfc.section.4.2.1.p.1">A cache can calculate the freshness lifetime (denoted as freshness_lifetime) of a response by using the first match of: </p>
    902929      <ul>
    903930         <li>If the cache is shared and the s-maxage response cache directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.9</a>) is present, use its value, or
    … …  
    907934         <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;7.3</a>) is present, use its value minus the value of the <a href="p2-semantics.html#header.date" class="smpl">Date</a> response header field, or
    908935         </li>
    909          <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>.
    910          </li>
    911       </ul>
    912       <p id="rfc.section.4.1.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
    913       <p id="rfc.section.4.1.1.p.3">When there is more than one value present for a given directive (e.g., two <a href="#header.expires" class="smpl">Expires</a> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid. Caches are encouraged
     936         <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>.
     937         </li>
     938      </ul>
     939      <p id="rfc.section.4.2.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
     940      <p id="rfc.section.4.2.1.p.3">When there is more than one value present for a given directive (e.g., two <a href="#header.expires" class="smpl">Expires</a> header fields, multiple Cache-Control: max-age directives), the directive's value is considered invalid. Caches are encouraged
    914941         to consider responses that have invalid freshness information to be stale.
    915942      </p>
    916       <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3>
    917       <p id="rfc.section.4.1.2.p.1">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field
     943      <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3>
     944      <p id="rfc.section.4.2.2.p.1">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field
    918945         values (such as the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case
    919946         constraints on their results.
    920947      </p>
    921       <p id="rfc.section.4.1.2.p.2">A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements
     948      <p id="rfc.section.4.2.2.p.2">A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements
    922949         in <a href="#response.cacheability" title="Storing Responses in Caches">Section&nbsp;3</a>, this means that, effectively, heuristics can only be used on responses without explicit freshness whose status codes are
    923950         defined as cacheable, and responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a
    924951         "public" response cache directive).
    925952      </p>
    926       <p id="rfc.section.4.1.2.p.3">If the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
     953      <p id="rfc.section.4.2.2.p.3">If the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
    927954         time. A typical setting of this fraction might be 10%.
    928955      </p>
    929       <p id="rfc.section.4.1.2.p.4">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a <a href="#header.warning" class="smpl">Warning</a> header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already
     956      <p id="rfc.section.4.2.2.p.4">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a <a href="#header.warning" class="smpl">Warning</a> header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already
    930957         present.
    931958      </p>
    932       <div class="note" id="rfc.section.4.1.2.p.5">
     959      <div class="note" id="rfc.section.4.2.2.p.5">
    933960         <p><b>Note:</b> <a href="http://tools.ietf.org/html/rfc2616#section-13.9">Section 13.9</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> prohibited caches from calculating heuristic freshness for URIs with query components (i.e., those containing '?'). In practice,
    934961            this has not been widely implemented. Therefore, origin servers are encouraged to send explicit directives (e.g., Cache-Control:
    … …  
    936963         </p>
    937964      </div>
    938       <h3 id="rfc.section.4.1.3"><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
    939       <p id="rfc.section.4.1.3.p.1">The <a href="#header.age" class="smpl">Age</a> header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is
     965      <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
     966      <p id="rfc.section.4.2.3.p.1">The <a href="#header.age" class="smpl">Age</a> header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is
    940967         the cache's estimate of the number of seconds since the response was generated or validated by the origin server. In essence,
    941968         the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin
    942969         server, plus the amount of time it has been in transit along network paths.
    943970      </p>
    944       <p id="rfc.section.4.1.3.p.2">The following data is used for the age calculation:</p>
    945       <p id="rfc.section.4.1.3.p.3"><dfn>age_value</dfn>
     971      <p id="rfc.section.4.2.3.p.2">The following data is used for the age calculation:</p>
     972      <p id="rfc.section.4.2.3.p.3"><dfn>age_value</dfn>
    946973      </p>
    947974      <ul class="empty">
    … …  
    949976         </li>
    950977      </ul>
    951       <p id="rfc.section.4.1.3.p.4"><dfn>date_value</dfn>
     978      <p id="rfc.section.4.2.3.p.4"><dfn>date_value</dfn>
    952979      </p>
    953980      <ul class="empty">
    954          <li>The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    955          </li>
    956       </ul>
    957       <p id="rfc.section.4.1.3.p.5"><dfn>now</dfn>
     981         <li>The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     982         </li>
     983      </ul>
     984      <p id="rfc.section.4.2.3.p.5"><dfn>now</dfn>
    958985      </p>
    959986      <ul class="empty">
    … …  
    961988         </li>
    962989      </ul>
    963       <p id="rfc.section.4.1.3.p.6"><dfn>request_time</dfn>
     990      <p id="rfc.section.4.2.3.p.6"><dfn>request_time</dfn>
    964991      </p>
    965992      <ul class="empty">
    966993         <li>The current value of the clock at the host at the time the request resulting in the stored response was made.</li>
    967994      </ul>
    968       <p id="rfc.section.4.1.3.p.7"><dfn>response_time</dfn>
     995      <p id="rfc.section.4.2.3.p.7"><dfn>response_time</dfn>
    969996      </p>
    970997      <ul class="empty">
    971998         <li>The current value of the clock at the host at the time the response was received.</li>
    972999      </ul>
    973       <p id="rfc.section.4.1.3.p.8">A response's age can be calculated in two entirely independent ways: </p>
     1000      <p id="rfc.section.4.2.3.p.8">A response's age can be calculated in two entirely independent ways: </p>
    9741001      <ol>
    9751002         <li>the "apparent_age": response_time minus date_value, if the local clock is reasonably well synchronized to the origin server's
    … …  
    9851012</pre><div id="rfc.figure.u.4"></div>
    9861013      <p>These are combined as</p><pre class="text">  corrected_initial_age = max(apparent_age, corrected_age_value);
    987 </pre><p id="rfc.section.4.1.3.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
    988       </p>
    989       <p id="rfc.section.4.1.3.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
     1014</pre><p id="rfc.section.4.2.3.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
     1015      </p>
     1016      <p id="rfc.section.4.2.3.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
    9901017         was last validated by the origin server to the corrected_initial_age.
    9911018      </p>
    9921019      <div id="rfc.figure.u.5"></div><pre class="text">  resident_time = now - response_time;
    9931020  current_age = corrected_initial_age + resident_time;
    994 </pre><h3 id="rfc.section.4.1.4"><a href="#rfc.section.4.1.4">4.1.4</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
    995       <p id="rfc.section.4.1.4.p.1">A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but
    996          is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>.
    997       </p>
    998       <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
     1021</pre><h3 id="rfc.section.4.2.4"><a href="#rfc.section.4.2.4">4.2.4</a>&nbsp;<a id="serving.stale.responses" href="#serving.stale.responses">Serving Stale Responses</a></h3>
     1022      <p id="rfc.section.4.2.4.p.1">A "stale" response is one that either has explicit expiry information or is allowed to have heuristic expiry calculated, but
     1023         is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>.
     1024      </p>
     1025      <p id="rfc.section.4.2.4.p.2">A cache <em class="bcp14">MUST NOT</em> generate a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    9991026         directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    10001027         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>).
    10011028      </p>
    1002       <p id="rfc.section.4.1.4.p.3">A cache <em class="bcp14">MUST NOT</em> send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)
     1029      <p id="rfc.section.4.2.4.p.3">A cache <em class="bcp14">MUST NOT</em> send stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)
    10031030         or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
    10041031      </p>
    1005       <p id="rfc.section.4.1.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;7.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
     1032      <p id="rfc.section.4.2.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;7.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
    10061033      </p>
    10071034      <div id="rfc.iref.f.3"></div>
    1008       <p id="rfc.section.4.1.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">MAY</em> forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache ought not attempt to validate a response simply because
     1035      <p id="rfc.section.4.2.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">MAY</em> forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache ought not attempt to validate a response simply because
    10091036         that response became stale in transit.
    10101037      </p>
    1011       <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>
    1012       <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
    1013          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.2"><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
     1038      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="validation.model" href="#validation.model">Validation</a></h2>
     1039      <p id="rfc.section.4.3.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
     1040         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><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
    10141041         update it. This process is known as "validating" or "revalidating" the stored response.
    10151042      </p>
    10161043      <div id="rfc.iref.v.1"></div>
    1017       <p id="rfc.section.4.2.p.2">When sending such a conditional request, a cache adds a <dfn>validator</dfn> (or more than one), that is used to find out whether a stored response is an equivalent copy of a current representation of
     1044      <p id="rfc.section.4.3.p.2">When sending such a conditional request, a cache adds a <dfn>validator</dfn> (or more than one), that is used to find out whether a stored response is an equivalent copy of a current representation of
    10181045         the resource.
    10191046      </p>
    1020       <p id="rfc.section.4.2.p.3">One such validator is the <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.
    1021       </p>
    1022       <p id="rfc.section.4.2.p.4">Another is the <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
     1047      <p id="rfc.section.4.3.p.3">One such validator is the <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.1</a>) stored response, if available.
     1048      </p>
     1049      <p id="rfc.section.4.3.p.4">Another is the <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
    10231050         contains only partial content, the cache ought not include its entity-tag in the If-None-Match header field unless the request
    10241051         is for a range that would be fully satisfied by that stored response.
    10251052      </p>
    1026       <p id="rfc.section.4.2.p.5">Cache handling of a response to a conditional request is dependent upon its status code:</p>
    1027       <p id="rfc.section.4.2.p.6"></p>
     1053      <p id="rfc.section.4.3.p.5">Cache handling of a response to a conditional request is dependent upon its status code:</p>
     1054      <p id="rfc.section.4.3.p.6"></p>
    10281055      <ul>
    1029          <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section&nbsp;4.2.1</a>.
     1056         <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section&nbsp;4.3.1</a>.
    10301057         </li>
    10311058         <li>A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request
    … …  
    10331060         </li>
    10341061         <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as
    1035             if the server failed to respond. In the latter case, it can send a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.1.4</a>).
    1036          </li>
    1037       </ul>
    1038       <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3>
    1039       <p id="rfc.section.4.2.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response
     1062            if the server failed to respond. In the latter case, it can send a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.2.4</a>).
     1063         </li>
     1064      </ul>
     1065      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Stored Responses upon Validation</a></h3>
     1066      <p id="rfc.section.4.3.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response
    10401067         and then update the stored response(s) with the new information provided in the <a href="p4-conditional.html#status.304" class="smpl">304</a> response.
    10411068      </p>
    10421069      <div id="rfc.iref.s.3"></div>
    1043       <p id="rfc.section.4.2.1.p.2">The stored response to update is identified by using the first match (if any) of: </p>
     1070      <p id="rfc.section.4.3.1.p.2">The stored response to update is identified by using the first match (if any) of: </p>
    10441071      <ul>
    10451072         <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same
    … …  
    10541081         </li>
    10551082      </ul>
    1056       <p id="rfc.section.4.2.1.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>:
     1083      <p id="rfc.section.4.3.1.p.3">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>:
    10571084      </p>
    10581085      <ul>
    … …  
    10641091         </li>
    10651092      </ul>
    1066       <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>
    1067       <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
    1068          request (i.e., that associated with the stored response), and the presented request.
    1069       </p>
    1070       <p id="rfc.section.4.3.p.2">The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed
    1071          to those in the second request by applying any of the following:
    1072       </p>
    1073       <ul>
    1074          <li>adding or removing whitespace, where allowed in the header field's syntax</li>
    1075          <li>combining multiple 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.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>)
    1076          </li>
    1077          <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification
    1078             (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)
    1079          </li>
    1080       </ul>
    1081       <p id="rfc.section.4.3.p.3">If (after any normalization that might take place) a header field is absent from a request, it can only match another request
    1082          if it is also absent there.
    1083       </p>
    1084       <p id="rfc.section.4.3.p.4">A <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match.
    1085       </p>
    1086       <p id="rfc.section.4.3.p.5">The stored response with matching selecting header fields is known as the selected response.</p>
    1087       <p id="rfc.section.4.3.p.6">If multiple selected responses are available (potentially including responses without a Vary header field), the cache will
    1088          need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on <a href="p2-semantics.html#header.accept" class="smpl">Accept</a> and similar request header fields), that mechanism <em class="bcp14">MAY</em> be used to select preferred responses; of the remainder, the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field) is used, as per <a href="#constructing.responses.from.caches" title="Constructing Responses from Caches">Section&nbsp;4</a>.
    1089       </p>
    1090       <p id="rfc.section.4.3.p.7">If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin
    1091          server in a (possibly conditional; see <a href="#validation.model" title="Validation">Section&nbsp;4.2</a>) request.
    1092       </p>
    10931093      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="head.effects" href="#head.effects">Updating Caches with HEAD Responses</a></h1>
    10941094      <p id="rfc.section.5.p.1">A response to the HEAD method is identical to what an equivalent request made with a GET would have been, except it lacks
    10951095         a body. This property of HEAD responses is used to both invalidate and update cached GET responses.
    10961096      </p>
    1097       <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.
    1098       </p>
    1099       <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:
     1097      <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.1</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.
     1098      </p>
     1099      <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.1</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules:
    11001100      </p>
    11011101      <ul>
    … …  
    11311131      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
    11321132      <p id="rfc.section.7.1.p.1">The "Age" header field conveys the sender's estimate of the amount of time since the response was generated or successfully
    1133          validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
     1133         validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>.
    11341134      </p>
    11351135      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#header.age" class="smpl">Age</a> = <a href="#delta-seconds" class="smpl">delta-seconds</a>
    … …  
    13551355      <div id="rfc.iref.e.2"></div>
    13561356      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
    1357       <p id="rfc.section.7.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a> for further discussion of the freshness model.
     1357      <p id="rfc.section.7.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a> for further discussion of the freshness model.
    13581358      </p>
    13591359      <p id="rfc.section.7.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
    … …  
    15021502         retrieved earlier in a session.
    15031503      </p>
    1504       <p id="rfc.section.8.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if
     1504      <p id="rfc.section.8.p.2">The freshness model (<a href="#expiration.model" title="Freshness">Section&nbsp;4.2</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if
    15051505         it has expired.
    15061506      </p>
    … …  
    18631863      </p>
    18641864      <p id="rfc.section.A.p.3">New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate
    1865          heuristic freshness for URIs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>)
     1865         heuristic freshness for URIs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.2.2</a>)
    18661866      </p>
    18671867      <p id="rfc.section.A.p.4">The algorithm for calculating age is now less conservative. Caches are now required to handle dates with timezones as if they're
    1868          invalid, because it's not possible to accurately guess. (<a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>)
    1869       </p>
    1870       <p id="rfc.section.A.p.5">The <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field is no longer used to determine the appropriate response to use when validating. (<a href="#validation.model" title="Validation">Section&nbsp;4.2</a>)
     1868         invalid, because it's not possible to accurately guess. (<a href="#age.calculations" title="Calculating Age">Section&nbsp;4.2.3</a>)
     1869      </p>
     1870      <p id="rfc.section.A.p.5">The <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field is no longer used to determine the appropriate response to use when validating. (<a href="#validation.model" title="Validation">Section&nbsp;4.3</a>)
    18711871      </p>
    18721872      <p id="rfc.section.A.p.6">The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now
    1873          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>)
     1873         explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>)
    18741874      </p>
    18751875      <p id="rfc.section.A.p.7">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>)
    … …  
    20452045            </li>
    20462046            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    2047                   <li>age&nbsp;&nbsp;<a href="#rfc.iref.a.1">4.1</a></li>
    2048                   <li>Age header field&nbsp;&nbsp;<a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.1.3</a>, <a href="#rfc.iref.a.2"><b>7.1</b></a>, <a href="#rfc.xref.header.age.3">9.3</a></li>
     2047                  <li>age&nbsp;&nbsp;<a href="#rfc.iref.a.1">4.2</a></li>
     2048                  <li>Age header field&nbsp;&nbsp;<a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.2.3</a>, <a href="#rfc.iref.a.2"><b>7.1</b></a>, <a href="#rfc.xref.header.age.3">9.3</a></li>
    20492049               </ul>
    20502050            </li>
    … …  
    20612061            </li>
    20622062            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    2063                   <li>Expires header field&nbsp;&nbsp;<a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.1</a>, <a href="#rfc.xref.header.expires.3">4.1.1</a>, <a href="#rfc.iref.e.2"><b>7.3</b></a>, <a href="#rfc.xref.header.expires.4">9.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li>
    2064                   <li>explicit expiration time&nbsp;&nbsp;<a href="#rfc.iref.e.1">4.1</a></li>
     2063                  <li>Expires header field&nbsp;&nbsp;<a href="#rfc.xref.header.expires.1">3</a>, <a href="#rfc.xref.header.expires.2">4.2</a>, <a href="#rfc.xref.header.expires.3">4.2.1</a>, <a href="#rfc.iref.e.2"><b>7.3</b></a>, <a href="#rfc.xref.header.expires.4">9.3</a>, <a href="#rfc.xref.header.expires.5">A</a></li>
     2064                  <li>explicit expiration time&nbsp;&nbsp;<a href="#rfc.iref.e.1">4.2</a></li>
    20652065               </ul>
    20662066            </li>
    20672067            <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul>
    2068                   <li>first-hand&nbsp;&nbsp;<a href="#rfc.iref.f.3">4.1.4</a></li>
    2069                   <li>fresh&nbsp;&nbsp;<a href="#rfc.iref.f.1">4.1</a></li>
    2070                   <li>freshness lifetime&nbsp;&nbsp;<a href="#rfc.iref.f.2">4.1</a></li>
     2068                  <li>first-hand&nbsp;&nbsp;<a href="#rfc.iref.f.3">4.2.4</a></li>
     2069                  <li>fresh&nbsp;&nbsp;<a href="#rfc.iref.f.1">4.2</a></li>
     2070                  <li>freshness lifetime&nbsp;&nbsp;<a href="#rfc.iref.f.2">4.2</a></li>
    20712071               </ul>
    20722072            </li>
    … …  
    20932093            </li>
    20942094            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
    2095                   <li>heuristic expiration time&nbsp;&nbsp;<a href="#rfc.iref.h.1">4.1</a></li>
     2095                  <li>heuristic expiration time&nbsp;&nbsp;<a href="#rfc.iref.h.1">4.2</a></li>
    20962096               </ul>
    20972097            </li>
    … …  
    21142114            </li>
    21152115            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2116                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a>, <a href="#rfc.xref.Part1.11">10</a>, <a href="#rfc.xref.Part1.12">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul>
     2116                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.1</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a>, <a href="#rfc.xref.Part1.11">10</a>, <a href="#rfc.xref.Part1.12">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul>
    21172117                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">C</a></li>
    21182118                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
    21192119                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.20">B</a></li>
    2120                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.15">B</a></li>
     2120                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">4.1</a>, <a href="#rfc.xref.Part1.15">B</a></li>
    21212121                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">B</a></li>
    21222122                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a></li>
    … …  
    21282128                     </ul>
    21292129                  </li>
    2130                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1.3</a>, <a href="#rfc.xref.Part2.5">4.3</a>, <a href="#rfc.xref.Part2.6">6</a>, <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">10</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul>
     2130                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">4.2.3</a>, <a href="#rfc.xref.Part2.6">6</a>, <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">10</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul>
    21312131                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.6">6</a></li>
    21322132                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2</a></li>
    21332133                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.9">B</a></li>
    2134                         <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.3</a></li>
    2135                         <li><em>Section 7.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.3</a></li>
     2134                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.2.3</a></li>
     2135                        <li><em>Section 7.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1</a></li>
    21362136                     </ul>
    21372137                  </li>
    2138                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.1.2</a>, <a href="#rfc.xref.Part4.2">4.2</a>, <a href="#rfc.xref.Part4.3">4.2.1</a>, <a href="#Part4"><b>12.1</b></a><ul>
    2139                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">4.2.1</a></li>
    2140                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.1.2</a></li>
     2138                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2.2</a>, <a href="#rfc.xref.Part4.2">4.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#Part4"><b>12.1</b></a><ul>
     2139                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">4.3.1</a></li>
     2140                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.2.2</a></li>
    21412141                     </ul>
    21422142                  </li>
    … …  
    21572157            </li>
    21582158            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    2159                   <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>
     2159                  <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4.2.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>
    21602160                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    2161                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.1.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul>
    2162                         <li><em>Section 13.9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.1.2</a></li>
     2161                  <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul>
     2162                        <li><em>Section 13.9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.2.2</a></li>
    21632163                     </ul>
    21642164                  </li>
    … …  
    21822182                  <li>s-maxage (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>7.2.2.9</b></a></li>
    21832183                  <li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1</a></li>
    2184                   <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">4.1</a></li>
    2185                   <li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">4.2.1</a></li>
     2184                  <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">4.2</a></li>
     2185                  <li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">4.3.1</a></li>
    21862186               </ul>
    21872187            </li>
    21882188            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    2189                   <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">4.2</a></li>
     2189                  <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">4.3</a></li>
    21902190               </ul>
    21912191            </li>
    21922192            <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul>
    2193                   <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.1.4</a>, <a href="#rfc.xref.header.warning.3">4.2.1</a>, <a href="#rfc.xref.header.warning.4">5</a>, <a href="#rfc.iref.w.1"><b>7.5</b></a>, <a href="#rfc.xref.header.warning.5">9.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li>
     2193                  <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">3.3</a>, <a href="#rfc.xref.header.warning.2">4.2.4</a>, <a href="#rfc.xref.header.warning.3">4.3.1</a>, <a href="#rfc.xref.header.warning.4">5</a>, <a href="#rfc.iref.w.1"><b>7.5</b></a>, <a href="#rfc.xref.header.warning.5">9.3</a>, <a href="#rfc.xref.header.warning.6">A</a></li>
    21942194               </ul>
    21952195            </li>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r2369 r2371  
    452452</t>
    453453
     454<section anchor="caching.negotiated.responses"
     455   title="Calculating Secondary Keys with Vary">
     456<t>
     457   When a cache receives a request that can be satisfied by a stored response
     458   that has a <x:ref>Vary</x:ref> header field (&header-vary;),
     459   it &MUST-NOT; use that response unless all of the selecting header fields
     460   nominated by the Vary header field match in both the original request
     461   (i.e., that associated with the stored response), and the presented
     462   request.
     463</t>
     464<t>
     465   The selecting header fields from two requests are defined to match if and
     466   only if those in the first request can be transformed to those in the
     467   second request by applying any of the following:
     468   <list style="symbols">
     469      <t>
     470         adding or removing whitespace, where allowed in the header field's
     471         syntax
     472      </t>
     473      <t>
     474         combining multiple header fields with the same field name
     475         (see &header-fields;)
     476      </t>
     477      <t>
     478         normalizing both header field values in a way that is known to have
     479         identical semantics, according to the header field's specification
     480         (e.g., re-ordering field values when order is not significant;
     481         case-normalization, where values are defined to be case-insensitive)
     482      </t>
     483  </list>
     484</t>
     485<t>
     486   If (after any normalization that might take place) a header field is absent
     487   from a request, it can only match another request if it is also absent
     488   there.
     489</t>
     490<t>
     491   A <x:ref>Vary</x:ref> header field-value of "*" always fails to match.
     492</t>
     493<t>
     494   The stored response with matching selecting header fields is known as the
     495   selected response.
     496</t>
     497<t>
     498   If multiple selected responses are available (potentially including
     499   responses without a Vary header field), the cache will need to choose one to use.
     500   When a selecting header field has a known mechanism for doing so (e.g., qvalues on
     501   <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be
     502   used to select preferred responses; of the remainder, the most recent
     503   response (as determined by the <x:ref>Date</x:ref> header field) is used, as
     504   per <xref target="constructing.responses.from.caches"/>.
     505</t>
     506<t>
     507   If no selected response is available, the cache cannot satisfy the
     508   presented request. Typically, it is forwarded to the origin server
     509   in a (possibly conditional; see <xref target="validation.model"/>) request.
     510</t>
     511</section>
    454512
    455513<section anchor="expiration.model" title="Freshness">
    … …  
    470528   server intends that a stored response can no longer be used by a cache
    471529   without further validation, whereas a <x:dfn>heuristic expiration
    472    time</x:dfn> is assigned by a cache when no explicit expiriation time is
     530   time</x:dfn> is assigned by a cache when no explicit expiration time is
    473531   available.
    474532</t>
    … …  
    878936</section>
    879937
    880 </section>
    881 
    882 <section anchor="caching.negotiated.responses"
    883    title="Calculating Secondary Keys with Vary">
    884 <t>
    885    When a cache receives a request that can be satisfied by a stored response
    886    that has a <x:ref>Vary</x:ref> header field (&header-vary;),
    887    it &MUST-NOT; use that response unless all of the selecting header fields
    888    nominated by the Vary header field match in both the original request
    889    (i.e., that associated with the stored response), and the presented
    890    request.
    891 </t>
    892 <t>
    893    The selecting header fields from two requests are defined to match if and
    894    only if those in the first request can be transformed to those in the
    895    second request by applying any of the following:
    896    <list style="symbols">
    897       <t>
    898          adding or removing whitespace, where allowed in the header field's
    899          syntax
    900       </t>
    901       <t>
    902          combining multiple header fields with the same field name
    903          (see &header-fields;)
    904       </t>
    905       <t>
    906          normalizing both header field values in a way that is known to have
    907          identical semantics, according to the header field's specification
    908          (e.g., re-ordering field values when order is not significant;
    909          case-normalization, where values are defined to be case-insensitive)
    910       </t>
    911   </list>
    912 </t>
    913 <t>
    914    If (after any normalization that might take place) a header field is absent
    915    from a request, it can only match another request if it is also absent
    916    there.
    917 </t>
    918 <t>
    919    A <x:ref>Vary</x:ref> header field-value of "*" always fails to match.
    920 </t>
    921 <t>
    922    The stored response with matching selecting header fields is known as the
    923    selected response.
    924 </t>
    925 <t>
    926    If multiple selected responses are available (potentially including
    927    responses without a Vary header field), the cache will need to choose one to use.
    928    When a selecting header field has a known mechanism for doing so (e.g., qvalues on
    929    <x:ref>Accept</x:ref> and similar request header fields), that mechanism &MAY; be
    930    used to select preferred responses; of the remainder, the most recent
    931    response (as determined by the <x:ref>Date</x:ref> header field) is used, as
    932    per <xref target="constructing.responses.from.caches"/>.
    933 </t>
    934 <t>
    935    If no selected response is available, the cache cannot satisfy the
    936    presented request. Typically, it is forwarded to the origin server
    937    in a (possibly conditional; see <xref target="validation.model"/>) request.
    938 </t>
    939938</section>
    940939
Note: See TracChangeset for help on using the changeset viewer.