Ignore:
Timestamp:
07/05/13 07:14:23 (9 years ago)
Author:
mnot@…
Message:

Distribute terminology throughout text; see #469

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

Legend:

Unmodified
Added
Removed

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

    r2238 r2239  
    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.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>
     580               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#conformance">Conformance and Error Handling</a></li>
     581               <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
     582                     <li><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#delta-seconds">Delta Seconds</a></li>
    584583                  </ul>
    585584               </li>
    … …  
    689688         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.
    690689      </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
     690      <div id="rfc.iref.s.1"></div>
     691      <div id="rfc.iref.p.1"></div>
     692      <div id="shared.and.non-shared.caches">
     693         <p id="rfc.section.1.p.3">A <dfn>shared cache</dfn> is a cache that stores responses to be reused by more than one user; shared caches are usually (but not always) deployed as
     694            a part of an intermediary. A <dfn>private cache</dfn>, in contrast, is dedicated to a single user.
     695         </p>
     696      </div>
     697      <p id="rfc.section.1.p.4">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current
    692698         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
    693699         valid for this request). A fresh response can therefore reduce both latency and network overhead each time it is reused. When
    694700         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;).
    695701      </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> 
    699       </p>
    700       <ul class="empty">
    701          <li>A conformant implementation of an HTTP cache. Note that this implies an HTTP/1.1 cache; this specification does not define
    702             conformance for HTTP/1.0 caches.
    703          </li>
    704       </ul>
    705       <div id="shared.and.non-shared.caches">
    706          <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.s.1"></span>  <dfn>shared cache</dfn> 
    707          </p>
    708          <ul class="empty">
    709             <li>A cache that stores responses to be reused by more than one user; usually (but not always) deployed as part of an intermediary.</li>
    710          </ul>
    711       </div>
    712       <p id="rfc.section.1.1.p.4"> <span id="rfc.iref.p.1"></span>  <dfn>private cache</dfn> 
    713       </p>
    714       <ul class="empty">
    715          <li>A cache that is dedicated to a single user.</li>
    716       </ul>
    717       <p id="rfc.section.1.1.p.5"> <span id="rfc.iref.c.3"></span>  <dfn>cacheable</dfn> 
    718       </p>
    719       <ul class="empty">
    720          <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    721             Even when a response is cacheable, there might be additional constraints on whether a cache can use the stored copy to satisfy
    722             a particular request.
    723          </li>
    724       </ul>
    725       <p id="rfc.section.1.1.p.6"> <span id="rfc.iref.e.1"></span>  <dfn>explicit expiration time</dfn> 
    726       </p>
    727       <ul class="empty">
    728          <li>The time at which the origin server intends that a stored response no longer be used by a cache without further validation.</li>
    729       </ul>
    730       <p id="rfc.section.1.1.p.7"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
    731       </p>
    732       <ul class="empty">
    733          <li>An expiration time assigned by a cache when no explicit expiration time is available.</li>
    734       </ul>
    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> 
    741       </p>
    742       <ul class="empty">
    743          <li>A response is first-hand if the freshness model is not in use; i.e., its age is 0.</li>
    744       </ul>
    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> 
    751       </p>
    752       <ul class="empty">
    753          <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li>
    754       </ul>
    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"
     702      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="conformance" href="#conformance">Conformance and Error Handling</a></h2>
     703      <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    774704         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>.
    775705      </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>
     706      <p id="rfc.section.1.1.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>.
     707      </p>
     708      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
     709      <p id="rfc.section.1.2.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.
     710      </p>
     711      <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a>&nbsp;<a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h3>
     712      <p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p>
    783713      <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>
    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
     714</pre><p id="rfc.section.1.2.1.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of
    785715         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.
    786716      </p>
    787       <div id="rfc.iref.c.4"></div>
    788       <div id="rfc.iref.c.5"></div>
     717      <div id="rfc.iref.c.2"></div>
     718      <div id="rfc.iref.c.3"></div>
    789719      <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>
    790720      <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
    … …  
    797727         use as a cache key.
    798728      </p>
     729      <div id="rfc.iref.c.4"></div>
    799730      <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
    800731         responses to GET, many implementations simply decline other methods and use only the URI as the primary cache key.
    … …  
    910841      <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.
    911842      </p>
     843      <div id="rfc.iref.f.1"></div>
     844      <div id="rfc.iref.s.2"></div>
    912845      <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>
    913       <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,
     846      <p id="rfc.section.4.1.p.1">A <dfn>fresh</dfn> response is one whose age has not yet exceeded its freshness lifetime. Conversely, a <dfn>stale</dfn> response is one where it has.
     847      </p>
     848      <div id="rfc.iref.f.2"></div>
     849      <div id="rfc.iref.e.1"></div>
     850      <div id="rfc.iref.h.1"></div>
     851      <p id="rfc.section.4.1.p.2">A response's <dfn>freshness lifetime</dfn> is the length of time between its generation by the origin server and its expiration time. An <dfn>explicit expiration time</dfn> is the time at which the origin server intends that a stored response can no longer be used by a cache without further validation,
     852         whereas a <dfn>heuristic expiration time</dfn> is assigned by a cache when no explicit expiriation time is available.
     853      </p>
     854      <div id="rfc.iref.a.1"></div>
     855      <p id="rfc.section.4.1.p.3">A response's <dfn>age</dfn> is the time that has passed since it was generated by, or successfully validated with, the origin server.
     856      </p>
     857      <p id="rfc.section.4.1.p.4">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server,
    914858         thereby improving efficiency.
    915859      </p>
    916       <p id="rfc.section.4.1.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
     860      <p id="rfc.section.4.1.p.5">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
    917861         using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;7.3</a>) or the max-age response cache directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.8</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
    918862         is not likely to change in a semantically significant way before the expiration time is reached.
    919863      </p>
    920       <p id="rfc.section.4.1.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past
     864      <p id="rfc.section.4.1.p.6">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past
    921865         to indicate that the response is already stale. Compliant caches will normally validate a stale cached response before reusing
    922866         it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.1.4</a>).
    923867      </p>
    924       <p id="rfc.section.4.1.p.4">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine
     868      <p id="rfc.section.4.1.p.7">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine
    925869         an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>).
    926870      </p>
    927871      <div id="rfc.figure.u.2"></div>
    928872      <p>The calculation to determine if a response is fresh is:</p><pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
    929 </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>.
    930       </p>
    931       <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
     873</pre><p id="rfc.section.4.1.p.9">freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;4.1.1</a>; current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
     874      </p>
     875      <p id="rfc.section.4.1.p.10">Clients can send the max-age or min-fresh cache directives in a request to constrain or relax freshness calculations for the
    932876         corresponding response (<a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
    933877      </p>
    934       <p id="rfc.section.4.1.p.8">When calculating freshness, to avoid common problems in date parsing:</p>
    935       <p id="rfc.section.4.1.p.9"> </p>
     878      <p id="rfc.section.4.1.p.11">When calculating freshness, to avoid common problems in date parsing:</p>
     879      <p id="rfc.section.4.1.p.12"> </p>
    936880      <ul>
    937881         <li>Although all date formats are specified to be case-sensitive, cache recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
    … …  
    944888         </li>
    945889      </ul>
    946       <p id="rfc.section.4.1.p.10">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
     890      <p id="rfc.section.4.1.p.13">Note that freshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
    947891         a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;8</a> for an explanation of the difference between caches and history mechanisms.
    948892      </p>
    … …  
    973917         "public" response cache directive).
    974918      </p>
    975       <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
     919      <p id="rfc.section.4.1.2.p.3">If the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
    976920         time. A typical setting of this fraction might be 10%.
    977921      </p>
    … …  
    1055999      <p id="rfc.section.4.1.4.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;7.5</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
    10561000      </p>
    1057       <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
     1001      <div id="rfc.iref.f.3"></div>
     1002      <p id="rfc.section.4.1.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache
    10581003         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
    10591004         that response became stale in transit.
    … …  
    10611006      <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>
    10621007      <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
    1063          fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to
     1008         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to
    10641009         update it. This process is known as "validating" or "revalidating" the stored response.
    10651010      </p>
    1066       <p id="rfc.section.4.2.p.2">When sending such a conditional request, a cache adds an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>) stored response, if available.
    1067       </p>
    1068       <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
     1011      <div id="rfc.iref.v.1"></div>
     1012      <p id="rfc.section.4.2.p.2">When sending such a conditional request, a cache adds a <dfn>validator</dfn> (or more than one), that is used to find out whether a stored response is an equivalent copy of a current representation of
     1013         the resource.
     1014      </p>
     1015      <p id="rfc.section.4.2.p.3">One such validator is the <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field, whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>) stored response, if available.
     1016      </p>
     1017      <p id="rfc.section.4.2.p.4">Another is the <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field, whose value is that of the <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field(s) from relevant responses stored for the primary cache key, if present. However, if any of the stored responses
    10691018         contains only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request
    10701019         is for a range that would be fully satisfied by that stored response.
    10711020      </p>
    1072       <p id="rfc.section.4.2.p.4">Cache handling of a response to a conditional request is dependent upon its status code:</p>
    1073       <p id="rfc.section.4.2.p.5"> </p>
     1021      <p id="rfc.section.4.2.p.5">Cache handling of a response to a conditional request is dependent upon its status code:</p>
     1022      <p id="rfc.section.4.2.p.6"> </p>
    10741023      <ul>
    10751024         <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Stored Responses upon Validation">Section&nbsp;4.2.1</a>.
    … …  
    10861035         and then update the stored response(s) with the new information provided in the <a href="p4-conditional.html#status.304" class="smpl">304</a> response.
    10871036      </p>
     1037      <div id="rfc.iref.s.3"></div>
    10881038      <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>
    10891039      <ul>
    1090          <li>If the new response contains a strong validator, then that strong validator identifies the selected representation for update.
    1091             All of the stored responses with the same strong validator are selected. If none of the stored responses contain the same
    1092             strong validator, then the new response <em class="bcp14">MUST NOT</em> be used to update any stored responses.
     1040         <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), then that strong validator identifies the selected representation for update. All of the stored responses with the same
     1041            strong validator are selected. If none of the stored responses contain the same strong validator, then the new response <em class="bcp14">MUST NOT</em> be used to update any stored responses.
    10931042         </li>
    10941043         <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then
    … …  
    11801129      </p>
    11811130      <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.3.1</a>).
     1131</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.2.1</a>).
    11831132      </p>
    11841133      <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
    11851134         true, since HTTP/1.0 caches might not implement the Age header field.
    11861135      </p>
    1187       <div id="rfc.iref.c.6"></div>
     1136      <div id="rfc.iref.c.5"></div>
    11881137      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
    11891138      <p id="rfc.section.7.2.p.1">The "Cache-Control" header field is used to specify directives for caches along the request/response chain. Such cache directives
    … …  
    12141163      <p id="rfc.section.7.2.1.1.p.1">Argument syntax: </p>
    12151164      <ul class="empty">
    1216          <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.3.1</a>)
     1165         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    12171166         </li>
    12181167      </ul>
    … …  
    12271176      <p id="rfc.section.7.2.1.2.p.1">Argument syntax: </p>
    12281177      <ul class="empty">
    1229          <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.3.1</a>)
     1178         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    12301179         </li>
    12311180      </ul>
    … …  
    12411190      <p id="rfc.section.7.2.1.3.p.1">Argument syntax: </p>
    12421191      <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.3.1</a>)
     1192         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    12441193         </li>
    12451194      </ul>
    … …  
    13511300      <p id="rfc.section.7.2.2.8.p.1">Argument syntax: </p>
    13521301      <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.3.1</a>)
     1302         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    13541303         </li>
    13551304      </ul>
    … …  
    13631312      <p id="rfc.section.7.2.2.9.p.1">Argument syntax: </p>
    13641313      <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.3.1</a>)
     1314         <li> <a href="#delta-seconds" class="smpl">delta-seconds</a> (see <a href="#delta-seconds" title="Delta Seconds">Section&nbsp;1.2.1</a>)
    13661315         </li>
    13671316      </ul>
    … …  
    15221471         of its meaning.
    15231472      </p>
    1524       <div id="rfc.iref.52"></div>
     1473      <div id="rfc.iref.50"></div>
    15251474      <h3 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a>&nbsp;<a id="warn.110" href="#warn.110">110 Response is Stale</a></h3>
    15261475      <p id="rfc.section.7.5.1.p.1">A cache <em class="bcp14">SHOULD</em> generate this whenever the sent response is stale.
    15271476      </p>
    1528       <div id="rfc.iref.52"></div>
     1477      <div id="rfc.iref.50"></div>
    15291478      <h3 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a>&nbsp;<a id="warn.111" href="#warn.111">111 Revalidation Failed</a></h3>
    15301479      <p id="rfc.section.7.5.2.p.1">A cache <em class="bcp14">SHOULD</em> generate this when sending a stale response because an attempt to validate the response failed, due to an inability to reach
    15311480         the server.
    15321481      </p>
    1533       <div id="rfc.iref.52"></div>
     1482      <div id="rfc.iref.50"></div>
    15341483      <h3 id="rfc.section.7.5.3"><a href="#rfc.section.7.5.3">7.5.3</a>&nbsp;<a id="warn.112" href="#warn.112">112 Disconnected Operation</a></h3>
    15351484      <p id="rfc.section.7.5.3.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it is intentionally disconnected from the rest of the network for a period of time.
    15361485      </p>
    1537       <div id="rfc.iref.52"></div>
     1486      <div id="rfc.iref.50"></div>
    15381487      <h3 id="rfc.section.7.5.4"><a href="#rfc.section.7.5.4">7.5.4</a>&nbsp;<a id="warn.113" href="#warn.113">113 Heuristic Expiration</a></h3>
    15391488      <p id="rfc.section.7.5.4.p.1">A cache <em class="bcp14">SHOULD</em> generate this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than
    15401489         24 hours.
    15411490      </p>
    1542       <div id="rfc.iref.52"></div>
     1491      <div id="rfc.iref.50"></div>
    15431492      <h3 id="rfc.section.7.5.5"><a href="#rfc.section.7.5.5">7.5.5</a>&nbsp;<a id="warn.199" href="#warn.199">199 Miscellaneous Warning</a></h3>
    15441493      <p id="rfc.section.7.5.5.p.1">The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.
    15451494      </p>
    1546       <div id="rfc.iref.52"></div>
     1495      <div id="rfc.iref.50"></div>
    15471496      <h3 id="rfc.section.7.5.6"><a href="#rfc.section.7.5.6">7.5.6</a>&nbsp;<a id="warn.214" href="#warn.214">214 Transformation Applied</a></h3>
    15481497      <p id="rfc.section.7.5.6.p.1"> <em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type,
    15491498         or modifying the representation data, unless this Warning code already appears in the response.
    15501499      </p>
    1551       <div id="rfc.iref.52"></div>
     1500      <div id="rfc.iref.50"></div>
    15521501      <h3 id="rfc.section.7.5.7"><a href="#rfc.section.7.5.7">7.5.7</a>&nbsp;<a id="warn.299" href="#warn.299">299 Miscellaneous Persistent Warning</a></h3>
    15531502      <p id="rfc.section.7.5.7.p.1">The warning text can include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.
    … …  
    20602009         <ul class="ind">
    20612010            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
    2062                   <li>110 Response is Stale (warn code)&nbsp;&nbsp;<a href="#rfc.iref.52"><b>7.5.1</b></a>, <a href="#rfc.xref.warn.110.1">9.2</a></li>
    2063                   <li>111 Revalidation Failed (warn code)&nbsp;&nbsp;<a href="#rfc.iref.52"><b>7.5.2</b></a>, <a href="#rfc.xref.warn.111.1">9.2</a></li>
    2064                   <li>112 Disconnected Operation (warn code)&nbsp;&nbsp;<a href="#rfc.iref.52"><b>7.5.3</b></a>, <a href="#rfc.xref.warn.112.1">9.2</a></li>
    2065                   <li>113 Heuristic Expiration (warn code)&nbsp;&nbsp;<a href="#rfc.iref.52"><b>7.5.4</b></a>, <a href="#rfc.xref.warn.113.1">9.2</a></li>
    2066                   <li>199 Miscellaneous Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.52"><b>7.5.5</b></a>, <a href="#rfc.xref.warn.199.1">9.2</a></li>
     2011                  <li>110 Response is Stale (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.1</b></a>, <a href="#rfc.xref.warn.110.1">9.2</a></li>
     2012                  <li>111 Revalidation Failed (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.2</b></a>, <a href="#rfc.xref.warn.111.1">9.2</a></li>
     2013                  <li>112 Disconnected Operation (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.3</b></a>, <a href="#rfc.xref.warn.112.1">9.2</a></li>
     2014                  <li>113 Heuristic Expiration (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.4</b></a>, <a href="#rfc.xref.warn.113.1">9.2</a></li>
     2015                  <li>199 Miscellaneous Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.5</b></a>, <a href="#rfc.xref.warn.199.1">9.2</a></li>
    20672016               </ul>
    20682017            </li>
    20692018            <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
    2070                   <li>214 Transformation Applied (warn code)&nbsp;&nbsp;<a href="#rfc.iref.52"><b>7.5.6</b></a>, <a href="#rfc.xref.warn.214.1">9.2</a></li>
    2071                   <li>299 Miscellaneous Persistent Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.52"><b>7.5.7</b></a>, <a href="#rfc.xref.warn.299.1">9.2</a></li>
     2019                  <li>214 Transformation Applied (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.6</b></a>, <a href="#rfc.xref.warn.214.1">9.2</a></li>
     2020                  <li>299 Miscellaneous Persistent Warning (warn code)&nbsp;&nbsp;<a href="#rfc.iref.50"><b>7.5.7</b></a>, <a href="#rfc.xref.warn.299.1">9.2</a></li>
    20722021               </ul>
    20732022            </li>
    20742023            <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.1</a></li>
     2024                  <li>age&nbsp;&nbsp;<a href="#rfc.iref.a.1">4.1</a></li>
    20762025                  <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>
    20772026               </ul>
    … …  
    20822031            </li>
    20832032            <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</a>, <a href="#rfc.iref.c.2">1.1</a></li>
    2085                   <li>cache entry&nbsp;&nbsp;<a href="#rfc.iref.c.4">2</a></li>
    2086                   <li>cache key&nbsp;&nbsp;<a href="#rfc.iref.c.5">2</a></li>
    2087                   <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.1</a></li>
     2033                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li>
     2034                  <li>cache entry&nbsp;&nbsp;<a href="#rfc.iref.c.2">2</a></li>
     2035                  <li>cache key&nbsp;&nbsp;<a href="#rfc.iref.c.3">2</a>, <a href="#rfc.iref.c.4">2</a></li>
     2036                  <li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><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>
    20892037               </ul>
    20902038            </li>
    20912039            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul>
    20922040                  <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.1</a></li>
     2041                  <li>explicit expiration time&nbsp;&nbsp;<a href="#rfc.iref.e.1">4.1</a></li>
    20942042               </ul>
    20952043            </li>
    20962044            <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.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>
     2045                  <li>first-hand&nbsp;&nbsp;<a href="#rfc.iref.f.3">4.1.4</a></li>
     2046                  <li>fresh&nbsp;&nbsp;<a href="#rfc.iref.f.1">4.1</a></li>
     2047                  <li>freshness lifetime&nbsp;&nbsp;<a href="#rfc.iref.f.2">4.1</a></li>
    21002048               </ul>
    21012049            </li>
    … …  
    21062054                        <li><tt>Cache-Control</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>7.2</b></a></li>
    21072055                        <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.3.1</b></a></li>
     2056                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>1.2.1</b></a></li>
    21092057                        <li><tt>Expires</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>7.3</b></a></li>
    21102058                        <li><tt>extension-pragma</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>7.4</b></a></li>
    … …  
    21222070            </li>
    21232071            <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.1</a></li>
     2072                  <li>heuristic expiration time&nbsp;&nbsp;<a href="#rfc.iref.h.1">4.1</a></li>
    21252073               </ul>
    21262074            </li>
    … …  
    21432091            </li>
    21442092            <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.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.4</a>, <a href="#rfc.xref.Part1.11">10</a>, <a href="#rfc.xref.Part1.12">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul>
    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>
     2093                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">3.1</a>, <a href="#rfc.xref.Part1.4">4</a>, <a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#rfc.xref.Part1.9">7.2.1.6</a>, <a href="#rfc.xref.Part1.10">7.2.2.4</a>, <a href="#rfc.xref.Part1.11">10</a>, <a href="#rfc.xref.Part1.12">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">B</a>, <a href="#rfc.xref.Part1.15">B</a>, <a href="#rfc.xref.Part1.16">B</a>, <a href="#rfc.xref.Part1.17">B</a>, <a href="#rfc.xref.Part1.18">B</a>, <a href="#rfc.xref.Part1.19">B</a>, <a href="#rfc.xref.Part1.20">B</a>, <a href="#rfc.xref.Part1.21">C</a><ul>
     2094                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.21">C</a></li>
     2095                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
    21482096                        <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>
    21492097                        <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>
    … …  
    21642112                     </ul>
    21652113                  </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>
     2114                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.1.2</a>, <a href="#rfc.xref.Part4.2">4.2</a>, <a href="#rfc.xref.Part4.3">4.2.1</a>, <a href="#Part4"><b>12.1</b></a><ul>
     2115                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">4.2.1</a></li>
     2116                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.1.2</a></li>
    21692117                     </ul>
    21702118                  </li>
    … …  
    21792127                  <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>
    21802128                  <li>private (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>7.2.2.6</b></a></li>
    2181                   <li>private cache&nbsp;&nbsp;<a href="#rfc.iref.p.1">1.1</a></li>
     2129                  <li>private cache&nbsp;&nbsp;<a href="#rfc.iref.p.1">1</a></li>
    21822130                  <li>proxy-revalidate (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.4"><b>7.2.2.7</b></a></li>
    21832131                  <li>public (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>7.2.2.5</b></a></li>
    … …  
    21862134            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    21872135                  <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>
    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>
     2136                  <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li>
    21892137                  <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>
    21902138                        <li><em>Section 13.9</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.1.2</a></li>
    … …  
    21952143                     </ul>
    21962144                  </li>
    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>
     2145                  <li><em>RFC5234</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>12.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul>
    21982146                        <li><em>Appendix B.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5234.2">B</a></li>
    21992147                     </ul>
    … …  
    22092157            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
    22102158                  <li>s-maxage (cache directive)&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>7.2.2.9</b></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>
     2159                  <li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1</a></li>
     2160                  <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">4.1</a></li>
     2161                  <li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">4.2.1</a></li>
    22142162               </ul>
    22152163            </li>
    22162164            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    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>
    2219                      </ul>
    2220                   </li>
     2165                  <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">4.2</a></li>
    22212166               </ul>
    22222167            </li>

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

    r2238 r2239  
    153153   is acting as a tunnel.
    154154</t>
     155<iref item="shared cache" />
     156<iref item="private cache" />
     157<t anchor="shared.and.non-shared.caches">
     158   A <x:dfn>shared cache</x:dfn> is a cache that stores responses to be reused
     159   by more than one user; shared caches are usually (but not always) deployed
     160   as a part of an intermediary. A <x:dfn>private cache</x:dfn>, in contrast,
     161   is dedicated to a single user.
     162</t>
    155163<t>
    156164   The goal of caching in HTTP/1.1 is to significantly improve performance
    … …  
    166174</t>
    167175
    168 <section anchor="intro.terminology" title="Terminology">
    169 <t>
    170    This specification uses a number of terms to refer to the roles played by
    171    participants in, and objects of, HTTP caching.
    172 </t>
    173 <t>
    174    <iref item="cache" />
    175    <x:dfn>cache</x:dfn>
    176    <list>
    177       <t>A conformant implementation of an HTTP cache. Note that this implies
    178         an HTTP/1.1 cache; this specification does not define conformance
    179         for HTTP/1.0 caches.</t>
    180    </list>
    181 </t>
    182 <t anchor="shared.and.non-shared.caches">
    183    <iref item="shared cache" />
    184    <x:dfn>shared cache</x:dfn>
    185    <list>
    186       <t>A cache that stores responses to be reused by more than one user;
    187          usually (but not always) deployed as part of an intermediary.</t>
    188    </list>
    189 </t>
    190 <t>
    191    <iref item="private cache" />
    192    <x:dfn>private cache</x:dfn>
    193    <list>
    194       <t>A cache that is dedicated to a single user.</t>
    195    </list>
    196 </t>
    197 <t>
    198    <iref item="cacheable" />
    199    <x:dfn>cacheable</x:dfn>
    200    <list>
    201       <t>A response is cacheable if a cache is allowed to store a copy of the
    202       response message for use in answering subsequent requests. Even when a
    203       response is cacheable, there might be additional constraints on whether
    204       a cache can use the stored copy to satisfy a particular request.</t>
    205    </list>
    206 </t>
    207 <t>
    208    <iref item="explicit expiration time" />
    209    <x:dfn>explicit expiration time</x:dfn>
    210    <list>
    211       <t>The time at which the origin server intends that a stored response
    212       no longer be used by a cache without further validation.</t>
    213    </list>
    214 </t>
    215 <t>
    216    <iref item="heuristic expiration time" />
    217    <x:dfn>heuristic expiration time</x:dfn>
    218    <list>
    219       <t>An expiration time assigned by a cache when no explicit expiration
    220       time is available.</t>
    221    </list>
    222 </t>
    223 <t>
    224    <iref item="age" />
    225    <x:dfn>age</x:dfn>
    226    <list>
    227       <t>The time since a response was sent by, or successfully validated
    228       with, the origin server.</t>
    229    </list>
    230 </t>
    231 <t>
    232    <iref item="first-hand" />
    233    <x:dfn>first-hand</x:dfn>
    234    <list>
    235       <t>A response is first-hand if the freshness model is not in use; i.e.,
    236       its age is 0.</t>
    237    </list>
    238 </t>
    239 <t>
    240    <iref item="freshness lifetime" />
    241    <x:dfn>freshness lifetime</x:dfn>
    242    <list>
    243       <t>The length of time between the generation of a response and its
    244       expiration time (either explicit or heuristic).</t>
    245    </list>
    246 </t>
    247 <t>
    248    <iref item="fresh" />
    249    <x:dfn>fresh</x:dfn>
    250    <list>
    251       <t>A response is fresh if its age has not yet exceeded its freshness
    252       lifetime.</t>
    253    </list>
    254 </t>
    255 <t>
    256    <iref item="stale" />
    257    <x:dfn>stale</x:dfn>
    258    <list>
    259       <t>A response is stale if its age has passed its freshness lifetime.</t>
    260    </list>
    261 </t>
    262 <t>
    263    <iref item="validator" />
    264    <x:dfn>validator</x:dfn>
    265    <list>
    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>
    269    </list>
    270 </t>
    271 <t>
    272    <iref item="strong validator" />
    273    <iref item="validator" subitem="strong" />
    274    <x:dfn>strong validator</x:dfn>
    275    <list>
    276       <t>A validator that is defined by the origin server such that its
    277          current value will change if the representation data changes.
    278          See &weak-and-strong;</t>
    279    </list>
    280 </t>
    281 </section>
    282 
    283176<section title="Conformance and Error Handling" anchor="conformance">
    284177<t>
    … …  
    349242   caching and defines something suitable for use as a cache key.
    350243</t>
     244<iref item="cache key" />
    351245<t>
    352246   The primary <x:dfn>cache key</x:dfn> consists of the request method and
    … …  
    559453
    560454<section anchor="expiration.model" title="Freshness">
     455<iref item="fresh" />
     456<iref item="stale" />
     457<t>
     458   A <x:dfn>fresh</x:dfn> response is one whose age has not yet exceeded its
     459   freshness lifetime. Conversely, a <x:dfn>stale</x:dfn>
     460   response is one where it has.
     461</t>
     462<iref item="freshness lifetime" />
     463<iref item="explicit expiration time" />
     464<iref item="heuristic expiration time" />
     465<t>
     466   A response's <x:dfn>freshness lifetime</x:dfn> is the length of time
     467   between its generation by the origin server and its expiration time. An
     468   <x:dfn>explicit expiration time</x:dfn> is the time at which the origin
     469   server intends that a stored response can no longer be used by a cache
     470   without further validation, whereas a <x:dfn>heuristic expiration
     471   time</x:dfn> is assigned by a cache when no explicit expiriation time is
     472   available.
     473</t>
     474<iref item="age" />
     475<t>
     476   A response's <x:dfn>age</x:dfn> is the time that has passed since it was
     477   generated by, or successfully validated with, the origin server. 
     478</t>
    561479<t>
    562480   When a response is "fresh" in the cache, it can be used to satisfy
    … …  
    569487   <x:ref>Expires</x:ref> header field (<xref target="header.expires" />) or
    570488   the max-age response cache directive (<xref
    571    target="cache-response-directive.max-age" />). Generally, origin servers will
    572    assign future explicit expiration times to responses in the belief that the
    573    representation is not likely to change in a semantically significant way
    574    before the expiration time is reached.
     489   target="cache-response-directive.max-age" />). Generally, origin servers
     490   will assign future explicit expiration times to responses in the belief
     491   that the representation is not likely to change in a semantically
     492   significant way before the expiration time is reached.
    575493</t>
    576494<t>
    … …  
    798716   field (e.g., because there are no HTTP/1.0 hops in the <x:ref>Via</x:ref>
    799717   header field), in which case the corrected_age_value &MAY; be used as the
    800    corrected_initial_age.</t>
     718   corrected_initial_age.
     719</t>
    801720<t>
    802721   The current_age of a stored response can then be calculated by adding the
    … …  
    835754   cache is disconnected.
    836755</t>
    837 <t>
    838    note that if a cache receives a first-hand response (either an entire
    839    response, or a <x:ref>304 (Not Modified)</x:ref> response) that it would
    840    normally forward to the requesting client, and the received response is no
    841    longer fresh, the cache can forward it to the requesting client without
    842    adding a new <x:ref>Warning</x:ref> (but without removing any existing
    843    Warning header fields). A cache shouldn't attempt to validate a response
    844    simply because that response became stale in transit.
     756<iref item="first-hand" />
     757<t>
     758   Note that if a cache receives a <x:dfn>first-hand</x:dfn> response (one
     759   where the freshness model is not in use; i.e., its age is 0, whether it is
     760   an entire response, or a <x:ref>304 (Not Modified)</x:ref> response) that
     761   it would normally forward to the requesting client, and the received
     762   response is no longer fresh, the cache can forward it to the requesting
     763   client without adding a new <x:ref>Warning</x:ref> (but without removing
     764   any existing Warning header fields). A cache shouldn't attempt to validate
     765   a response simply because that response became stale in transit.
    845766</t>
    846767</section>
    … …  
    857778   "validating" or "revalidating" the stored response.
    858779</t>
    859 <t>
    860    When sending such a conditional request, a cache adds an
    861    <x:ref>If-Modified-Since</x:ref> header field whose value is that of the
    862    <x:ref>Last-Modified</x:ref> header field from the selected
    863    (see <xref target="caching.negotiated.responses"/>) stored response, if
    864    available.
    865 </t>
    866 <t>
    867    Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field
     780<iref item="validator" />
     781<t>
     782   When sending such a conditional request, a cache adds a
     783   <x:dfn>validator</x:dfn> (or more than one), that is used to find
     784   out whether a stored response is an equivalent copy of a current
     785   representation of the resource.
     786</t>
     787<t>
     788   One such validator is the <x:ref>If-Modified-Since</x:ref> header field,
     789   whose value is that of the <x:ref>Last-Modified</x:ref> header field from
     790   the selected (see <xref target="caching.negotiated.responses"/>) stored
     791   response, if available.
     792</t>
     793<t>
     794   Another is the <x:ref>If-None-Match</x:ref> header field,
    868795   whose value is that of the <x:ref>ETag</x:ref> header field(s) from
    869796   relevant responses stored for the primary cache key, if present. However,
    … …  
    909836   with the new information provided in the <x:ref>304</x:ref> response.
    910837</t>
     838<iref item="strong validator" />
    911839<t>
    912840   The stored response to update is identified by using the first match (if
    … …  
    914842   <list style="symbols">
    915843    <t>
    916      If the new response contains a strong validator, then that strong
    917      validator identifies the selected representation for update. All of the
    918      stored responses with the same strong validator are selected. If none of
    919      the stored responses contain the same strong validator, then the new
    920      response &MUST-NOT; be used to update any stored responses.
     844     If the new response contains a <x:dfn>strong validator</x:dfn> (see
     845     &weak-and-strong;), then that strong validator identifies the selected
     846     representation for update. All of the stored responses with the same
     847     strong validator are selected. If none of the stored responses contain
     848     the same strong validator, then the new response &MUST-NOT; be used to
     849     update any stored responses.
    921850    </t>
    922851    <t>
Note: See TracChangeset for help on using the changeset viewer.