Changeset 2234


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

Editorial work on p6; partially deals with #469.

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

Legend:

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

    r2232 r2234  
    452452  }
    453453  @bottom-center {
    454        content: "Expires November 2, 2013";
     454       content: "Expires November 8, 2013";
    455455  }
    456456  @bottom-right {
     
    492492      <link href="p5-range.html" rel="prev">
    493493      <link href="p7-auth.html" rel="next">
    494       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.594, 2013/04/30 16:11:28, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     494      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.594, 2013/04/30 16:11:28, XSLT vendor: SAXON 9.1.0.8 from Saxonica http://www.saxonica.com/">
    495495      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    496496      <meta name="dct.creator" content="Fielding, R.">
     
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2013-05-01">
     500      <meta name="dct.issued" scheme="ISO8601" content="2013-05-07">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <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.">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: November 2, 2013</td>
     526               <td class="left">Expires: November 8, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
     
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">May 1, 2013</td>
     535               <td class="right">May 7, 2013</td>
    536536            </tr>
    537537         </tbody>
     
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on November 2, 2013.</p>
     561      <p>This Internet-Draft will expire on November 8, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    578578      <ul class="toc">
    579579         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#caching">Introduction</a><ul>
    580                <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.purpose">Purpose</a></li>
    581                <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#intro.terminology">Terminology</a></li>
    582                <li><a href="#rfc.section.1.3">1.3</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
    583                <li><a href="#rfc.section.1.4">1.4</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    584                      <li><a href="#rfc.section.1.4.1">1.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li>
     580               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#intro.terminology">Terminology</a></li>
     581               <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
     582               <li><a href="#rfc.section.1.3">1.3</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
     583                     <li><a href="#rfc.section.1.3.1">1.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li>
    585584                  </ul>
    586585               </li>
     
    594593         </li>
    595594         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a><ul>
    596                <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness Model</a><ul>
     595               <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness</a><ul>
    597596                     <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>
    598597                     <li><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li>
     
    601600                  </ul>
    602601               </li>
    603                <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a><ul>
     602               <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation</a><ul>
    604603                     <li><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Responses with 304 Not Modified</a></li>
    605604                  </ul>
     
    686685      </p>
    687686      <div id="rfc.iref.c.1"></div>
    688       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.purpose" href="#intro.purpose">Purpose</a></h2>
    689       <p id="rfc.section.1.1.p.1">An HTTP <dfn>cache</dfn> is a local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache
    690          stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests.
    691          Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel.
    692       </p>
    693       <p id="rfc.section.1.1.p.2">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current
    694          request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness Model">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
    695          valid for this request). A fresh cache response can therefore reduce both latency and network transfers each time it is reused.
    696          When a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation Model">Section&nbsp;4.2</a>) or if the origin is unavailable.
    697       </p>
    698       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.terminology" href="#intro.terminology">Terminology</a></h2>
    699       <p id="rfc.section.1.2.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, HTTP caching.</p>
    700       <p id="rfc.section.1.2.p.2"> <span id="rfc.iref.c.2"></span>  <dfn>cache</dfn> 
     687      <p id="rfc.section.1.p.2">An HTTP <dfn>cache</dfn> is a local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it.
     688         A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
     689         requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel.
     690      </p>
     691      <p id="rfc.section.1.p.3">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current
     692         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
     693         valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When
     694         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 (xref target="serving.stale.responses" /&gt;).
     695      </p>
     696      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.terminology" href="#intro.terminology">Terminology</a></h2>
     697      <p id="rfc.section.1.1.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, HTTP caching.</p>
     698      <p id="rfc.section.1.1.p.2"> <span id="rfc.iref.c.2"></span>  <dfn>cache</dfn> 
    701699      </p>
    702700      <ul class="empty">
     
    706704      </ul>
    707705      <div id="shared.and.non-shared.caches">
    708          <p id="rfc.section.1.2.p.3"> <span id="rfc.iref.s.1"></span>  <dfn>shared cache</dfn> 
     706         <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.s.1"></span>  <dfn>shared cache</dfn> 
    709707         </p>
    710708         <ul class="empty">
     
    712710         </ul>
    713711      </div>
    714       <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.p.1"></span>  <dfn>private cache</dfn> 
     712      <p id="rfc.section.1.1.p.4"> <span id="rfc.iref.p.1"></span>  <dfn>private cache</dfn> 
    715713      </p>
    716714      <ul class="empty">
    717715         <li>A cache that is dedicated to a single user.</li>
    718716      </ul>
    719       <p id="rfc.section.1.2.p.5"> <span id="rfc.iref.c.3"></span>  <dfn>cacheable</dfn> 
     717      <p id="rfc.section.1.1.p.5"> <span id="rfc.iref.c.3"></span>  <dfn>cacheable</dfn> 
    720718      </p>
    721719      <ul class="empty">
     
    725723         </li>
    726724      </ul>
    727       <p id="rfc.section.1.2.p.6"> <span id="rfc.iref.e.1"></span>  <dfn>explicit expiration time</dfn> 
     725      <p id="rfc.section.1.1.p.6"> <span id="rfc.iref.e.1"></span>  <dfn>explicit expiration time</dfn> 
    728726      </p>
    729727      <ul class="empty">
    730728         <li>The time at which the origin server intends that a stored response no longer be used by a cache without further validation.</li>
    731729      </ul>
    732       <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
     730      <p id="rfc.section.1.1.p.7"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
    733731      </p>
    734732      <ul class="empty">
    735733         <li>An expiration time assigned by a cache when no explicit expiration time is available.</li>
    736734      </ul>
    737       <p id="rfc.section.1.2.p.8"> <span id="rfc.iref.a.1"></span>  <dfn>age</dfn> 
    738       </p>
    739       <ul class="empty">
    740          <li>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</li>
    741       </ul>
    742       <p id="rfc.section.1.2.p.9"> <span id="rfc.iref.f.1"></span>  <dfn>first-hand</dfn> 
     735      <p id="rfc.section.1.1.p.8"> <span id="rfc.iref.a.1"></span>  <dfn>age</dfn> 
     736      </p>
     737      <ul class="empty">
     738         <li>The time since a response was sent by, or successfully validated with, the origin server.</li>
     739      </ul>
     740      <p id="rfc.section.1.1.p.9"> <span id="rfc.iref.f.1"></span>  <dfn>first-hand</dfn> 
    743741      </p>
    744742      <ul class="empty">
    745743         <li>A response is first-hand if the freshness model is not in use; i.e., its age is 0.</li>
    746744      </ul>
    747       <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.f.2"></span>  <dfn>freshness lifetime</dfn> 
    748       </p>
    749       <ul class="empty">
    750          <li>The length of time between the generation of a response and its expiration time.</li>
    751       </ul>
    752       <p id="rfc.section.1.2.p.11"> <span id="rfc.iref.f.3"></span>  <dfn>fresh</dfn> 
     745      <p id="rfc.section.1.1.p.10"> <span id="rfc.iref.f.2"></span>  <dfn>freshness lifetime</dfn> 
     746      </p>
     747      <ul class="empty">
     748         <li>The length of time between the generation of a response and its expiration time (either explicit or heuristic).</li>
     749      </ul>
     750      <p id="rfc.section.1.1.p.11"> <span id="rfc.iref.f.3"></span>  <dfn>fresh</dfn> 
    753751      </p>
    754752      <ul class="empty">
    755753         <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li>
    756754      </ul>
    757       <p id="rfc.section.1.2.p.12"> <span id="rfc.iref.s.2"></span>  <dfn>stale</dfn> 
    758       </p>
    759       <ul class="empty">
    760          <li>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</li>
    761       </ul>
    762       <p id="rfc.section.1.2.p.13"> <span id="rfc.iref.v.1"></span>  <dfn>validator</dfn> 
    763       </p>
    764       <ul class="empty">
    765          <li>A protocol element (e.g., an entity-tag or a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) that is used to find out whether a stored response is an equivalent copy of a representation. 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.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    766          </li>
    767       </ul>
    768       <p id="rfc.section.1.2.p.14"> <span id="rfc.iref.s.3"></span>  <span id="rfc.iref.v.2"></span>  <dfn>strong validator</dfn> 
    769       </p>
    770       <ul class="empty">
    771          <li>A validator that is defined by the origin server such that its current value will change if the representation data changes;
    772             i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    773          </li>
    774       </ul>
    775       <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
    776       <p id="rfc.section.1.3.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     755      <p id="rfc.section.1.1.p.12"> <span id="rfc.iref.s.2"></span>  <dfn>stale</dfn> 
     756      </p>
     757      <ul class="empty">
     758         <li>A response is stale if its age has passed its freshness lifetime.</li>
     759      </ul>
     760      <p id="rfc.section.1.1.p.13"> <span id="rfc.iref.v.1"></span>  <dfn>validator</dfn> 
     761      </p>
     762      <ul class="empty">
     763         <li>A protocol element (e.g., an entity-tag or a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) that is used to find out whether a stored response is an equivalent copy of a representation. .
     764         </li>
     765      </ul>
     766      <p id="rfc.section.1.1.p.14"> <span id="rfc.iref.s.3"></span>  <span id="rfc.iref.v.2"></span>  <dfn>strong validator</dfn> 
     767      </p>
     768      <ul class="empty">
     769         <li>A validator that is defined by the origin server such that its current value will change if the representation data changes.
     770            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.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></li>
     771      </ul>
     772      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
     773      <p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    777774         in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    778775      </p>
    779       <p id="rfc.section.1.3.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    780       </p>
    781       <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    782       <p id="rfc.section.1.4.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
    783       </p>
    784       <h3 id="rfc.section.1.4.1"><a href="#rfc.section.1.4.1">1.4.1</a>&nbsp;<a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h3>
    785       <p id="rfc.section.1.4.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p>
     776      <p id="rfc.section.1.2.p.2">Conformance criteria and considerations regarding error handling are defined in <a href="p1-messaging.html#conformance" title="Conformance and Error Handling">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     777      </p>
     778      <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     779      <p id="rfc.section.1.3.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. <a href="#imported.abnf" title="Imported ABNF">Appendix&nbsp;B</a> describes rules imported from other documents. <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;C</a> shows the collected ABNF with the list rule expanded.
     780      </p>
     781      <h3 id="rfc.section.1.3.1"><a href="#rfc.section.1.3.1">1.3.1</a>&nbsp;<a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h3>
     782      <p id="rfc.section.1.3.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p>
    786783      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    787 </pre><p id="rfc.section.1.4.1.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of
     784</pre><p id="rfc.section.1.3.1.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of
    788785         its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648.
    789786      </p>
     
    792789      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="caching.overview" href="#caching.overview">Overview of Cache Operation</a></h1>
    793790      <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when
    794          no requirement or locally-desired configuration prevents it. Therefore, HTTP cache requirements are focused on preventing
    795          a cache from either storing a non-reusable response or reusing a stored response inappropriately.
     791         no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from
     792         either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always
     793         store and reuse particular responses.
    796794      </p>
    797795      <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common
     
    799797         use as a cache key.
    800798      </p>
    801       <p id="rfc.section.2.p.3">The default <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching
    802          responses to GET, many implementations simply decline other methods and use only the URI as the key.
     799      <p id="rfc.section.2.p.3">The primary <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching
     800         responses to GET, many implementations simply decline other methods and use only the URI as the primary cache key.
    803801      </p>
    804802      <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
     
    823821               <li>contains a max-age response cache directive (see <a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.7</a>), or
    824822               </li>
    825                <li>contains a s-maxage response cache directive and the cache is shared, or</li>
     823               <li>contains a s-maxage response cache directive (see <a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.8</a>) and the cache is shared, or
     824               </li>
    826825               <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
    827826               </li>
     
    835834      <p id="rfc.section.3.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>.
    836835      </p>
    837       <p id="rfc.section.3.p.3">In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements any
    838          cache-specific behavior.
    839       </p>
    840       <p id="rfc.section.3.p.4">Note that, in normal operation, many caches will not store a response that has neither a cache validator nor an explicit expiration
     836      <p id="rfc.section.3.p.3">In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements all
     837         specified caching-related behavior.
     838      </p>
     839      <p id="rfc.section.3.p.4">Note that, in normal operation, some caches will not store a response that has neither a cache validator nor an explicit expiration
    841840         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
    842841      </p>
     
    859858      </p>
    860859      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h1>
    861       <p id="rfc.section.4.p.1">For a presented request, a cache <em class="bcp14">MUST NOT</em> send a stored response, unless:
     860      <p id="rfc.section.4.p.1">When presented with a request, a cache <em class="bcp14">MUST NOT</em> reuse a stored response, unless:
    862861      </p>
    863862      <ul>
     
    867866         <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
    868867         </li>
    869          <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 Model">Section&nbsp;4.2</a>), and
    870          </li>
    871          <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.3</a>), unless it is successfully validated (<a href="#validation.model" title="Validation Model">Section&nbsp;4.2</a>), and
     868         <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
     869         </li>
     870         <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.3</a>), unless it is successfully validated (<a href="#validation.model" title="Validation">Section&nbsp;4.2</a>), and
    872871         </li>
    873872         <li>the stored response is either:
    874873            <ul>
    875                <li>fresh (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;4.1</a>), or
     874               <li>fresh (see <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>), or
    876875               </li>
    877876               <li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.1.4</a>), or
    878877               </li>
    879                <li>successfully validated (see <a href="#validation.model" title="Validation Model">Section&nbsp;4.2</a>).
     878               <li>successfully validated (see <a href="#validation.model" title="Validation">Section&nbsp;4.2</a>).
    880879               </li>
    881880            </ul>
     
    884883      <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>.
    885884      </p>
    886       <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> send a single <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>) 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>.
     885      <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>.
    887886      </p>
    888887      <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
     
    891890      <p id="rfc.section.4.p.5">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;6</a>.
    892891      </p>
    893       <p id="rfc.section.4.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field). It can also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate
     892      <p id="rfc.section.4.p.6">When more than one suitable response is stored, a cache <em class="bcp14">MUST</em> use the most recent response (as determined by the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field). It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate
    894893         which response to use.
    895894      </p>
    896       <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 on every use.
    897       </p>
    898       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
     895      <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.
     896      </p>
     897      <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>
    899898      <p id="rfc.section.4.1.p.1">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server,
    900899         thereby improving efficiency.
     
    913912      <div id="rfc.figure.u.2"></div>
    914913      <p>The calculation to determine if a response is fresh is:</p><pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
    915 </pre><p id="rfc.section.4.1.p.6">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;4.1.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
     914</pre><p id="rfc.section.4.1.p.6">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>.
    916915      </p>
    917916      <p id="rfc.section.4.1.p.7">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the
     
    934933      </ul>
    935934      <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>
    936       <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), it is considered invalid. Caches are encouraged to consider responses
    937          that have invalid freshness information to be stale.
     935      <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         to consider responses that have invalid freshness information to be stale.
    938937      </p>
    939938      <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>
     
    947946         "public" response cache directive).
    948947      </p>
    949       <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.4"><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
     948      <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.2"><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
    950949         time. A typical setting of this fraction might be 10%.
    951950      </p>
     
    955954      <div class="note" id="rfc.section.4.1.2.p.5">
    956955         <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,
    957             this has not been widely implemented. Therefore, servers are encouraged to send explicit directives (e.g., Cache-Control:
     956            this has not been widely implemented. Therefore, origin servers are encouraged to send explicit directives (e.g., Cache-Control:
    958957            no-cache) if they wish to preclude caching.
    959958         </p>
     
    10301029      <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>
    10311030      <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
    1032          is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;4.1</a>.
     1031         is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>.
    10331032      </p>
    10341033      <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> send a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
     
    10411040      <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.1" 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.
    10421041      </p>
    1043       <p id="rfc.section.4.1.4.p.5">If a cache receives a first-hand response (either 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
     1042      <p id="rfc.section.4.1.4.p.5">note that if a cache receives a first-hand response (either 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
    10441043         can 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 shouldn't attempt to validate a response simply because
    10451044         that response became stale in transit.
    10461045      </p>
    1047       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
     1046      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="validation.model" href="#validation.model">Validation</a></h2>
    10481047      <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
    1049          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.5"><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="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
    10501049         update it. This process is known as "validating" or "revalidating" the stored response.
    10511050      </p>
    10521051      <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.
    10531052      </p>
    1054       <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 all responses stored for the requested URI, if present. However, if any of the stored responses contains
    1055          only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request is for
    1056          a range that would be fully satisfied by that stored response.
     1053      <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
     1054         contains only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request
     1055         is for a range that would be fully satisfied by that stored response.
    10571056      </p>
    10581057      <p id="rfc.section.4.2.p.4">Cache handling of a response to a conditional request is dependent upon its status code:</p>
     
    10741073      <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>
    10751074      <ul>
    1076          <li>If the new response contains a strong validator, then that strong validator identifies the selected representation. All of
    1077             the stored responses with the same strong validator are selected. If none of the stored responses contain the same strong
    1078             validator, then the new response <em class="bcp14">MUST NOT</em> be used to update any stored responses.
     1075         <li>If the new response contains a strong validator, then that strong validator identifies the selected representation for update.
     1076            All of the stored responses with the same strong validator are selected. If none of the stored responses contain the same
     1077            strong validator, then the new response <em class="bcp14">MUST NOT</em> be used to update any stored responses.
    10791078         </li>
    10801079         <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then
    1081             the most recent of those matching stored responses is selected.
     1080            the most recent of those matching stored responses is selected for update.
    10821081         </li>
    10831082         <li>If the new response does not include any form of validator (such as in the case where a client generates an If-Modified-Since
    10841083            request from a source other than the Last-Modified response header field), and there is only one stored response, and that
    1085             stored response also lacks a validator, then that stored response is selected.
     1084            stored response also lacks a validator, then that stored response is selected for update.
    10861085         </li>
    10871086      </ul>
     
    11211120      </p>
    11221121      <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
    1123          server in a (possibly conditional; see <a href="#validation.model" title="Validation Model">Section&nbsp;4.2</a>) request.
     1122         server in a (possibly conditional; see <a href="#validation.model" title="Validation">Section&nbsp;4.2</a>) request.
    11241123      </p>
    11251124      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2>
     
    11691168         request.
    11701169      </p>
    1171       <p id="rfc.section.6.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
    1172          change at the origin server might not have gone through the cache where a response is stored.
     1170      <p id="rfc.section.6.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, a state-changing request might
     1171         invalidate responses in the caches it travels through, but relevant responses still might be stored in other caches that it
     1172         has not.
    11731173      </p>
    11741174      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
     
    11801180      </p>
    11811181      <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>
    1182 </pre><p id="rfc.section.7.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.4.1</a>).
     1182</pre><p id="rfc.section.7.1.p.3">Age field-values are non-negative integers, representing time in seconds (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.3.1</a>).
    11831183      </p>
    11841184      <p id="rfc.section.7.1.p.4">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
     
    11941194      </p>
    11951195      <div class="note" id="rfc.section.7.2.p.3">
    1196          <p> <b>Note:</b> HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;7.4</a>).
     1196         <p> <b>Note:</b> some HTTP/1.0 caches might not implement Cache-Control.
    11971197         </p>
    11981198      </div>
     
    12281228      <p id="rfc.section.7.2.1.3.p.1">Argument syntax: </p>
    12291229      <ul class="empty">
    1230          <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.4.1</a>)
     1230         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.3.1</a>)
    12311231         </li>
    12321232      </ul>
     
    12411241      <p id="rfc.section.7.2.1.4.p.1">Argument syntax: </p>
    12421242      <ul class="empty">
    1243          <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.4.1</a>)
    1244          </li>
    1245       </ul>
    1246       <p id="rfc.section.7.2.1.4.p.2">The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its expiration
    1247          time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    1248          by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1249          a stale response of any age.
     1243         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.3.1</a>)
     1244         </li>
     1245      </ul>
     1246      <p id="rfc.section.7.2.1.4.p.2">The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness
     1247         lifetime. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its freshness
     1248         lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing
     1249         to accept a stale response of any age.
    12501250      </p>
    12511251      <p id="rfc.section.7.2.1.4.p.3"> <b>Note:</b> This directive uses the token form of the argument syntax; e.g., 'max-stale=10', not 'max-stale="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
     
    12551255      <p id="rfc.section.7.2.1.5.p.1">Argument syntax: </p>
    12561256      <ul class="empty">
    1257          <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.4.1</a>)
     1257         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.3.1</a>)
    12581258         </li>
    12591259      </ul>
     
    12921292         with the listed response header fields. That is, a shared cache <em class="bcp14">MUST NOT</em> store the specified field-names(s), whereas it <em class="bcp14">MAY</em> store the remainder of the response message.
    12931293      </p>
    1294       <p id="rfc.section.7.2.2.2.p.4">The field-names given are not limited to the set of standard header fields defined by this specification. Field names are
    1295          case-insensitive.
    1296       </p>
     1294      <p id="rfc.section.7.2.2.2.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
    12971295      <p id="rfc.section.7.2.2.2.p.5"> <b>Note:</b> This usage of the word "private" only controls where the response can be stored; it cannot ensure the privacy of the message
    12981296         content. Also, private response directives with field-names are often handled by implementations as if an unqualified private
     
    13161314         server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
    13171315      </p>
    1318       <p id="rfc.section.7.2.2.3.p.4">The field-names given are not limited to the set of standard header fields defined by this specification. Field names are
    1319          case-insensitive.
    1320       </p>
    1321       <p id="rfc.section.7.2.2.3.p.5"> <b>Note:</b> Many HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache response directives with field-names are often
    1322          handled by implementations as if an unqualified no-cache directive was received; i.e., the special handling for the qualified
    1323          form is not widely implemented.
     1316      <p id="rfc.section.7.2.2.3.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
     1317      <p id="rfc.section.7.2.2.3.p.5"> <b>Note:</b> Although it has been back-ported to many implementations, some HTTP/1.0 caches will not recognize or obey this directive.
     1318         Also, no-cache response directives with field-names are often handled by implementations as if an unqualified no-cache directive
     1319         was received; i.e., the special handling for the qualified form is not widely implemented.
    13241320      </p>
    13251321      <p id="rfc.section.7.2.2.3.p.6"> <b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
     
    13511347      <p id="rfc.section.7.2.2.7.p.1">Argument syntax: </p>
    13521348      <ul class="empty">
    1353          <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.4.1</a>)
     1349         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.3.1</a>)
    13541350         </li>
    13551351      </ul>
     
    13631359      <p id="rfc.section.7.2.2.8.p.1">Argument syntax: </p>
    13641360      <ul class="empty">
    1365          <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.4.1</a>)
     1361         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.3.1</a>)
    13661362         </li>
    13671363      </ul>
     
    13771373      <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
    13781374      <p id="rfc.section.7.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional
    1379          value. Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics
     1375         value.
     1376      </p>
     1377      <p id="rfc.section.7.2.3.p.2">Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics
    13801378         of other directives. Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives.
    1381          Both the new directive and the standard directive are supplied, such that applications that do not understand the new directive
     1379      </p>
     1380      <p id="rfc.section.7.2.3.p.3">Both the new directive and the standard directive are supplied, such that applications that do not understand the new directive
    13821381         will default to the behavior specified by the standard directive, and those that understand the new directive will recognize
    13831382         it as modifying the requirements associated with the standard directive. In this way, extensions to the cache-control directives
    13841383         can be made without requiring changes to the base protocol.
    13851384      </p>
    1386       <p id="rfc.section.7.2.3.p.2">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
     1385      <p id="rfc.section.7.2.3.p.4">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
    13871386         obeying certain extensions, and ignoring all directives that it does not understand.
    13881387      </p>
    1389       <p id="rfc.section.7.2.3.p.3">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
     1388      <p id="rfc.section.7.2.3.p.5">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
    13901389         We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the
    13911390         community named within its value is allowed to cache the response. An origin server wishing to allow the UCI community to
     
    13931392      </p>
    13941393      <div id="rfc.figure.u.8"></div><pre class="text">  Cache-Control: private, community="UCI"
    1395 </pre><p id="rfc.section.7.2.3.p.5">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
     1394</pre><p id="rfc.section.7.2.3.p.7">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
    13961395         it will also see and understand the private directive and thus default to the safe behavior.
    13971396      </p>
    1398       <p id="rfc.section.7.2.3.p.6">A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache
     1397      <p id="rfc.section.7.2.3.p.8">A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache
    13991398         will be combined with standard directives (or the response's default cacheability) such that the cache behavior will remain
    14001399         minimally correct even if the cache does not understand the extension(s).
    14011400      </p>
    1402       <p id="rfc.section.7.2.3.p.7">New extension directives ought to consider defining:</p>
    1403       <p id="rfc.section.7.2.3.p.8"> </p>
     1401      <p id="rfc.section.7.2.3.p.9">New extension directives ought to consider defining:</p>
     1402      <p id="rfc.section.7.2.3.p.10"> </p>
    14041403      <ul>
    14051404         <li>What it means for a directive to be specified multiple times,</li>
    14061405         <li>When the directive does not take an argument, what it means when an argument is present,</li>
    1407          <li>When the directive requires an argument, what it means when it is missing.</li>
    1408       </ul>
    1409       <p id="rfc.section.7.2.3.p.9">The HTTP Cache Directive Registry defines the name space for the cache directives.</p>
    1410       <p id="rfc.section.7.2.3.p.10">A registration <em class="bcp14">MUST</em> include the following fields:
     1406         <li>When the directive requires an argument, what it means when it is missing,</li>
     1407         <li>Whether the directive is specific to requests, responses, or able to be used in either.</li>
     1408      </ul>
     1409      <p id="rfc.section.7.2.3.p.11">The HTTP Cache Directive Registry defines the name space for the cache directives.</p>
     1410      <p id="rfc.section.7.2.3.p.12">A registration <em class="bcp14">MUST</em> include the following fields:
    14111411      </p>
    14121412      <ul>
     
    14141414         <li>Pointer to specification text</li>
    14151415      </ul>
    1416       <p id="rfc.section.7.2.3.p.11">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
    1417       </p>
    1418       <p id="rfc.section.7.2.3.p.12">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt;.
     1416      <p id="rfc.section.7.2.3.p.13">Values to be added to this name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
     1417      </p>
     1418      <p id="rfc.section.7.2.3.p.14">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt;.
    14191419      </p>
    14201420      <div id="rfc.iref.e.2"></div>
    14211421      <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>
    1422       <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 Model">Section&nbsp;4.1</a> for further discussion of the freshness model.
     1422      <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.
    14231423      </p>
    14241424      <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
     
    15701570         retrieved earlier in a session.
    15711571      </p>
    1572       <p id="rfc.section.8.p.2">The freshness model (<a href="#expiration.model" title="Freshness Model">Section&nbsp;4.1</a>) does not necessarily apply to history mechanisms. I.e., a history mechanism can display a previous representation even if
     1572      <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
    15731573         it has expired.
    15741574      </p>
     
    17661766                  <td class="left">http</td>
    17671767                  <td class="left">standard</td>
    1768                   <td class="left"> <a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;7.4</a>
     1768                  <td class="left"> <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;7.4</a>
    17691769                  </td>
    17701770               </tr>
     
    19001900         (<a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>)
    19011901      </p>
    1902       <p id="rfc.section.A.p.4">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 Model">Section&nbsp;4.2</a>)
     1902      <p id="rfc.section.A.p.4">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>)
    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
     
    19141914         (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section&nbsp;7.3</a>)
    19151915      </p>
    1916       <p id="rfc.section.A.p.10">The Pragma header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.4" title="Pragma">Section&nbsp;7.4</a>)
     1916      <p id="rfc.section.A.p.10">The Pragma header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section&nbsp;7.4</a>)
    19171917      </p>
    19181918      <p id="rfc.section.A.p.11">Cache directives are explicitly defined to be case-insensitive. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;7.2</a>)
     
    20732073            </li>
    20742074            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    2075                   <li>age&nbsp;&nbsp;<a href="#rfc.iref.a.1">1.2</a></li>
     2075                  <li>age&nbsp;&nbsp;<a href="#rfc.iref.a.1">1.1</a></li>
    20762076                  <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>
    20772077               </ul>
     
    20822082            </li>
    20832083            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    2084                   <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.1">1.1</a>, <a href="#rfc.iref.c.2">1.2</a></li>
     2084                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a>, <a href="#rfc.iref.c.2">1.1</a></li>
    20852085                  <li>cache entry&nbsp;&nbsp;<a href="#rfc.iref.c.4">2</a></li>
    20862086                  <li>cache key&nbsp;&nbsp;<a href="#rfc.iref.c.5">2</a></li>
    20872087                  <li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.6"><b>7.2</b></a>, <a href="#rfc.xref.header.cache-control.2">9.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a>, <a href="#rfc.xref.header.cache-control.4">A</a></li>
    2088                   <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.3">1.2</a></li>
     2088                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.3">1.1</a></li>
    20892089               </ul>
    20902090            </li>
    20912091            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    20922092                  <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>
    2093                   <li>explicit expiration time&nbsp;&nbsp;<a href="#rfc.iref.e.1">1.2</a></li>
     2093                  <li>explicit expiration time&nbsp;&nbsp;<a href="#rfc.iref.e.1">1.1</a></li>
    20942094               </ul>
    20952095            </li>
    20962096            <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul>
    2097                   <li>first-hand&nbsp;&nbsp;<a href="#rfc.iref.f.1">1.2</a></li>
    2098                   <li>fresh&nbsp;&nbsp;<a href="#rfc.iref.f.3">1.2</a></li>
    2099                   <li>freshness lifetime&nbsp;&nbsp;<a href="#rfc.iref.f.2">1.2</a></li>
     2097                  <li>first-hand&nbsp;&nbsp;<a href="#rfc.iref.f.1">1.1</a></li>
     2098                  <li>fresh&nbsp;&nbsp;<a href="#rfc.iref.f.3">1.1</a></li>
     2099                  <li>freshness lifetime&nbsp;&nbsp;<a href="#rfc.iref.f.2">1.1</a></li>
    21002100               </ul>
    21012101            </li>
     
    21062106                        <li><tt>Cache-Control</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>7.2</b></a></li>
    21072107                        <li><tt>cache-directive</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>7.2</b></a></li>
    2108                         <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.4.1</b></a></li>
     2108                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.3.1</b></a></li>
    21092109                        <li><tt>Expires</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>7.3</b></a></li>
    21102110                        <li><tt>extension-pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>7.4</b></a></li>
     
    21222122            </li>
    21232123            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
    2124                   <li>heuristic expiration time&nbsp;&nbsp;<a href="#rfc.iref.h.1">1.2</a></li>
     2124                  <li>heuristic expiration time&nbsp;&nbsp;<a href="#rfc.iref.h.1">1.1</a></li>
    21252125               </ul>
    21262126            </li>
     
    21432143            </li>
    21442144            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2145                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.4</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.9</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>
    2146                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.4</a>, <a href="#rfc.xref.Part1.21">C</a></li>
    2147                         <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a></li>
     2145                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.3</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.9</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>
     2146                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.3</a>, <a href="#rfc.xref.Part1.21">C</a></li>
     2147                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.2</a></li>
    21482148                        <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>
    21492149                        <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>
     
    21642164                     </ul>
    21652165                  </li>
    2166                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2</a>, <a href="#rfc.xref.Part4.2">1.2</a>, <a href="#rfc.xref.Part4.3">1.2</a>, <a href="#rfc.xref.Part4.4">4.1.2</a>, <a href="#rfc.xref.Part4.5">4.2</a>, <a href="#Part4"><b>12.1</b></a><ul>
    2167                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2</a></li>
    2168                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">4.1.2</a></li>
    2169                         <li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">1.2</a></li>
    2170                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">1.2</a></li>
     2166                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.1</a>, <a href="#rfc.xref.Part4.2">4.1.2</a>, <a href="#rfc.xref.Part4.3">4.2</a>, <a href="#Part4"><b>12.1</b></a><ul>
     2167                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.1</a></li>
     2168                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">4.1.2</a></li>
    21712169                     </ul>
    21722170                  </li>
     
    21792177                     </ul>
    21802178                  </li>
    2181                   <li>Pragma header field&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.xref.header.pragma.2">7.2</a>, <a href="#rfc.iref.p.5"><b>7.4</b></a>, <a href="#rfc.xref.header.pragma.3">9.3</a>, <a href="#rfc.xref.header.pragma.4">A</a></li>
     2179                  <li>Pragma header field&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">4</a>, <a href="#rfc.iref.p.5"><b>7.4</b></a>, <a href="#rfc.xref.header.pragma.2">9.3</a>, <a href="#rfc.xref.header.pragma.3">A</a></li>
    21822180                  <li>private (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>7.2.2.2</b></a></li>
    2183                   <li>private cache&nbsp;&nbsp;<a href="#rfc.iref.p.1">1.2</a></li>
     2181                  <li>private cache&nbsp;&nbsp;<a href="#rfc.iref.p.1">1.1</a></li>
    21842182                  <li>proxy-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.4"><b>7.2.2.6</b></a></li>
    21852183                  <li>public (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>7.2.2.1</b></a></li>
     
    21882186            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    21892187                  <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>
    2190                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.3</a>, <a href="#RFC2119"><b>12.1</b></a></li>
     2188                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.2</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    21912189                  <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>
    21922190                        <li><em>Section 13.9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.1.2</a></li>
     
    21972195                     </ul>
    21982196                  </li>
    2199                   <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.4</a>, <a href="#RFC5234"><b>12.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul>
     2197                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.3</a>, <a href="#RFC5234"><b>12.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul>
    22002198                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li>
    22012199                     </ul>
     
    22112209            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
    22122210                  <li>s-maxage (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>7.2.2.8</b></a></li>
    2213                   <li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1.2</a></li>
    2214                   <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">1.2</a></li>
    2215                   <li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">1.2</a></li>
     2211                  <li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1.1</a></li>
     2212                  <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">1.1</a></li>
     2213                  <li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">1.1</a></li>
    22162214               </ul>
    22172215            </li>
    22182216            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    2219                   <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">1.2</a><ul>
    2220                         <li>strong&nbsp;&nbsp;<a href="#rfc.iref.v.2">1.2</a></li>
     2217                  <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">1.1</a><ul>
     2218                        <li>strong&nbsp;&nbsp;<a href="#rfc.iref.v.2">1.1</a></li>
    22212219                     </ul>
    22222220                  </li>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2232 r2234  
    144144</t>
    145145
    146 <section anchor="intro.purpose" title="Purpose">
    147146<iref item="cache" />
    148147<t>
    149148   An HTTP <x:dfn>cache</x:dfn> is a local store of response messages and the
    150    subsystem that controls its message storage, retrieval, and deletion. A
    151    cache stores cacheable responses in order to reduce the response time and
     149   subsystem that controls storage, retrieval, and deletion of messages in it.
     150   A cache stores cacheable responses in order to reduce the response time and
    152151   network bandwidth consumption on future, equivalent requests. Any client or
    153152   server &MAY; employ a cache, though a cache cannot be used by a server that
     
    160159   <xref target="expiration.model" />, if the response can be reused without
    161160   "validation" (checking with the origin server to see if the cached response
    162    remains valid for this request).  A fresh cache response can therefore
    163    reduce both latency and network transfers each time it is reused.
     161   remains valid for this request).  A fresh response can therefore
     162   reduce both latency and network overhead each time it is reused.
    164163   When a cached response is not fresh, it might still be reusable if it can
    165164   be freshened by validation (<xref target="validation.model" />) or if the
    166    origin is unavailable.
    167 </t>
    168 </section>
     165   origin is unavailable (xref target="serving.stale.responses" />).
     166</t>
    169167
    170168<section anchor="intro.terminology" title="Terminology">
     
    227225   <x:dfn>age</x:dfn>
    228226   <list>
    229       <t>The age of a response is the time since it was sent by, or
    230       successfully validated with, the origin server.</t>
     227      <t>The time since a response was sent by, or successfully validated
     228      with, the origin server.</t>
    231229   </list>
    232230</t>
     
    244242   <list>
    245243      <t>The length of time between the generation of a response and its
    246       expiration time.</t>
     244      expiration time (either explicit or heuristic).</t>
    247245   </list>
    248246</t>
     
    259257   <x:dfn>stale</x:dfn>
    260258   <list>
    261       <t>A response is stale if its age has passed its freshness lifetime
    262       (either explicit or heuristic).</t>
     259      <t>A response is stale if its age has passed its freshness lifetime.</t>
    263260   </list>
    264261</t>
     
    267264   <x:dfn>validator</x:dfn>
    268265   <list>
    269       <t>A protocol element (e.g., an entity-tag or a <x:ref>Last-Modified</x:ref>
    270       time) that is used to find out whether a stored response is an equivalent
    271       copy of a representation. See &weak-and-strong;.</t>
     266      <t>A protocol element (e.g., an entity-tag or a
     267      <x:ref>Last-Modified</x:ref> time) that is used to find out whether a
     268      stored response is an equivalent copy of a representation. .</t>
    272269   </list>
    273270</t>
     
    278275   <list>
    279276      <t>A validator that is defined by the origin server such that its
    280          current value will change if the representation data changes; i.e.,
    281          an entity-tag that is not marked as weak (&entity-tags;) or,
    282          if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value
    283          that is strong in the sense defined by &lastmod-comparison;.</t>
     277         current value will change if the representation data changes.
     278         See &weak-and-strong;</t>
    284279   </list>
    285280</t>
     
    336331   in the cache.  Although caching is an entirely &OPTIONAL; feature of HTTP,
    337332   we assume that reusing the cached response is desirable and that such
    338    reuse is the default behavior when no requirement or locally-desired
     333   reuse is the default behavior when no requirement or local
    339334   configuration prevents it.  Therefore, HTTP cache requirements are focused
    340335   on preventing a cache from either storing a non-reusable response or
    341    reusing a stored response inappropriately.
     336   reusing a stored response inappropriately, rather than mandating that
     337   caches always store and reuse particular responses.
    342338</t>
    343339<t>
     
    354350</t>
    355351<t>
    356    The default <x:dfn>cache key</x:dfn> consists of the request method and
     352   The primary <x:dfn>cache key</x:dfn> consists of the request method and
    357353   target URI.  However, since HTTP caches in common use today are typically
    358354   limited to caching responses to GET, many implementations simply decline
    359    other methods and use only the URI as the key.
     355   other methods and use only the URI as the primary cache key.
    360356</t>
    361357<t>
     
    390386            <t>contains a max-age response cache directive (see <xref
    391387            target="cache-response-directive.max-age" />), or</t>
    392             <t>contains a s-maxage response cache directive and the cache is
     388            <t>contains a s-maxage response cache directive (see <xref
     389            target="cache-response-directive.s-maxage" />) and the cache is
    393390            shared, or</t>
    394391            <t>contains a Cache Control Extension (see <xref
     
    409406<t>
    410407   In this context, a cache has "understood" a request method or a response
    411    status code if it recognizes it and implements any cache-specific
    412    behavior.
    413 </t>
    414 <t>
    415    Note that, in normal operation, many caches will not store a response that
     408   status code if it recognizes it and implements all specified
     409   caching-related behavior.
     410</t>
     411<t>
     412   Note that, in normal operation, some caches will not store a response that
    416413   has neither a cache validator nor an explicit expiration time, as such
    417414   responses are not usually useful to store. However, caches are not
     
    474471   title="Constructing Responses from Caches">
    475472<t>
    476    For a presented request, a cache &MUST-NOT; send a stored response,
     473   When presented with a request, a cache &MUST-NOT; reuse a stored response,
    477474   unless:
    478475   <list style="symbols">
     
    507504</t>
    508505<t>
    509    When a stored response is used to satisfy a request without validation,
    510    a cache &MUST; send a single <x:ref>Age</x:ref> header field
    511    (<xref target="header.age"/>) in the response with a value equal to the
    512    stored response's current_age; see <xref target="age.calculations" />.
     506   When a stored response is used to satisfy a request without validation, a
     507   cache &MUST; generate an <x:ref>Age</x:ref> header field (<xref
     508   target="header.age"/>), replacing any present in the response with a value
     509   equal to the stored response's current_age; see <xref
     510   target="age.calculations" />.
    513511</t>
    514512<t>
     
    525523   When more than one suitable response is stored, a cache &MUST; use the
    526524   most recent response (as determined by the <x:ref>Date</x:ref> header
    527    field). It can also forward a request with "Cache-Control: max-age=0" or
     525   field). It can also forward the request with "Cache-Control: max-age=0" or
    528526   "Cache-Control: no-cache" to disambiguate which response to use.
    529527</t>
    530528<t>
    531529   A cache that does not have a clock available &MUST-NOT; use stored
    532    responses without revalidating them on every use.
    533 </t>
    534 
    535 
    536 <section anchor="expiration.model" title="Freshness Model">
     530   responses without revalidating them upon every use.
     531</t>
     532
     533
     534<section anchor="expiration.model" title="Freshness">
    537535<t>
    538536   When a response is "fresh" in the cache, it can be used to satisfy
     
    571569</figure>
    572570<t>
    573    The freshness_lifetime is defined in <xref
    574    target="calculating.freshness.lifetime" />; the current_age is defined in
     571   freshness_lifetime is defined in <xref
     572   target="calculating.freshness.lifetime" />; current_age is defined in
    575573   <xref target="age.calculations" />.
    576574</t>
     
    613611   When there is more than one value present for a given directive (e.g., two
    614612   <x:ref>Expires</x:ref> header fields, multiple Cache-Control: max-age
    615    directives), it is considered invalid. Caches are encouraged to consider
    616    responses that have invalid freshness information to be stale.
     613   directives), the directive's value is considered invalid. Caches are
     614   encouraged to consider responses that have invalid freshness information to
     615   be stale.
    617616</t>
    618617</section>
     
    653652      from calculating heuristic freshness for URIs with query components
    654653      (i.e., those containing '?'). In practice, this has not been widely
    655       implemented. Therefore, servers are encouraged to send explicit
     654      implemented. Therefore, origin servers are encouraged to send explicit
    656655      directives (e.g., Cache-Control: no-cache) if they wish to preclude
    657656      caching.
     
    811810</t>
    812811<t>
    813    If a cache receives a first-hand response (either an entire response, or a
    814    <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward
    815    to the requesting client, and the received response is no longer fresh, the
    816    cache can forward it to the requesting client without adding a new
    817    <x:ref>Warning</x:ref> (but without removing any existing Warning header
    818    fields). A cache shouldn't attempt to validate a response simply because
    819    that response became stale in transit.
    820 </t>
    821 </section>
    822 </section>
    823 
    824 <section anchor="validation.model" title="Validation Model">
     812   note that if a cache receives a first-hand response (either an entire
     813   response, or a <x:ref>304 (Not Modified)</x:ref> response) that it would
     814   normally forward to the requesting client, and the received response is no
     815   longer fresh, the cache can forward it to the requesting client without
     816   adding a new <x:ref>Warning</x:ref> (but without removing any existing
     817   Warning header fields). A cache shouldn't attempt to validate a response
     818   simply because that response became stale in transit.
     819</t>
     820</section>
     821</section>
     822
     823<section anchor="validation.model" title="Validation">
    825824<t>
    826825   When a cache has one or more stored responses for a requested URI, but
     
    841840<t>
    842841   Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field
    843    whose value is that of the <x:ref>ETag</x:ref> header field(s) from all
    844    responses stored for the requested URI, if present. However, if any of the
    845    stored responses contains only partial content, the cache shouldn't
    846    include its entity-tag in the If-None-Match header field unless the request
    847    is for a range that would be fully satisfied by that stored response.
     842   whose value is that of the <x:ref>ETag</x:ref> header field(s) from
     843   relevant responses stored for the primary cache key, if present. However,
     844   if any of the stored responses contains only partial content, the cache
     845   shouldn't include its entity-tag in the If-None-Match header field unless
     846   the request is for a range that would be fully satisfied by that stored
     847   response.
    848848</t>
    849849
     
    889889    <t>
    890890     If the new response contains a strong validator, then that strong
    891      validator identifies the selected representation.  All of the stored
    892      responses with the same strong validator are selected.
    893      If none of the stored responses contain the same strong validator,
    894      then the new response &MUST-NOT; be used to update any stored responses.
     891     validator identifies the selected representation for update. All of the
     892     stored responses with the same strong validator are selected. If none of
     893     the stored responses contain the same strong validator, then the new
     894     response &MUST-NOT; be used to update any stored responses.
    895895    </t>
    896896    <t>
    897897     If the new response contains a weak validator and that validator
    898898     corresponds to one of the cache's stored responses, then the most
    899      recent of those matching stored responses is selected.
     899     recent of those matching stored responses is selected for update.
    900900    </t>
    901901    <t>
     
    904904     source other than the Last-Modified response header field), and there is
    905905     only one stored response, and that stored response also lacks a
    906      validator, then that stored response is selected.
     906     validator, then that stored response is selected for update.
    907907    </t>
    908908   </list>
     
    10791079<t>
    10801080   Note that this does not guarantee that all appropriate responses are
    1081    invalidated. For example, the request that caused the change at the origin
    1082    server might not have gone through the cache where a response is stored.
    1083 </t>
     1081   invalidated. For example, a state-changing request might invalidate
     1082   responses in the caches it travels through, but relevant responses still
     1083   might be stored in other caches that it has not.</t>
    10841084</section>
    10851085
     
    11351135<x:note>
    11361136   <t>
    1137        &Note; HTTP/1.0 caches might not implement Cache-Control and
    1138        might only implement Pragma: no-cache (see <xref target="header.pragma"
    1139        />).
     1137       &Note; some HTTP/1.0 caches might not implement Cache-Control.
    11401138   </t>
    11411139</x:note>
     
    12351233<t>
    12361234   The "max-stale" request directive indicates that the client is willing
    1237    to accept a response that has exceeded its expiration time. If max-stale
     1235   to accept a response that has exceeded its freshness lifetime. If max-stale
    12381236   is assigned a value, then the client is willing to accept a response
    1239    that has exceeded its expiration time by no more than the specified
     1237   that has exceeded its freshness lifetime by no more than the specified
    12401238   number of seconds. If no value is assigned to max-stale, then the client
    12411239   is willing to accept a stale response of any age.
     
    13371335</t>
    13381336<t>
    1339    The field-names given are not limited to the set of standard header
     1337   The field-names given are not limited to the set of header
    13401338   fields defined by this specification. Field names are case-insensitive.
    13411339</t>
     
    13831381</t>
    13841382<t>
    1385    The field-names given are not limited to the set of standard header
     1383   The field-names given are not limited to the set of header
    13861384   fields defined by this specification. Field names are case-insensitive.
    13871385</t>
    13881386<t>
    1389    &Note; Many HTTP/1.0 caches will not recognize or obey
    1390    this directive. Also, no-cache response directives with field-names are
    1391    often handled by implementations as if an unqualified no-cache directive
    1392    was received; i.e., the special handling for the qualified form is not
    1393    widely implemented.
     1387   &Note; Although it has been back-ported to many implementations, some
     1388   HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache
     1389   response directives with field-names are often handled by implementations
     1390   as if an unqualified no-cache directive was received; i.e., the special
     1391   handling for the qualified form is not widely implemented.
    13941392</t>
    13951393<t>
     
    15101508<t>
    15111509   The Cache-Control header field can be extended through the use of one or
    1512    more cache-extension tokens, each with an optional value. Informational
    1513    extensions (those that do not require a change in cache behavior) can be
    1514    added without changing the semantics of other directives. Behavioral
    1515    extensions are designed to work by acting as modifiers to the existing base
    1516    of cache directives. Both the new directive and the standard directive are
    1517    supplied, such that applications that do not understand the new directive
    1518    will default to the behavior specified by the standard directive, and those
    1519    that understand the new directive will recognize it as modifying the
    1520    requirements associated with the standard directive. In this way,
    1521    extensions to the cache-control directives can be made without requiring
    1522    changes to the base protocol.
     1510   more cache-extension tokens, each with an optional value.
     1511</t>
     1512<t>
     1513   Informational extensions (those that do not require a change in cache
     1514   behavior) can be added without changing the semantics of other directives.
     1515   Behavioral extensions are designed to work by acting as modifiers to the
     1516   existing base of cache directives.
     1517</t>
     1518<t>   
     1519   Both the new directive and the standard directive are supplied, such that
     1520   applications that do not understand the new directive will default to the
     1521   behavior specified by the standard directive, and those that understand the
     1522   new directive will recognize it as modifying the requirements associated
     1523   with the standard directive. In this way, extensions to the cache-control
     1524   directives can be made without requiring changes to the base protocol.
    15231525</t>
    15241526<t>
     
    15611563      argument is present,</t>
    15621564      <t>When the directive requires an argument, what it means when it is
    1563       missing.</t>
     1565      missing,</t>
     1566      <t>Whether the directive is specific to requests, responses, or able
     1567        to be used in either.</t>
    15641568   </list>
    15651569</t>
Note: See TracChangeset for help on using the changeset viewer.