02/02/08 01:04:56 (14 years ago)

Reduce the description of cache validation to just those bits that
summarize what a cache SHOULD do, thus avoiding the need to respecify
what is defined in part 4. Move cache validator descriptions
to the associated header field definitions in part 4 (to be merged
at a later time).

1 edited


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

    r182 r183  
    512512            </ul>
    513513         </li>
    514          <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a><ul class="toc">
    515                <li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#last-modified.dates">Last-Modified Dates</a></li>
    516                <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#entity.tag.cache.validators">Entity Tag Cache Validators</a></li>
    517                <li class="tocline1">4.3&nbsp;&nbsp;&nbsp;<a href="#non-validating.conditionals">Non-validating Conditionals</a></li>
    518             </ul>
    519          </li>
     514         <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a></li>
    520515         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Response Cacheability</a></li>
    521516         <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses From Caches</a><ul class="toc">
    933928      <p id="rfc.section.4.p.1">When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the
    934929         origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call
    935          this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if
    936          the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, HTTP/1.1
    937          supports the use of conditional methods.
    938       </p>
    939       <p id="rfc.section.4.p.2">The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server
    940          generates a full response, it attaches some sort of validator to it, which is kept with the cache entry. When a client (user
    941          agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated
    942          validator in the request.
    943       </p>
    944       <p id="rfc.section.4.p.3">The server then checks that validator against the current validator for the entity, and, if they match (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.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), it responds with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it returns a full response
    945          (including entity-body). Thus, we avoid transmitting the full response if the validator matches, and we avoid an extra round
    946          trip if it does not match.
    947       </p>
    948       <p id="rfc.section.4.p.4">In HTTP/1.1, a conditional request looks exactly the same as a normal request for the same resource, except that it carries
    949          a special header (which includes the validator) that implicitly turns the method (usually, GET) into a conditional.
    950       </p>
    951       <p id="rfc.section.4.p.5">The protocol includes both positive and negative senses of cache-validating conditions. That is, it is possible to request
    952          either that a method be performed if and only if a validator matches or if and only if no validators match.
    953       </p>
    954       <dl class="empty">
    955          <dd> <b>Note:</b> a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited
    956             by a cache-control directive. However, a cache cannot do a conditional retrieval if it does not have a validator for the entity,
    957             which means it will not be refreshable after it expires.
    958          </dd>
    959       </dl>
    960       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="last-modified.dates" href="#last-modified.dates">Last-Modified Dates</a></h2>
    961       <p id="rfc.section.4.1.p.1">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered
    962          to be valid if the entity has not been modified since the Last-Modified value.
    963       </p>
    964       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="entity.tag.cache.validators" href="#entity.tag.cache.validators">Entity Tag Cache Validators</a></h2>
    965       <p id="rfc.section.4.2.p.1">The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. This might allow more reliable
    966          validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date
    967          values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification
    968          dates.
    969       </p>
    970       <p id="rfc.section.4.2.p.2">Entity Tags are described in <a href="p4-conditional.html#entity.tags" title="Entity Tags">Section 2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. The headers used with entity tags are described in <a href="p4-conditional.html#header.fields" title="Header Field Definitions">Section 6</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
    971       </p>
    972       <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="non-validating.conditionals" href="#non-validating.conditionals">Non-validating Conditionals</a></h2>
    973       <p id="rfc.section.4.3.p.1">The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an
    974          appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality
    975          would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0)
    976          are never used for purposes of validating a cache entry.
     930         this "validating" the cache entry.
     931      </p>
     932      <p id="rfc.section.4.p.2">HTTP's conditional request mechanism, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, is used to avoid retransmitting the response payload when the cached entry is valid. When a cached response includes one
     933         or more "cache validators," such as the field values of an ETag or Last-Modified header field, then a validating GET request <em class="bcp14">SHOULD</em> be made conditional to those field values. The server checks the conditional request's validator against the current state
     934         of the requested resource and, if they match, the server responds with a 304 (Not Modified) status code to indicate that the
     935         cached response can be refreshed and reused without retransmitting the response payload. If the validator does not match the
     936         current state of the requested resource, then the server returns a full response, including payload, so that the request can
     937         be satisfied and the cache entry supplanted without the need for an additional network round-trip.
    977938      </p>
    978939      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h1>
    20512012                     </ul>
    20522013                  </li>
    2053                   <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">4</a>, <a class="iref" href="#rfc.xref.Part4.2">4.2</a>, <a class="iref" href="#rfc.xref.Part4.3">4.2</a>, <a class="iref" href="#Part4"><b>19.1</b></a><ul class="ind">
    2054                         <li class="indline1"><em>Section 2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.2">4.2</a></li>
    2055                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">4</a></li>
    2056                         <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.3">4.2</a></li>
    2057                      </ul>
    2058                   </li>
     2014                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">4</a>, <a class="iref" href="#Part4"><b>19.1</b></a></li>
    20592015                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">6.3</a>, <a class="iref" href="#rfc.xref.Part5.2">9</a>, <a class="iref" href="#Part5"><b>19.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">A.1</a><ul class="ind">
    20602016                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">6.3</a>, <a class="iref" href="#rfc.xref.Part5.2">9</a></li>
Note: See TracChangeset for help on using the changeset viewer.