Changeset 1112


Ignore:
Timestamp:
10/02/11 05:52:29 (11 years ago)
Author:
mnot@…
Message:

Work on terminology and requirements language. #234

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

Legend:

Unmodified
Added
Removed

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

    r1110 r1112  
    632632      <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>
    633633      <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>
    634       <p id="rfc.section.1.2.p.2"> <span id="rfc.iref.c.2"></span>  <dfn>cacheable</dfn> 
    635       </p>
    636       <ul class="empty">
    637          <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    638             Even when a response is cacheable, there might be additional constraints on whether a cache can use the cached copy to satisfy
    639             a particular request.
    640          </li>
    641       </ul>
    642       <p id="rfc.section.1.2.p.3"> <span id="rfc.iref.e.1"></span>  <dfn>explicit expiration time</dfn> 
    643       </p>
    644       <ul class="empty">
    645          <li>The time at which the origin server intends that a representation no longer be returned by a cache without further validation.</li>
    646       </ul>
    647       <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
    648       </p>
    649       <ul class="empty">
    650          <li>An expiration time assigned by a cache when no explicit expiration time is available.</li>
    651       </ul>
    652       <p id="rfc.section.1.2.p.5"> <span id="rfc.iref.a.1"></span>  <dfn>age</dfn> 
    653       </p>
    654       <ul class="empty">
    655          <li>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</li>
    656       </ul>
    657       <p id="rfc.section.1.2.p.6"> <span id="rfc.iref.f.1"></span>  <dfn>first-hand</dfn> 
    658       </p>
    659       <ul class="empty">
    660          <li>A response is first-hand if the freshness model is not in use; i.e., its age is 0.</li>
    661       </ul>
    662       <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.f.2"></span>  <dfn>freshness lifetime</dfn> 
    663       </p>
    664       <ul class="empty">
    665          <li>The length of time between the generation of a response and its expiration time.</li>
    666       </ul>
    667       <p id="rfc.section.1.2.p.8"> <span id="rfc.iref.f.3"></span>  <dfn>fresh</dfn> 
    668       </p>
    669       <ul class="empty">
    670          <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li>
    671       </ul>
    672       <p id="rfc.section.1.2.p.9"> <span id="rfc.iref.s.1"></span>  <dfn>stale</dfn> 
    673       </p>
    674       <ul class="empty">
    675          <li>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</li>
    676       </ul>
    677       <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.v.1"></span>  <dfn>validator</dfn> 
    678       </p>
    679       <ul class="empty">
    680          <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response has an
    681             equivalent copy of a representation.
     634      <p id="rfc.section.1.2.p.2"> <span id="rfc.iref.c.2"></span>  <dfn>cache</dfn> 
     635      </p>
     636      <ul class="empty">
     637         <li>A conformant implementation of a HTTP cache. Note that this implies an HTTP/1.1 cache; this specification does not define
     638            conformance for HTTP/1.0 caches.
    682639         </li>
    683640      </ul>
    684641      <div id="shared.and.non-shared.caches">
    685          <p id="rfc.section.1.2.p.11"> <span id="rfc.iref.v.2"></span>  <dfn>shared cache</dfn> 
     642         <p id="rfc.section.1.2.p.3"> <span id="rfc.iref.s.1"></span>  <dfn>shared cache</dfn> 
    686643         </p>
    687644         <ul class="empty">
    688             <li>A cache that is accessible to more than one user. A non-shared cache is dedicated to a single user.</li>
     645            <li>A cache that is accessible to more than one user; usually (but not always) deployed as part of an intermediary.</li>
    689646         </ul>
    690647      </div>
     648      <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.p.1"></span>  <dfn>private cache</dfn> 
     649      </p>
     650      <ul class="empty">
     651         <li>A cache that is dedicated to a single user.</li>
     652      </ul>
     653      <p id="rfc.section.1.2.p.5"> <span id="rfc.iref.c.3"></span>  <dfn>cacheable</dfn> 
     654      </p>
     655      <ul class="empty">
     656         <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
     657            Even when a response is cacheable, there might be additional constraints on whether a cache can use the stored copy to satisfy
     658            a particular request.
     659         </li>
     660      </ul>
     661      <p id="rfc.section.1.2.p.6"> <span id="rfc.iref.e.1"></span>  <dfn>explicit expiration time</dfn> 
     662      </p>
     663      <ul class="empty">
     664         <li>The time at which the origin server intends that a representation no longer be returned by a cache without further validation.</li>
     665      </ul>
     666      <p id="rfc.section.1.2.p.7"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
     667      </p>
     668      <ul class="empty">
     669         <li>An expiration time assigned by a cache when no explicit expiration time is available.</li>
     670      </ul>
     671      <p id="rfc.section.1.2.p.8"> <span id="rfc.iref.a.1"></span>  <dfn>age</dfn> 
     672      </p>
     673      <ul class="empty">
     674         <li>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</li>
     675      </ul>
     676      <p id="rfc.section.1.2.p.9"> <span id="rfc.iref.f.1"></span>  <dfn>first-hand</dfn> 
     677      </p>
     678      <ul class="empty">
     679         <li>A response is first-hand if the freshness model is not in use; i.e., its age is 0.</li>
     680      </ul>
     681      <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.f.2"></span>  <dfn>freshness lifetime</dfn> 
     682      </p>
     683      <ul class="empty">
     684         <li>The length of time between the generation of a response and its expiration time.</li>
     685      </ul>
     686      <p id="rfc.section.1.2.p.11"> <span id="rfc.iref.f.3"></span>  <dfn>fresh</dfn> 
     687      </p>
     688      <ul class="empty">
     689         <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li>
     690      </ul>
     691      <p id="rfc.section.1.2.p.12"> <span id="rfc.iref.s.2"></span>  <dfn>stale</dfn> 
     692      </p>
     693      <ul class="empty">
     694         <li>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</li>
     695      </ul>
     696      <p id="rfc.section.1.2.p.13"> <span id="rfc.iref.v.1"></span>  <dfn>validator</dfn> 
     697      </p>
     698      <ul class="empty">
     699         <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response is an
     700            equivalent copy of a representation.
     701         </li>
     702      </ul>
    691703      <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
    692704      <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"
    … …  
    780792         </li>
    781793      </ul>
    782       <p id="rfc.section.2.2.p.2">When a stored response is used to satisfy a request without validation, caches <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.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;2.3.2</a>.
    783       </p>
    784       <p id="rfc.section.2.2.p.3">Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., a cache must not reply to such a request before having forwarded
    785          the request and having received a corresponding response.
     794      <p id="rfc.section.2.2.p.2">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.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;2.3.2</a>.
     795      </p>
     796      <p id="rfc.section.2.2.p.3">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 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to the origin server; i.e., a cache must not generate a reply to such a request before having forwarded the request and
     797         having received a corresponding response.
    786798      </p>
    787799      <p id="rfc.section.2.2.p.4">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;2.5</a>.
    788800      </p>
    789       <p id="rfc.section.2.2.p.5">Caches <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field) when more than one suitable response is stored. They
    790          can also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to
    791          use.
    792       </p>
    793       <p id="rfc.section.2.2.p.6">An HTTP implementation without a clock <em class="bcp14">MUST NOT</em> used stored responses without revalidating them on every use. An HTTP cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard.
     801      <p id="rfc.section.2.2.p.5">A cache <em class="bcp14">MUST</em> use the most recent response (as determined by the Date header field) when more than one suitable response is stored. It can
     802         also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
     803      </p>
     804      <p id="rfc.section.2.2.p.6">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> used stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard.
    794805      </p>
    795806      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
    … …  
    805816         requests.
    806817      </p>
    807       <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other heade field values
    808          (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific
     818      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field
     819         values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific
    809820         algorithms, but does impose worst-case constraints on their results.
    810821      </p>
    … …  
    836847      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
    837848      <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness
    838          to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a heuristic expiration time <em class="bcp14">MAY</em> be calculated. Heuristics <em class="bcp14">MUST NOT</em> be used for response status codes that do not explicitly allow it.
    839       </p>
    840       <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, the cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
     849         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
     850      </p>
     851      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
    841852         is not already present.
    842853      </p>
    843       <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
     854      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), a cache <em class="bcp14">SHOULD NOT</em> use a heuristic expiration value that is more than some fraction of the interval since that time. A typical setting of this
     855         fraction might be 10%.
    844856      </p>
    845857      <div class="note" id="rfc.section.2.3.1.1.p.4">
    … …  
    873885      </p>
    874886      <ul class="empty">
    875          <li>The term "now" means "the current value of the clock at the host performing the calculation". Hosts that use HTTP, but especially
    876             hosts running origin servers and caches, <em class="bcp14">SHOULD</em> use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.2"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize their clocks to a globally accurate time standard.
     887         <li>The term "now" means "the current value of the clock at the host performing the calculation". A cache <em class="bcp14">SHOULD</em> use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.2"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize its clocks to a globally accurate time standard.
    877888         </li>
    878889      </ul>
    … …  
    892903            clock. If the result is negative, the result is replaced by zero.
    893904         </li>
    894          <li>the "corrected_age_value", if all of the caches along the response path implement HTTP/1.1; note this value <em class="bcp14">MUST</em> be interpreted relative to the time the request was initiated, not the time that the response was received.
     905         <li>the "corrected_age_value", if all of the caches along the response path implement HTTP/1.1. A cache <em class="bcp14">MUST</em> interpret this value relative to the time the request was initiated, not the time that the response was received.
    895906         </li>
    896907      </ol>
    … …  
    910921         is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>.
    911922      </p>
    912       <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
     923      <p id="rfc.section.2.3.3.p.2">A cache <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    913924         directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    914925         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>).
    915926      </p>
    916       <p id="rfc.section.2.3.3.p.3">Caches <em class="bcp14">SHOULD NOT</em> return stale responses unless they are disconnected (i.e., it cannot contact the origin server or otherwise find a forward
    917          path) or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    918       </p>
    919       <p id="rfc.section.2.3.3.p.4">Stale responses <em class="bcp14">SHOULD</em> have a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>). Likewise, the 112 warn-code <em class="bcp14">SHOULD</em> be sent on stale responses if the cache is disconnected.
     927      <p id="rfc.section.2.3.3.p.3">A cache <em class="bcp14">SHOULD NOT</em> return stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)
     928         or otherwise explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
     929      </p>
     930      <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</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.
    920931      </p>
    921932      <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
    … …  
    928939         update it. This process is known as "validating" or "revalidating" the stored response.
    929940      </p>
    930       <p id="rfc.section.2.4.p.2">When sending such a conditional request, the cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
    931       </p>
    932       <p id="rfc.section.2.4.p.3">Additionally, the cache <em class="bcp14">SHOULD</em> add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested
    933          URI, if present. However, if any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
    934          response.
     941      <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
     942      </p>
     943      <p id="rfc.section.2.4.p.3">Additionally, a cache <em class="bcp14">SHOULD</em> add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested
     944         URI, if present. However, if any of the stored responses contains only partial content, the cache <em class="bcp14">SHOULD NOT</em> include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied by
     945         that stored response.
    935946      </p>
    936947      <p id="rfc.section.2.4.p.4">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.responses" title="Combining Responses">Section&nbsp;2.8</a>.
    937948      </p>
    938949      <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
    939          request is suitable. Instead, the full response <em class="bcp14">SHOULD</em> be used to satisfy the request and <em class="bcp14">MAY</em> replace the stored response.
     950         request is suitable. Instead, a cache <em class="bcp14">SHOULD</em> use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response.
    940951      </p>
    941952      <p id="rfc.section.2.4.p.6">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
    942953      </p>
    943954      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2>
    944       <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
    945       </p>
    946       <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present):
     955      <p id="rfc.section.2.5.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
     956      </p>
     957      <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when the following request methods
     958         are received:
    947959      </p>
    948960      <ul>
    … …  
    951963         <li>POST</li>
    952964      </ul>
    953       <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header field <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    954       </p>
    955       <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     965      <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part
     966         in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
     967      </p>
     968      <p id="rfc.section.2.5.p.4">A cache that passes through requests with methods it does not understand <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    956969      </p>
    957970      <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will
    … …  
    962975      </p>
    963976      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2>
    964       <p id="rfc.section.2.6.p.1">Shared caches <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
     977      <p id="rfc.section.2.6.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
    965978      </p>
    966979      <p id="rfc.section.2.6.p.2">In this specification, the following Cache-Control response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
    … …  
    10011014      <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: might need language about Content-Location here]</span><span class="comment" id="TODO-select-for-combine">[<a href="#TODO-select-for-combine" class="smpl">TODO-select-for-combine</a>: Shouldn't this be the selected response?]</span>
    10021015      </p>
    1003       <p id="rfc.section.2.8.p.3">If the new response's status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
     1016      <p id="rfc.section.2.8.p.3">When the new response's status code is 206 (partial content), a cache <em class="bcp14">MUST NOT</em> combine it with the old response if either response does not have a validator, and <em class="bcp14">MUST NOT</em> combine it with the old response when those validators do not match with the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    10041017      </p>
    10051018      <p id="rfc.section.2.8.p.4">The stored response header fields are used as those of the updated response, except that </p>
    10061019      <ul>
    1007          <li>any stored Warning header fields with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted.
    1008          </li>
    1009          <li>any stored Warning header fields with warn-code 2xx <em class="bcp14">MUST</em> be retained.
    1010          </li>
    1011          <li>any other header fields provided in the new response <em class="bcp14">MUST</em> replace all instances of the corresponding header fields from the stored response.
    1012          </li>
    1013       </ul>
    1014       <p id="rfc.section.2.8.p.5">The updated response header fields <em class="bcp14">MUST</em> be used to replace those of the stored response in cache (unless the stored response is removed from cache). In the case of
    1015          a 206 response, the combined representation <em class="bcp14">MAY</em> be stored.
     1020         <li>a cache <em class="bcp14">MUST</em> delete any stored Warning header fields with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>).
     1021         </li>
     1022         <li>a cache <em class="bcp14">MUST</em> retain any stored Warning header fields with warn-code 2xx.
     1023         </li>
     1024         <li>a cache <em class="bcp14">MUST</em> use other header fields provided in the new response to replace all instances of the corresponding header fields from the
     1025            stored response.
     1026         </li>
     1027      </ul>
     1028      <p id="rfc.section.2.8.p.5">A cache <em class="bcp14">MUST</em> use the updated response header fields to replace those of the stored response (unless the stored response is removed). In
     1029         the case of a 206 response, a cache <em class="bcp14">MAY</em> store the combined representation.
    10161030      </p>
    10171031      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    10301044      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a>
    10311045</pre><p id="rfc.section.3.1.p.5">If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows,
    1032          it <em class="bcp14">MUST</em> transmit an Age header field with a field-value of 2147483648 (2<sup>31</sup>). Caches <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range.
     1046         it <em class="bcp14">MUST</em> transmit an Age header field with a field-value of 2147483648 (2<sup>31</sup>). Recipients parsing the Age header field-value <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range.
    10331047      </p>
    10341048      <p id="rfc.section.3.1.p.6">The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not
    10351049         true, since HTTP/1.0 caches might not implement the Age header field.
    10361050      </p>
    1037       <div id="rfc.iref.c.3"></div>
     1051      <div id="rfc.iref.c.4"></div>
    10381052      <div id="rfc.iref.h.3"></div>
    10391053      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
    … …  
    10421056         be given in the response.
    10431057      </p>
    1044       <p id="rfc.section.3.2.p.2">HTTP/1.1 caches <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;3.2.3</a> for information about how Cache-Control directives defined elsewhere are handled.
     1058      <p id="rfc.section.3.2.p.2">A cache <em class="bcp14">MUST</em> obey the requirements of the Cache-Control directives defined in this section. See <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;3.2.3</a> for information about how Cache-Control directives defined elsewhere are handled.
    10451059      </p>
    10461060      <div class="note" id="rfc.section.3.2.p.3">
    … …  
    10481062         </p>
    10491063      </div>
    1050       <p id="rfc.section.3.2.p.4">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives
    1051          might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific
    1052          cache.
     1064      <p id="rfc.section.3.2.p.4">An intermediary (i.e., a proxy or gateway, whether or not it implements a cache) <em class="bcp14">MUST</em> pass cache directives through, regardless of their significance to that application, since the directives might be applicable
     1065         to all recipients along the request/response chain. It is not possible to target a directive to a specific cache.
    10531066      </p>
    10541067      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.cache-control" class="smpl">Cache-Control</a>   = "Cache-Control" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.cache-control" class="smpl">Cache-Control-v</a>
    … …  
    10691082     / "only-if-cached"
    10701083     / <a href="#header.cache-control" class="smpl">cache-extension</a>
    1071 </pre><p id="rfc.section.3.2.1.p.2"> <dfn>no-cache</dfn>  <span id="rfc.iref.c.4"></span>  <span id="rfc.iref.n.1"></span> 
    1072       </p>
    1073       <ul class="empty">
    1074          <li>The no-cache request directive indicates that a stored response <em class="bcp14">MUST NOT</em> be used to satisfy the request without successful validation on the origin server.
    1075          </li>
    1076       </ul>
    1077       <p id="rfc.section.3.2.1.p.3"> <dfn>no-store</dfn>  <span id="rfc.iref.c.5"></span>  <span id="rfc.iref.n.2"></span> 
    1078       </p>
    1079       <ul class="empty">
    1080          <li>The no-store request directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. This directive applies to both non-shared and shared caches.
    1081             "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
     1084</pre><p id="rfc.section.3.2.1.p.2"> <dfn>no-cache</dfn>  <span id="rfc.iref.c.5"></span>  <span id="rfc.iref.n.1"></span> 
     1085      </p>
     1086      <ul class="empty">
     1087         <li>The no-cache request directive indicates that a cache <em class="bcp14">MUST NOT</em> use a stored response to satisfy the request without successful validation on the origin server.
     1088         </li>
     1089      </ul>
     1090      <p id="rfc.section.3.2.1.p.3"> <dfn>no-store</dfn>  <span id="rfc.iref.c.6"></span>  <span id="rfc.iref.n.2"></span> 
     1091      </p>
     1092      <ul class="empty">
     1093         <li>The no-store request directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
    10821094         </li>
    10831095         <li>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches
    … …  
    10881100         </li>
    10891101      </ul>
    1090       <p id="rfc.section.3.2.1.p.4"> <dfn>max-age</dfn>  <span id="rfc.iref.c.6"></span>  <span id="rfc.iref.m.1"></span> 
     1102      <p id="rfc.section.3.2.1.p.4"> <dfn>max-age</dfn>  <span id="rfc.iref.c.7"></span>  <span id="rfc.iref.m.1"></span> 
    10911103      </p>
    10921104      <ul class="empty">
    … …  
    10951107         </li>
    10961108      </ul>
    1097       <p id="rfc.section.3.2.1.p.5"> <dfn>max-stale</dfn>  <span id="rfc.iref.c.7"></span>  <span id="rfc.iref.m.2"></span> 
     1109      <p id="rfc.section.3.2.1.p.5"> <dfn>max-stale</dfn>  <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.2"></span> 
    10981110      </p>
    10991111      <ul class="empty">
    … …  
    11041116         </li>
    11051117      </ul>
    1106       <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn>  <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> 
     1118      <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn>  <span id="rfc.iref.c.9"></span>  <span id="rfc.iref.m.3"></span> 
    11071119      </p>
    11081120      <ul class="empty">
    … …  
    11121124         </li>
    11131125      </ul>
    1114       <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn>  <span id="rfc.iref.c.9"></span>  <span id="rfc.iref.n.3"></span> 
    1115       </p>
    1116       <ul class="empty">
    1117          <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request header fields, nor the request representation.
    1118          </li>
    1119       </ul>
    1120       <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn>  <span id="rfc.iref.c.10"></span>  <span id="rfc.iref.o.1"></span> 
     1126      <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn>  <span id="rfc.iref.c.10"></span>  <span id="rfc.iref.n.3"></span> 
     1127      </p>
     1128      <ul class="empty">
     1129         <li>The no-transform request directive indicates that an intermediary (whether or not it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request header fields, nor the request representation.
     1130         </li>
     1131      </ul>
     1132      <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn>  <span id="rfc.iref.c.11"></span>  <span id="rfc.iref.o.1"></span> 
    11211133      </p>
    11221134      <ul class="empty">
    … …  
    11241136            directive, a cache <em class="bcp14">SHOULD</em> either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504
    11251137            (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity,
    1126             such a request <em class="bcp14">MAY</em> be forwarded within that group of caches.
     1138            a member cache <em class="bcp14">MAY</em> forward such a request within that group of caches.
    11271139         </li>
    11281140      </ul>
    … …  
    11391151     / "s-maxage" "=" <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
    11401152     / <a href="#header.cache-control" class="smpl">cache-extension</a>
    1141 </pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn>  <span id="rfc.iref.c.11"></span>  <span id="rfc.iref.p.1"></span> 
    1142       </p>
    1143       <ul class="empty">
    1144          <li>The public response directive indicates that the response <em class="bcp14">MAY</em> be cached, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also Authorization, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, for additional details.)
    1145          </li>
    1146       </ul>
    1147       <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn>  <span id="rfc.iref.c.12"></span>  <span id="rfc.iref.p.2"></span> 
    1148       </p>
    1149       <ul class="empty">
    1150          <li>The private response directive indicates that the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be stored by a shared cache. A private (non-shared) cache <em class="bcp14">MAY</em> store the response.
     1153</pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn>  <span id="rfc.iref.c.12"></span>  <span id="rfc.iref.p.2"></span> 
     1154      </p>
     1155      <ul class="empty">
     1156         <li>The public response directive indicates that a cache <em class="bcp14">MAY</em> store the response, even if it would normally be non-cacheable or cacheable only within a private cache. (See also Authorization, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, for additional details.)
     1157         </li>
     1158      </ul>
     1159      <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn>  <span id="rfc.iref.c.13"></span>  <span id="rfc.iref.p.3"></span> 
     1160      </p>
     1161      <ul class="empty">
     1162         <li>The private response directive indicates that the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be stored by a shared cache. A private cache <em class="bcp14">MAY</em> store the response.
    11511163         </li>
    11521164         <li>If the private response directive specifies one or more field-names, this requirement is limited to the field-values associated
    1153             with the listed response header fields. That is, the specified field-names(s) <em class="bcp14">MUST NOT</em> be stored by a shared cache, whereas the remainder of the response message <em class="bcp14">MAY</em> be.
     1165            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.
    11541166         </li>
    11551167         <li> <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
    … …  
    11581170         </li>
    11591171      </ul>
    1160       <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn>  <span id="rfc.iref.c.13"></span>  <span id="rfc.iref.n.4"></span> 
     1172      <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn>  <span id="rfc.iref.c.14"></span>  <span id="rfc.iref.n.4"></span> 
    11611173      </p>
    11621174      <ul class="empty">
    … …  
    11661178         </li>
    11671179         <li>If the no-cache response directive specifies one or more field-names, this requirement is limited to the field-values associated
    1168             with the listed response header fields. That is, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful validation on the origin server. This allows an origin
    1169             server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
     1180            with the listed response header fields. That is, a cache <em class="bcp14">MUST NOT</em> send the specified field-name(s) in the response to a subsequent request without successful validation on the origin server.
     1181            This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of
     1182            the rest of the response.
    11701183         </li>
    11711184         <li> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache response directives with field-names are often
    … …  
    11741187         </li>
    11751188      </ul>
    1176       <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn>  <span id="rfc.iref.c.14"></span>  <span id="rfc.iref.n.5"></span> 
    1177       </p>
    1178       <ul class="empty">
    1179          <li>The no-store response directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either the immediate request or response. This directive applies to both non-shared and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
     1189      <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn>  <span id="rfc.iref.c.15"></span>  <span id="rfc.iref.n.5"></span> 
     1190      </p>
     1191      <ul class="empty">
     1192         <li>The no-store response directive indicates that a cache <em class="bcp14">MUST NOT</em> store any part of either the immediate request or response. This directive applies to both private and shared caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
    11801193         </li>
    11811194         <li>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches
    … …  
    11831196         </li>
    11841197      </ul>
    1185       <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn>  <span id="rfc.iref.c.15"></span>  <span id="rfc.iref.m.4"></span> 
    1186       </p>
    1187       <ul class="empty">
    1188          <li>The must-revalidate response directive indicates that once it has become stale, the response <em class="bcp14">MUST NOT</em> be used to satisfy subsequent requests without successful validation on the origin server.
     1198      <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn>  <span id="rfc.iref.c.16"></span>  <span id="rfc.iref.m.4"></span> 
     1199      </p>
     1200      <ul class="empty">
     1201         <li>The must-revalidate response directive indicates that once it has become stale, a cache <em class="bcp14">MUST NOT</em> use the response to satisfy subsequent requests without successful validation on the origin server.
    11891202         </li>
    11901203         <li>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances
    1191             an HTTP/1.1 cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response.
    1192          </li>
    1193          <li>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the representation could result in incorrect
     1204            a cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response.
     1205         </li>
     1206         <li>A server <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the representation could result in incorrect
    11941207            operation, such as a silently unexecuted financial transaction.
    11951208         </li>
    11961209      </ul>
    1197       <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn>  <span id="rfc.iref.c.16"></span>  <span id="rfc.iref.p.3"></span> 
     1210      <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn>  <span id="rfc.iref.c.17"></span>  <span id="rfc.iref.p.4"></span> 
    11981211      </p>
    11991212      <ul class="empty">
    12001213         <li>The proxy-revalidate response directive has the same meaning as the must-revalidate response directive, except that it does
    1201             not apply to non-shared caches.
    1202          </li>
    1203       </ul>
    1204       <p id="rfc.section.3.2.2.p.8"> <dfn>max-age</dfn>  <span id="rfc.iref.c.17"></span>  <span id="rfc.iref.m.5"></span> 
     1214            not apply to private caches.
     1215         </li>
     1216      </ul>
     1217      <p id="rfc.section.3.2.2.p.8"> <dfn>max-age</dfn>  <span id="rfc.iref.c.18"></span>  <span id="rfc.iref.m.5"></span> 
    12051218      </p>
    12061219      <ul class="empty">
    … …  
    12091222         </li>
    12101223      </ul>
    1211       <p id="rfc.section.3.2.2.p.9"> <dfn>s-maxage</dfn>  <span id="rfc.iref.c.18"></span>  <span id="rfc.iref.s.2"></span> 
     1224      <p id="rfc.section.3.2.2.p.9"> <dfn>s-maxage</dfn>  <span id="rfc.iref.c.19"></span>  <span id="rfc.iref.s.3"></span> 
    12121225      </p>
    12131226      <ul class="empty">
    … …  
    12171230         </li>
    12181231      </ul>
    1219       <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn>  <span id="rfc.iref.c.19"></span>  <span id="rfc.iref.n.6"></span> 
    1220       </p>
    1221       <ul class="empty">
    1222          <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response header fields, nor the response representation.
     1232      <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn>  <span id="rfc.iref.c.20"></span>  <span id="rfc.iref.n.6"></span> 
     1233      </p>
     1234      <ul class="empty">
     1235         <li>The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response header fields, nor the response representation.
    12231236         </li>
    12241237      </ul>
    … …  
    12361249      </p>
    12371250      <p id="rfc.section.3.2.3.p.3">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
    1238          We define this new directive to mean that, in addition to any non-shared cache, any cache that is shared only by members of
    1239          the community named within its value may cache the response. An origin server wishing to allow the UCI community to use an
    1240          otherwise private response in their shared cache(s) could do so by including
     1251         We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the
     1252         community named within its value may cache the response. An origin server wishing to allow the UCI community to use an otherwise
     1253         private response in their shared cache(s) could do so by including
    12411254      </p>
    12421255      <div id="rfc.figure.u.12"></div><pre class="text">  Cache-Control: private, community="UCI"
    … …  
    12441257         it will also see and understand the private directive and thus default to the safe behavior.
    12451258      </p>
    1246       <p id="rfc.section.3.2.3.p.6">Unrecognized cache directives <em class="bcp14">MUST</em> be ignored; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard
    1247          directives (or the response's default cacheability) such that the cache behavior will remain minimally correct even if the
    1248          cache does not understand the extension(s).
     1259      <p id="rfc.section.3.2.3.p.6">A cache <em class="bcp14">MUST</em> be ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache
     1260         will be combined with standard directives (or the response's default cacheability) such that the cache behavior will remain
     1261         minimally correct even if the cache does not understand the extension(s).
    12491262      </p>
    12501263      <p id="rfc.section.3.2.3.p.7">The HTTP Cache Directive Registry defines the name space for the cache directives.</p>
    1251       <p id="rfc.section.3.2.3.p.8">Registrations <em class="bcp14">MUST</em> include the following fields:
     1264      <p id="rfc.section.3.2.3.p.8">A registration <em class="bcp14">MUST</em> include the following fields:
    12521265      </p>
    12531266      <ul>
    … …  
    12671280         that time.
    12681281      </p>
    1269       <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
     1282      <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
    12701283      </p>
    12711284      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.expires" class="smpl">Expires</a>   = "Expires" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expires" class="smpl">Expires-v</a>
    … …  
    12771290         </p>
    12781291      </div>
    1279       <p id="rfc.section.3.3.p.7">HTTP/1.1 servers <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.
    1280       </p>
    1281       <p id="rfc.section.3.3.p.8">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
    1282       </p>
    1283       <div id="rfc.iref.p.4"></div>
     1292      <p id="rfc.section.3.3.p.7">A server <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.
     1293      </p>
     1294      <p id="rfc.section.3.3.p.8">A cache <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
     1295      </p>
     1296      <div id="rfc.iref.p.5"></div>
    12841297      <div id="rfc.iref.h.5"></div>
    12851298      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
    … …  
    12921305  <a href="#header.pragma" class="smpl">pragma-directive</a>  = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a>
    12931306  <a href="#header.pragma" class="smpl">extension-pragma</a>  = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ]
    1294 </pre><p id="rfc.section.3.4.p.3">When the no-cache directive is present in a request message, an application <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive
    1295          has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. Clients <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. HTTP/1.1 caches <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache".
     1307</pre><p id="rfc.section.3.4.p.3">When the no-cache directive is present in a request message, a cache <em class="bcp14">SHOULD</em> forward the request toward the origin server even if it has a stored copy of what is being requested. This pragma directive
     1308         has the same semantics as the no-cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) and is defined here for backward compatibility with HTTP/1.0. A client <em class="bcp14">SHOULD</em> include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant. A cache <em class="bcp14">SHOULD</em> treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache".
    12961309      </p>
    12971310      <div class="note" id="rfc.section.3.4.p.4">
    … …  
    13011314      </div>
    13021315      <p id="rfc.section.3.4.p.5">This mechanism is deprecated; no new Pragma directives will be defined in HTTP.</p>
    1303       <div id="rfc.iref.v.3"></div>
     1316      <div id="rfc.iref.v.2"></div>
    13041317      <div id="rfc.iref.h.6"></div>
    13051318      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
    … …  
    13141327  <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a>
    13151328</pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-header fields.</p>
    1316       <p id="rfc.section.3.5.p.6">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
     1329      <p id="rfc.section.3.5.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache
    13171330         to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
    13181331         resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide
    … …  
    13211334      <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-header fields (e.g., the network
    13221335         address of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether
    1323          this response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server.
     1336         this response is appropriate. A proxy <em class="bcp14">MUST NOT</em> generate the "*" value.
    13241337      </p>
    13251338      <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names
    … …  
    13621375      </p>
    13631376      <ul>
    1364          <li>1xx Warnings describe the freshness or validation status of the response, and so <em class="bcp14">MUST</em> be deleted by caches after validation. They can only be generated by a cache when validating a cached entry, and <em class="bcp14">MUST NOT</em> be generated in any other situation.
     1377         <li>1xx Warnings describe the freshness or validation status of the response, and so <em class="bcp14">MUST</em> be deleted by a cache after validation. They can only be generated by a cache when validating a cached entry, and <em class="bcp14">MUST NOT</em> be generated in any other situation.
    13651378         </li>
    13661379         <li>2xx Warnings describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression
    1367             of the representation) and <em class="bcp14">MUST NOT</em> be deleted by caches after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.
     1380            of the representation) and <em class="bcp14">MUST NOT</em> be deleted by a cache after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.
    13681381         </li>
    13691382      </ul>
    … …  
    13711384         then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header field in the message.
    13721385      </p>
    1373       <p id="rfc.section.3.6.p.10">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from
    1374          the Date value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning
     1386      <p id="rfc.section.3.6.p.10">If a system receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date
     1387         value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (preventing the consequences of naive caching of Warning
    13751388         header fields.) If all of the warning-values are deleted for this reason, the Warning header field <em class="bcp14">MUST</em> be deleted as well.
    13761389      </p>
    … …  
    13801393      <p id="rfc.section.3.6.p.12"> 110 Response is stale </p>
    13811394      <ul class="empty">
    1382          <li><em class="bcp14">SHOULD</em> be included whenever the returned response is stale.
     1395         <li>A cache <em class="bcp14">SHOULD</em> include this whenever the returned response is stale.
    13831396         </li>
    13841397      </ul>
    13851398      <p id="rfc.section.3.6.p.13"> 111 Revalidation failed </p>
    13861399      <ul class="empty">
    1387          <li><em class="bcp14">SHOULD</em> be included if a cache returns a stale response because an attempt to validate the response failed, due to an inability to
    1388             reach the server.
     1400         <li>A cache <em class="bcp14">SHOULD</em> include this when returning a stale response because an attempt to validate the response failed, due to an inability to reach
     1401            the server.
    13891402         </li>
    13901403      </ul>
    13911404      <p id="rfc.section.3.6.p.14"> 112 Disconnected operation </p>
    13921405      <ul class="empty">
    1393          <li><em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time.
     1406         <li>A cache <em class="bcp14">SHOULD</em> b include this if it is intentionally disconnected from the rest of the network for a period of time.
    13941407         </li>
    13951408      </ul>
    13961409      <p id="rfc.section.3.6.p.15"> 113 Heuristic expiration </p>
    13971410      <ul class="empty">
    1398          <li><em class="bcp14">SHOULD</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater
    1399             than 24 hours.
     1411         <li>A cache <em class="bcp14">SHOULD</em> include this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24
     1412            hours.
    14001413         </li>
    14011414      </ul>
    … …  
    14071420      <p id="rfc.section.3.6.p.17"> 214 Transformation applied </p>
    14081421      <ul class="empty">
    1409          <li><em class="bcp14">MUST</em> be added by an intermediate proxy if it applies any transformation to the representation, such as changing the content-coding,
    1410             media-type, or modifying the representation data, unless this Warning code already appears in the response.
     1422         <li><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,
     1423            or modifying the representation data, unless this Warning code already appears in the response.
    14111424         </li>
    14121425      </ul>
    … …  
    19331946            </li>
    19341947            <li><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul>
    1935                   <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.1">1.1</a></li>
     1948                  <li>cache&nbsp;&nbsp;<a href="#rfc.iref.c.1">1.1</a>, <a href="#rfc.iref.c.2">1.2</a></li>
    19361949                  <li>Cache Directives&nbsp;&nbsp;
    19371950                     <ul>
    1938                         <li>max-age&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.2.1</b></a>, <a href="#rfc.iref.c.17"><b>3.2.2</b></a></li>
    1939                         <li>max-stale&nbsp;&nbsp;<a href="#rfc.iref.c.7"><b>3.2.1</b></a></li>
    1940                         <li>min-fresh&nbsp;&nbsp;<a href="#rfc.iref.c.8"><b>3.2.1</b></a></li>
    1941                         <li>must-revalidate&nbsp;&nbsp;<a href="#rfc.iref.c.15"><b>3.2.2</b></a></li>
    1942                         <li>no-cache&nbsp;&nbsp;<a href="#rfc.iref.c.4"><b>3.2.1</b></a>, <a href="#rfc.iref.c.13"><b>3.2.2</b></a></li>
    1943                         <li>no-store&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>3.2.1</b></a>, <a href="#rfc.iref.c.14"><b>3.2.2</b></a></li>
    1944                         <li>no-transform&nbsp;&nbsp;<a href="#rfc.iref.c.9"><b>3.2.1</b></a>, <a href="#rfc.iref.c.19"><b>3.2.2</b></a></li>
    1945                         <li>only-if-cached&nbsp;&nbsp;<a href="#rfc.iref.c.10"><b>3.2.1</b></a></li>
    1946                         <li>private&nbsp;&nbsp;<a href="#rfc.iref.c.12"><b>3.2.2</b></a></li>
    1947                         <li>proxy-revalidate&nbsp;&nbsp;<a href="#rfc.iref.c.16"><b>3.2.2</b></a></li>
    1948                         <li>public&nbsp;&nbsp;<a href="#rfc.iref.c.11"><b>3.2.2</b></a></li>
    1949                         <li>s-maxage&nbsp;&nbsp;<a href="#rfc.iref.c.18"><b>3.2.2</b></a></li>
    1950                      </ul>
    1951                   </li>
    1952                   <li>Cache-Control header&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">2.1</a>, <a href="#rfc.xref.header.cache-control.2">2.2</a>, <a href="#rfc.iref.c.3"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li>
    1953                   <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.2">1.2</a></li>
     1951                        <li>max-age&nbsp;&nbsp;<a href="#rfc.iref.c.7"><b>3.2.1</b></a>, <a href="#rfc.iref.c.18"><b>3.2.2</b></a></li>
     1952                        <li>max-stale&nbsp;&nbsp;<a href="#rfc.iref.c.8"><b>3.2.1</b></a></li>
     1953                        <li>min-fresh&nbsp;&nbsp;<a href="#rfc.iref.c.9"><b>3.2.1</b></a></li>
     1954                        <li>must-revalidate&nbsp;&nbsp;<a href="#rfc.iref.c.16"><b>3.2.2</b></a></li>
     1955                        <li>no-cache&nbsp;&nbsp;<a href="#rfc.iref.c.5"><b>3.2.1</b></a>, <a href="#rfc.iref.c.14"><b>3.2.2</b></a></li>
     1956                        <li>no-store&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.2.1</b></a>, <a href="#rfc.iref.c.15"><b>3.2.2</b></a></li>
     1957                        <li>no-transform&nbsp;&nbsp;<a href="#rfc.iref.c.10"><b>3.2.1</b></a>, <a href="#rfc.iref.c.20"><b>3.2.2</b></a></li>
     1958                        <li>only-if-cached&nbsp;&nbsp;<a href="#rfc.iref.c.11"><b>3.2.1</b></a></li>
     1959                        <li>private&nbsp;&nbsp;<a href="#rfc.iref.c.13"><b>3.2.2</b></a></li>
     1960                        <li>proxy-revalidate&nbsp;&nbsp;<a href="#rfc.iref.c.17"><b>3.2.2</b></a></li>
     1961                        <li>public&nbsp;&nbsp;<a href="#rfc.iref.c.12"><b>3.2.2</b></a></li>
     1962                        <li>s-maxage&nbsp;&nbsp;<a href="#rfc.iref.c.19"><b>3.2.2</b></a></li>
     1963                     </ul>
     1964                  </li>
     1965                  <li>Cache-Control header&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">2.1</a>, <a href="#rfc.xref.header.cache-control.2">2.2</a>, <a href="#rfc.iref.c.4"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li>
     1966                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.3">1.2</a></li>
    19541967               </ul>
    19551968            </li>
    … …  
    20882101                     </ul>
    20892102                  </li>
    2090                   <li>Pragma header&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.p.4"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li>
     2103                  <li>Pragma header&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.p.5"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li>
    20912104                  <li>private&nbsp;&nbsp;
    20922105                     <ul>
    2093                         <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>3.2.2</b></a></li>
    2094                      </ul>
    2095                   </li>
     2106                        <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>3.2.2</b></a></li>
     2107                     </ul>
     2108                  </li>
     2109                  <li>private cache&nbsp;&nbsp;<a href="#rfc.iref.p.1">1.2</a></li>
    20962110                  <li>proxy-revalidate&nbsp;&nbsp;
    20972111                     <ul>
    2098                         <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.p.3"><b>3.2.2</b></a></li>
     2112                        <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.p.4"><b>3.2.2</b></a></li>
    20992113                     </ul>
    21002114                  </li>
    21012115                  <li>public&nbsp;&nbsp;
    21022116                     <ul>
    2103                         <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.p.1"><b>3.2.2</b></a></li>
     2117                        <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.p.2"><b>3.2.2</b></a></li>
    21042118                     </ul>
    21052119                  </li>
    … …  
    21322146                  <li>s-maxage&nbsp;&nbsp;
    21332147                     <ul>
    2134                         <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>3.2.2</b></a></li>
    2135                      </ul>
    2136                   </li>
    2137                   <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.1">1.2</a></li>
     2148                        <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>3.2.2</b></a></li>
     2149                     </ul>
     2150                  </li>
     2151                  <li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1.2</a></li>
     2152                  <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">1.2</a></li>
    21382153               </ul>
    21392154            </li>
    21402155            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    2141                   <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">1.2</a>, <a href="#rfc.iref.v.2">1.2</a></li>
    2142                   <li>Vary header&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.v.3"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li>
     2156                  <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">1.2</a></li>
     2157                  <li>Vary header&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.v.2"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li>
    21432158               </ul>
    21442159            </li>

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

    r1110 r1112  
    264264</t>
    265265<t>
     266   <iref item="cache" />
     267   <x:dfn>cache</x:dfn>
     268   <list>
     269      <t>A conformant implementation of a HTTP cache. Note that this implies
     270        an HTTP/1.1 cache; this specification does not define conformance
     271        for HTTP/1.0 caches.</t>
     272   </list>
     273</t>
     274<t anchor="shared.and.non-shared.caches">
     275   <iref item="shared cache" />
     276   <x:dfn>shared cache</x:dfn>
     277   <list>
     278      <t>A cache that is accessible to more than one user; usually (but
     279        not always) deployed as part of an intermediary.</t>
     280   </list>
     281</t>
     282<t>
     283   <iref item="private cache" />
     284   <x:dfn>private cache</x:dfn>
     285   <list>
     286      <t>A cache that is dedicated to a single user.</t>
     287   </list>
     288</t>
     289<t>
    266290   <iref item="cacheable" />
    267291   <x:dfn>cacheable</x:dfn>
    … …  
    270294      response message for use in answering subsequent requests. Even when a
    271295      response is cacheable, there might be additional constraints on whether
    272       a cache can use the cached copy to satisfy a particular request.</t>
     296      a cache can use the stored copy to satisfy a particular request.</t>
    273297   </list>
    274298</t>
    … …  
    334358   <list>
    335359      <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that
    336       is used to find out whether a stored response has an equivalent copy of
     360      is used to find out whether a stored response is an equivalent copy of
    337361      a representation.</t>
    338    </list>
    339 </t>
    340 <t anchor="shared.and.non-shared.caches">
    341    <iref item="validator" />
    342    <x:dfn>shared cache</x:dfn>
    343    <list>
    344       <t>A cache that is accessible to more than one user. A non-shared cache
    345       is dedicated to a single user.</t>
    346362   </list>
    347363</t>
    … …  
    525541<t>
    526542   When a stored response is used to satisfy a request without validation,
    527    caches &MUST; include a single Age header field (<xref target="header.age"
     543   a cache &MUST; include a single Age header field (<xref target="header.age"
    528544   />) in the response with a value equal to the stored response's
    529545   current_age; see <xref target="age.calculations" />.
    530546</t>
    531547<t>
    532    Requests with methods that are unsafe (&safe-methods;) &MUST; be written
    533    through the cache to the origin server; i.e., a cache must not reply to
    534    such a request before having forwarded the request and having received a
    535    corresponding response.
     548   A cache &MUST; write through requests with methods that are unsafe
     549   (&safe-methods;) to the origin server; i.e., a cache must not generate
     550   a reply to such a request before having forwarded the request and having
     551   received a corresponding response.
    536552</t>
    537553<t>
    … …  
    540556</t>
    541557<t>
    542    Caches &MUST; use the most recent response (as determined by the Date
    543    header field) when more than one suitable response is stored. They can also
     558   A cache &MUST; use the most recent response (as determined by the Date
     559   header field) when more than one suitable response is stored. It can also
    544560   forward a request with "Cache-Control: max-age=0" or "Cache-Control:
    545561   no-cache" to disambiguate which response to use.
    546562</t>
    547563<t>
    548    An HTTP implementation without a clock &MUST-NOT; used stored responses
    549    without revalidating them on every use. An HTTP cache, especially a shared
     564   A cache that does not have a clock available &MUST-NOT; used stored responses
     565   without revalidating them on every use. A cache, especially a shared
    550566   cache, &SHOULD; use a mechanism, such as NTP <xref target="RFC1305"/>, to
    551567   synchronize its clock with a reliable external standard.
    … …  
    576592</t>
    577593<t>
    578    Since origin servers do not always provide explicit expiration times, HTTP
    579    caches &MAY; assign heuristic expiration times when explicit times are not
    580    specified, employing algorithms that use other heade field values (such as the
    581    Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1
     594   Since origin servers do not always provide explicit expiration times,
     595   a cache &MAY; assign a heuristic expiration time when an explicit time is not
     596   specified, employing algorithms that use other header field values (such as the
     597   Last-Modified time) to estimate a plausible expiration time. This
    582598   specification does not provide specific algorithms, but does impose
    583599   worst-case constraints on their results.
    … …  
    642658   status code whose definition allows heuristic freshness to be used
    643659   (including the following in &status-codes;: 200, 203, 206, 300, 301 and
    644    410), a heuristic expiration time &MAY; be calculated. Heuristics
    645    &MUST-NOT; be used for response status codes that do not explicitly allow
    646    it.
    647 </t>
    648 <t>
    649    When a heuristic is used to calculate freshness lifetime, the cache
     660   410), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT;
     661   use heuristics to determine freshness for responses with status codes that do
     662   not explicitly allow it.
     663</t>
     664<t>
     665   When a heuristic is used to calculate freshness lifetime, a cache
    650666   &SHOULD; attach a Warning header field with a 113 warn-code to the response if
    651667   its current_age is more than 24 hours and such a warning is not already
    … …  
    654670<t>
    655671   Also, if the response has a Last-Modified header field (&header-last-modified;),
    656    the heuristic expiration value &SHOULD; be no more than some fraction of
    657    the interval since that time. A typical setting of this fraction might be
    658    10%.
     672   a cache &SHOULD-NOT; use a heuristic expiration value that is more than some
     673   fraction of the interval since that time. A typical setting of this fraction
     674   might be 10%.
    659675</t>
    660676<x:note>
    … …  
    712728      <t>
    713729         The term "now" means "the current value of the clock at the host
    714          performing the calculation". Hosts that use HTTP, but especially
    715          hosts running origin servers and caches, &SHOULD; use NTP (<xref
    716          target="RFC1305"/>) or some similar protocol to synchronize their
     730         performing the calculation". A cache &SHOULD; use NTP (<xref
     731         target="RFC1305"/>) or some similar protocol to synchronize its
    717732         clocks to a globally accurate time standard.
    718733      </t>
    … …  
    744759      the result is negative, the result is replaced by zero.</t>
    745760      <t>the "corrected_age_value", if all of the caches along the response
    746       path implement HTTP/1.1; note this value &MUST; be interpreted relative
     761      path implement HTTP/1.1. A cache &MUST; interpret this value relative
    747762      to the time the request was initiated, not the time that the response
    748763      was received.</t>
    … …  
    780795</t>
    781796<t>
    782    Caches &MUST-NOT; return a stale response if it is prohibited by an
     797   A cache &MUST-NOT; return a stale response if it is prohibited by an
    783798   explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    784799   directive, a "must-revalidate" cache-response-directive, or an applicable
    … …  
    787802</t>
    788803<t>
    789    Caches &SHOULD-NOT; return stale responses unless they are disconnected
     804   A cache &SHOULD-NOT; return stale responses unless it is disconnected
    790805   (i.e., it cannot contact the origin server or otherwise find a forward
    791806   path) or otherwise explicitly allowed (e.g., the max-stale request
    … …  
    793808</t>
    794809<t>
    795    Stale responses &SHOULD; have a Warning header field with the 110 warn-code (see
    796    <xref target="header.warning" />). Likewise, the 112 warn-code &SHOULD; be
    797    sent on stale responses if the cache is disconnected.
     810   A cache &SHOULD; append a Warning header field with the 110 warn-code (see
     811   <xref target="header.warning" />) to stale responses. Likewise, a cache
     812   &SHOULD; add the 112 warn-code to stale responses if the cache is
     813   disconnected.
    798814</t>
    799815<t>
    … …  
    820836</t>
    821837<t>
    822    When sending such a conditional request, the cache &SHOULD; add an
     838   When sending such a conditional request, a cache &SHOULD; add an
    823839   If-Modified-Since header field whose value is that of the Last-Modified header
    824840   field from the selected (see <xref target="caching.negotiated.responses"/>)
    … …  
    826842</t>
    827843<t>
    828    Additionally, the cache &SHOULD; add an If-None-Match header field whose value is
     844   Additionally, a cache &SHOULD; add an If-None-Match header field whose value is
    829845   that of the ETag header field(s) from all responses stored for the requested URI,
    830846   if present. However, if any of the stored responses contains only partial
    831    content, its entity-tag &SHOULD-NOT; be included in the If-None-Match
     847   content, the cache &SHOULD-NOT; include its entity-tag in the If-None-Match
    832848   header field unless the request is for a range that would be fully
    833849   satisfied by that stored response.
    … …  
    840856   A full response (i.e., one with a response body) indicates that none of the
    841857   stored responses nominated in the conditional request is suitable. Instead,
    842    the full response &SHOULD; be used to satisfy the request and &MAY; replace
    843    the stored response.
     858   a cache &SHOULD; use the full response to satisfy the request and &MAY;
     859   replace the stored response.
    844860</t>
    845861<t>
    … …  
    854870   title="Request Methods that Invalidate">
    855871<t>
    856    Because unsafe methods (&safe-methods;) have the potential for changing
     872   Because unsafe request methods (&safe-methods;) have the potential for changing
    857873   state on the origin server, intervening caches can use them to keep their
    858874   contents up-to-date.
    859875</t>
    860876<t>
    861    The following HTTP methods &MUST; cause a cache to invalidate the effective
    862    Request URI (&effective-request-uri;) as well as the URI(s) in the Location
    863    and Content-Location header fields (if present):
     877   A cache &MUST; invalidate the effective Request URI
     878   (&effective-request-uri;) as well as the URI(s) in the Location
     879   and Content-Location header fields (if present) when the following
     880   request methods are received:
    864881   <list style="symbols">
    865882      <t>PUT</t>
    … …  
    869886</t>
    870887<t>
    871    An invalidation based on a URI from a Location or Content-Location header field
    872    &MUST-NOT; be performed if the host part of that URI differs from the host
    873    part in the effective request URI (&effective-request-uri;). This helps
    874    prevent denial of service attacks.
    875 </t>
    876 <t>
    877    A cache that passes through requests for methods it does not understand
     888   However, a cache &MUST-NOT; invalidate a URI from a
     889   Location or Content-Location header field if the host part of that URI
     890   differs from the host part in the effective request URI
     891   (&effective-request-uri;). This helps prevent denial of service attacks.
     892</t>
     893<t>
     894   A cache that passes through requests with methods it does not understand
    878895   &SHOULD; invalidate the effective request URI (&effective-request-uri;).
    879896</t>
    … …  
    895912
    896913<t>
    897    Shared caches &MUST-NOT; use a cached response to a request with an
     914   A shared cache &MUST-NOT; use a cached response to a request with an
    898915   Authorization header field (&header-authorization;) to satisfy any subsequent
    899916   request unless a cache directive that allows such responses to be stored is
    … …  
    9831000</t>
    9841001<t>
    985    If the new response's status code is 206 (partial content), both the stored
    986    and new responses &MUST; have validators, and those validators &MUST; match
    987    using the strong comparison function (see &weak-and-strong;). Otherwise,
    988    the responses &MUST-NOT; be combined.
     1002   When the new response's status code is 206 (partial content), a cache
     1003   &MUST-NOT; combine it with the old response if either response does not
     1004   have a validator, and &MUST-NOT; combine it with the old response when
     1005   those validators do not match with the strong comparison function
     1006   (see &weak-and-strong;).
    9891007</t>
    9901008<t>
    … …  
    9921010   except that
    9931011   <list style="symbols">
    994       <t>any stored Warning header fields with warn-code 1xx (see <xref
    995       target="header.warning" />) &MUST; be deleted.</t>
    996       <t>any stored Warning header fields with warn-code 2xx &MUST; be retained.</t>
    997       <t>any other header fields provided in the new response &MUST; replace all
     1012      <t>a cache &MUST; delete any stored Warning header fields with warn-code 1xx (see <xref
     1013      target="header.warning" />).</t>
     1014      <t>a cache &MUST; retain any stored Warning header fields with warn-code 2xx.</t>
     1015      <t>a cache &MUST; use other header fields provided in the new response to replace all
    9981016      instances of the corresponding header fields from the stored response.</t>
    9991017   </list>
    10001018</t>
    10011019<t>
    1002    The updated response header fields &MUST; be used to replace those of the stored
    1003    response in cache (unless the stored response is removed from cache). In
    1004    the case of a 206 response, the combined representation &MAY; be stored.
     1020   A cache &MUST; use the updated response header fields to replace those of the stored
     1021   response (unless the stored response is removed). In
     1022   the case of a 206 response, a cache &MAY; store the combined representation.
    10051023</t>
    10061024</section>
    … …  
    10401058   If a cache receives a value larger than the largest positive integer it can
    10411059   represent, or if any of its age calculations overflows, it &MUST; transmit
    1042    an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>). Caches
    1043    &SHOULD; use an arithmetic type of at least 31 bits of range.
     1060   an Age header field with a field-value of 2147483648 (2<x:sup>31</x:sup>).
     1061   Recipients parsing the Age header field-value &SHOULD; use an arithmetic type of
     1062   at least 31 bits of range.
    10441063</t>
    10451064<t>
    … …  
    10671086</t>
    10681087<t>
    1069    HTTP/1.1 caches &MUST; obey the requirements of the Cache-Control
     1088   A cache &MUST; obey the requirements of the Cache-Control
    10701089   directives defined in this section. See <xref
    10711090   target="cache.control.extensions"/> for information about how Cache-Control
    … …  
    10801099</x:note>
    10811100<t>
    1082    Cache directives &MUST; be passed through by a proxy or gateway
    1083    application, regardless of their significance to that application, since
    1084    the directives might be applicable to all recipients along the
    1085    request/response chain. It is not possible to target a directive to a
    1086    specific cache.
     1101   An intermediary (i.e., a proxy or gateway, whether or not it implements
     1102   a cache) &MUST; pass cache directives through, regardless of their
     1103   significance to that application, since the directives might be applicable
     1104   to all recipients along the request/response chain. It is not possible to
     1105   target a directive to a specific cache.
    10871106</t>
    10881107<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Cache-Control"/><iref primary="true" item="Grammar" subitem="Cache-Control-v"/><iref primary="true" item="Grammar" subitem="cache-extension"/>
    … …  
    11181137   <iref item="no-cache" primary="true" subitem="Cache Directive" />
    11191138   <list>
    1120       <t>The no-cache request directive indicates that a stored response
    1121       &MUST-NOT; be used to satisfy the request without successful validation
    1122       on the origin server.</t>
     1139      <t>The no-cache request directive indicates that a cache &MUST-NOT;
     1140      use a stored response to satisfy the request without successful
     1141      validation on the origin server.</t>
    11231142   </list>
    11241143</t>
    … …  
    11301149      <t>The no-store request directive indicates that a cache &MUST-NOT;
    11311150      store any part of either this request or any response to it. This
    1132       directive applies to both non-shared and shared caches. "&MUST-NOT;
     1151      directive applies to both private and shared caches. "&MUST-NOT;
    11331152      store" in this context means that the cache &MUST-NOT; intentionally
    11341153      store the information in non-volatile storage, and &MUST; make a
    … …  
    11851204   <iref item="no-transform" primary="true" subitem="Cache Directive" />
    11861205   <list>
    1187       <t>The no-transform request directive indicates that an intermediate
    1188       cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or
    1189       Content-Type request header fields, nor the request representation.</t>
     1206      <t>The no-transform request directive indicates that an intermediary
     1207        (whether or not it implements a cache) &MUST-NOT; change the
     1208        Content-Encoding, Content-Range or Content-Type request header fields,
     1209        nor the request representation.</t>
    11901210   </list>
    11911211</t>
    … …  
    12001220      with the other constraints of the request, or respond with a 504
    12011221      (Gateway Timeout) status code. If a group of caches is being operated as
    1202       a unified system with good internal connectivity, such a request &MAY;
    1203       be forwarded within that group of caches.</t>
     1222      a unified system with good internal connectivity, a member cache &MAY;
     1223      forward such a request within that group of caches.</t>
    12041224   </list>
    12051225</t>
    … …  
    12301250   <iref item="public" primary="true" subitem="Cache Directive" />
    12311251   <list>
    1232       <t>The public response directive indicates that the response &MAY; be
    1233       cached, even if it would normally be non-cacheable or cacheable only
    1234       within a non-shared cache. (See also Authorization,
     1252      <t>The public response directive indicates that a cache &MAY; store
     1253      the response, even if it would normally be non-cacheable or cacheable only
     1254      within a private cache. (See also Authorization,
    12351255      &header-authorization;, for additional details.) </t>
    12361256  </list>
    … …  
    12431263      <t>The private response directive indicates that the response message is
    12441264      intended for a single user and &MUST-NOT; be stored by a shared cache. A
    1245       private (non-shared) cache &MAY; store the response.</t>
     1265      private cache &MAY; store the response.</t>
    12461266      <t>If the private response directive specifies one or more field-names,
    12471267      this requirement is limited to the field-values associated with the
    1248       listed response header fields. That is, the specified field-names(s)
    1249       &MUST-NOT; be stored by a shared cache, whereas the remainder of the
    1250       response message &MAY; be.</t>
     1268      listed response header fields. That is, a shared cache &MUST-NOT; store
     1269      the specified field-names(s), whereas it &MAY; store the remainder of the
     1270      response message.</t>
    12511271      <t> <x:h>Note:</x:h> This usage of the word private only controls where
    12521272      the response can be stored; it cannot ensure the privacy of the message
    … …  
    12691289      <t>If the no-cache response directive specifies one or more field-names,
    12701290      this requirement is limited to the field-values associated with the
    1271       listed response header fields. That is, the specified field-name(s) &MUST-NOT;
    1272       be sent in the response to a subsequent request without successful
     1291      listed response header fields. That is, a cache &MUST-NOT; send the
     1292      specified field-name(s) in the response to a subsequent request without successful
    12731293      validation on the origin server. This allows an origin server to prevent
    12741294      the re-use of certain header fields in a response, while still allowing
    … …  
    12881308      <t>The no-store response directive indicates that a cache &MUST-NOT;
    12891309      store any part of either the immediate request or response. This
    1290       directive applies to both non-shared and shared caches. "&MUST-NOT;
     1310      directive applies to both private and shared caches. "&MUST-NOT;
    12911311      store" in this context means that the cache &MUST-NOT; intentionally
    12921312      store the information in non-volatile storage, and &MUST; make a
    … …  
    13051325   <list>
    13061326      <t>The must-revalidate response directive indicates that once it has
    1307       become stale, the response &MUST-NOT; be used to satisfy subsequent
     1327      become stale, a cache &MUST-NOT; use the response to satisfy subsequent
    13081328      requests without successful validation on the origin server.</t>
    13091329      <t>The must-revalidate directive is necessary to support reliable
    1310       operation for certain protocol features. In all circumstances an
    1311       HTTP/1.1 cache &MUST; obey the must-revalidate directive; in particular,
    1312       if the cache cannot reach the origin server for any reason, it &MUST;
     1330      operation for certain protocol features. In all circumstances a
     1331      cache &MUST; obey the must-revalidate directive; in particular,
     1332      if a cache cannot reach the origin server for any reason, it &MUST;
    13131333      generate a 504 (Gateway Timeout) response.</t>
    1314       <t>Servers &SHOULD; send the must-revalidate directive if and only if
     1334      <t>A server &SHOULD; send the must-revalidate directive if and only if
    13151335      failure to validate a request on the representation could result in
    13161336      incorrect operation, such as a silently unexecuted financial
    … …  
    13251345      <t>The proxy-revalidate response directive has the same meaning as the
    13261346      must-revalidate response directive, except that it does not apply to
    1327       non-shared caches.</t>
     1347      private caches.</t>
    13281348   </list>
    13291349</t>
    … …  
    13551375   <iref item="no-transform" primary="true" subitem="Cache Directive" />
    13561376   <list>
    1357       <t>The no-transform response directive indicates that an intermediate
    1358       cache or proxy &MUST-NOT; change the Content-Encoding, Content-Range or
    1359       Content-Type response header fields, nor the response representation.</t>
     1377      <t>The no-transform response directive indicates that an intermediary
     1378      (regardless of whether it implements a cache) &MUST-NOT; change the
     1379      Content-Encoding, Content-Range or Content-Type response header fields,
     1380      nor the response representation.</t>
    13601381   </list>
    13611382</t>
    … …  
    13871408   For example, consider a hypothetical new response directive called
    13881409   "community" that acts as a modifier to the private directive. We define
    1389    this new directive to mean that, in addition to any non-shared cache, any
     1410   this new directive to mean that, in addition to any private cache, any
    13901411   cache that is shared only by members of the community named within its
    13911412   value may cache the response. An origin server wishing to allow the UCI
    … …  
    14021423</t>
    14031424<t>
    1404    Unrecognized cache directives &MUST; be ignored; it is assumed that any
     1425   A cache &MUST; be ignore unrecognized cache directives; it is assumed that any
    14051426   cache directive likely to be unrecognized by an HTTP/1.1 cache will be
    14061427   combined with standard directives (or the response's default cacheability)
    … …  
    14131434</t>
    14141435<t>
    1415    Registrations &MUST; include the following fields:
     1436   A registration &MUST; include the following fields:
    14161437   <list style="symbols">
    14171438      <t>Cache Directive Name</t>
    … …  
    14471468<t>
    14481469   The field-value is an absolute date and time as defined by HTTP-date in
    1449    &full-date;; it &MUST; be sent in rfc1123-date format.
     1470   &full-date;; a sender &MUST; use the rfc1123-date format.
    14501471</t>
    14511472<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/><iref primary="true" item="Grammar" subitem="Expires-v"/>
    … …  
    14671488</x:note>
    14681489<t>
    1469    HTTP/1.1 servers &SHOULD-NOT; send Expires dates more than one year in the
     1490   A server &SHOULD-NOT; send Expires dates more than one year in the
    14701491   future.
    14711492</t>
    14721493<t>
    1473    HTTP/1.1 clients and caches &MUST; treat other invalid date formats,
     1494   A cache &MUST; treat other invalid date formats,
    14741495   especially including the value "0", as in the past (i.e., "already
    14751496   expired").
    … …  
    14981519</artwork></figure>
    14991520<t>
    1500    When the no-cache directive is present in a request message, an application
     1521   When the no-cache directive is present in a request message, a cache
    15011522   &SHOULD; forward the request toward the origin server even if it has a
    1502    cached copy of what is being requested. This pragma directive has the same
     1523   stored copy of what is being requested. This pragma directive has the same
    15031524   semantics as the no-cache response directive (see <xref
    15041525   target="cache-response-directive" />) and is defined here for backward
    1505    compatibility with HTTP/1.0. Clients &SHOULD; include both header fields
     1526   compatibility with HTTP/1.0. A client &SHOULD; include both header fields
    15061527   when a no-cache request is sent to a server not known to be HTTP/1.1
    1507    compliant. HTTP/1.1 caches &SHOULD; treat "Pragma: no-cache" as if the
     1528   compliant. A cache &SHOULD; treat "Pragma: no-cache" as if the
    15081529   client had sent "Cache-Control: no-cache".
    15091530</t>
    … …  
    15511572</t>
    15521573<t>
    1553    Servers &SHOULD; include a Vary header field with any cacheable response
     1574   A server &SHOULD; include a Vary header field with any cacheable response
    15541575   that is subject to server-driven negotiation. Doing so allows a cache to
    15551576   properly interpret future requests on that resource and informs the user
    … …  
    15641585   to the request-header fields (e.g., the network address of the client), play a
    15651586   role in the selection of the response representation; therefore, a cache
    1566    cannot determine whether this response is appropriate. The "*" value
    1567    &MUST-NOT; be generated by a proxy server.
     1587   cannot determine whether this response is appropriate. A proxy &MUST-NOT;
     1588   generate the "*" value.
    15681589</t>
    15691590<t>
    … …  
    16341655   <list style="symbols">
    16351656      <t>1xx Warnings describe the freshness or validation status of the
    1636       response, and so &MUST; be deleted by caches after validation. They can
     1657      response, and so &MUST; be deleted by a cache after validation. They can
    16371658      only be generated by a cache when validating a cached entry, and
    16381659      &MUST-NOT; be generated in any other situation.</t>
    16391660      <t>2xx Warnings describe some aspect of the representation that is not
    16401661      rectified by a validation (for example, a lossy compression of the
    1641       representation) and &MUST-NOT; be deleted by caches after validation,
     1662      representation) and &MUST-NOT; be deleted by a cache after validation,
    16421663      unless a full response is returned, in which case they &MUST; be.</t>
    16431664   </list>
    … …  
    16501671</t>
    16511672<t>
    1652    If an implementation receives a message with a warning-value that includes
     1673   If a system receives a message with a warning-value that includes
    16531674   a warn-date, and that warn-date is different from the Date value in the
    16541675   response, then that warning-value &MUST; be deleted from the message before
    … …  
    16641685   110 Response is stale
    16651686   <list>
    1666       <t>&SHOULD; be included whenever the returned response is stale.</t>
     1687      <t>A cache &SHOULD; include this whenever the returned response is stale.</t>
    16671688   </list>
    16681689</t>
    … …  
    16701691   111 Revalidation failed
    16711692   <list>
    1672       <t>&SHOULD; be included if a cache returns a stale response because an
     1693      <t>A cache &SHOULD; include this when returning a stale response because an
    16731694      attempt to validate the response failed, due to an inability to reach
    16741695      the server.</t>
    … …  
    16781699   112 Disconnected operation
    16791700   <list>
    1680       <t>&SHOULD; be included if the cache is intentionally disconnected from
     1701      <t>A cache &SHOULD; b include this if it is intentionally disconnected from
    16811702      the rest of the network for a period of time.</t>
    16821703   </list>
    … …  
    16851706   113 Heuristic expiration
    16861707   <list>
    1687       <t>&SHOULD; be included if the cache heuristically chose a freshness
     1708      <t>A cache &SHOULD; include this if it heuristically chose a freshness
    16881709      lifetime greater than 24 hours and the response's age is greater than 24
    16891710      hours.</t>
    … …  
    17011722   214 Transformation applied
    17021723   <list>
    1703       <t>&MUST; be added by an intermediate proxy if it applies any
     1724      <t>&MUST; be added by a proxy if it applies any
    17041725      transformation to the representation, such as changing the
    17051726      content-coding, media-type, or modifying the representation data, unless
Note: See TracChangeset for help on using the changeset viewer.