Changeset 183


Ignore:
Timestamp:
02/02/08 01:04:56 (14 years ago)
Author:
fielding@…
Message:

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).

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p4-conditional.html

    r182 r183  
    745745   ETag: W/"xyzzy"
    746746   ETag: ""
    747 </pre><div id="rfc.iref.i.1"></div>
     747</pre><p id="rfc.section.6.1.p.4">The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. This might allow more reliable
     748         validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date
     749         values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification
     750         dates.
     751      </p>
     752      <p id="rfc.section.6.1.p.5">The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an
     753         appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality
     754         would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0)
     755         are never used for purposes of validating a cache entry.
     756      </p>
     757      <div id="rfc.iref.i.1"></div>
    748758      <div id="rfc.iref.h.2"></div>
    749759      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.if-match" href="#header.if-match">If-Match</a></h2>
    … …  
    899909      </p>
    900910      <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.
     911      </p>
     912      <p id="rfc.section.6.6.p.9">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered
     913         to be valid if the entity has not been modified since the Last-Modified value.
    901914      </p>
    902915      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r182 r183  
    614614   ETag: ""
    615615</artwork></figure>
     616<t>
     617   The ETag response-header field value, an entity tag, provides for an
     618   "opaque" cache validator. This might allow more reliable validation
     619   in situations where it is inconvenient to store modification dates,
     620   where the one-second resolution of HTTP date values is not
     621   sufficient, or where the origin server wishes to avoid certain
     622   paradoxes that might arise from the use of modification dates.
     623</t>
     624<t>
     625   The principle behind entity tags is that only the service author
     626   knows the semantics of a resource well enough to select an
     627   appropriate cache validation mechanism, and the specification of any
     628   validator comparison function more complex than byte-equality would
     629   open up a can of worms. Thus, comparisons of any other headers
     630   (except Last-Modified, for compatibility with HTTP/1.0) are never
     631   used for purposes of validating a cache entry.
     632</t>
    616633</section>
    617634
    … …  
    927944   HTTP/1.1 servers &SHOULD; send Last-Modified whenever feasible.
    928945</t>
     946<t>
     947   The Last-Modified entity-header field value is often used as a cache
     948   validator. In simple terms, a cache entry is considered to be valid
     949   if the entity has not been modified since the Last-Modified value.
     950</t>
    929951</section>
    930952

  • 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>

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

    r182 r183  
    1616  <!ENTITY ID-YEAR "2008">
    1717  <!ENTITY messaging                   "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     18  <!ENTITY conditional                 "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1819  <!ENTITY combining-byte-ranges       "<xref target='Part5' x:rel='#combining.byte.ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY entity-length               "<xref target='Part3' x:rel='#entity.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    20   <!ENTITY entity-header-fields        "<xref target='Part4' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    21   <!ENTITY entity-tags                 "<xref target='Part4' x:rel='#entity.tags' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2221  <!ENTITY full-date                   "<xref target='Part1' x:rel='#full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2322  <!ENTITY header-authorization        "<xref target='Part7' x:rel='#header.authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2423  <!ENTITY header-connection           "<xref target='Part1' x:rel='#header.connection' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2524  <!ENTITY header-date                 "<xref target='Part1' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    26   <!ENTITY weak-and-strong-validators  "<xref target='Part4' x:rel='#weak.and.strong.validators' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2725  <!ENTITY message-headers             "<xref target='Part1' x:rel='#message.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2826  <!ENTITY message-length              "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    962960   server (or possibly an intermediate cache with a fresh response) to
    963961   see if its cached entry is still usable. We call this "validating"
    964    the cache entry. Since we do not want to have to pay the overhead of
    965    retransmitting the full response if the cached entry is good, and we
    966    do not want to pay the overhead of an extra round trip if the cached
    967    entry is invalid, HTTP/1.1 supports the use of
    968    conditional methods.
    969 </t>
    970 <t>
    971    The key protocol features for supporting conditional methods are
    972    those concerned with "cache validators." When an origin server
    973    generates a full response, it attaches some sort of validator to it,
    974    which is kept with the cache entry. When a client (user agent or
    975    proxy cache) makes a conditional request for a resource for which it
    976    has a cache entry, it includes the associated validator in the
    977    request.
    978 </t>
    979 <t>
    980    The server then checks that validator against the current validator
    981    for the entity, and, if they match (see &weak-and-strong-validators;), it responds
    982    with a special status code (usually, 304 (Not Modified)) and no
    983    entity-body. Otherwise, it returns a full response (including
    984    entity-body). Thus, we avoid transmitting the full response if the
    985    validator matches, and we avoid an extra round trip if it does not
    986    match.
    987 </t>
    988 <t>
    989    In HTTP/1.1, a conditional request looks exactly the same as a normal
    990    request for the same resource, except that it carries a special
    991    header (which includes the validator) that implicitly turns the
    992    method (usually, GET) into a conditional.
    993 </t>
    994 <t>
    995    The protocol includes both positive and negative senses of cache-validating
    996    conditions. That is, it is possible to request either that
    997    a method be performed if and only if a validator matches or if and
    998    only if no validators match.
    999   <list><t>
    1000       <x:h>Note:</x:h> a response that lacks a validator may still be cached, and
    1001       served from cache until it expires, unless this is explicitly
    1002       prohibited by a cache-control directive. However, a cache cannot
    1003       do a conditional retrieval if it does not have a validator for the
    1004       entity, which means it will not be refreshable after it expires.
    1005   </t></list>
    1006 </t>
    1007 
    1008 <section title="Last-Modified Dates" anchor="last-modified.dates">
    1009 <t>
    1010    The Last-Modified entity-header field value is often used as a cache
    1011    validator. In simple terms, a cache entry is considered to be valid
    1012    if the entity has not been modified since the Last-Modified value.
    1013 </t>
    1014 </section>
    1015 
    1016 <section title="Entity Tag Cache Validators" anchor="entity.tag.cache.validators">
    1017 <t>
    1018    The ETag response-header field value, an entity tag, provides for an
    1019    "opaque" cache validator. This might allow more reliable validation
    1020    in situations where it is inconvenient to store modification dates,
    1021    where the one-second resolution of HTTP date values is not
    1022    sufficient, or where the origin server wishes to avoid certain
    1023    paradoxes that might arise from the use of modification dates.
    1024 </t>
    1025 <t>
    1026    Entity Tags are described in &entity-tags;. The headers used with entity
    1027    tags are described in &entity-header-fields;.
    1028 </t>
    1029 </section>
    1030 
    1031 <section title="Non-validating Conditionals" anchor="non-validating.conditionals">
    1032 <t>
    1033    The principle behind entity tags is that only the service author
    1034    knows the semantics of a resource well enough to select an
    1035    appropriate cache validation mechanism, and the specification of any
    1036    validator comparison function more complex than byte-equality would
    1037    open up a can of worms. Thus, comparisons of any other headers
    1038    (except Last-Modified, for compatibility with HTTP/1.0) are never
    1039    used for purposes of validating a cache entry.
    1040 </t>
    1041 </section>
     962   the cache entry.
     963</t>
     964<t>
     965   HTTP's conditional request mechanism, defined in &conditional;, is
     966   used to avoid retransmitting the response payload when the cached entry
     967   is valid.  When a cached response includes one or more "cache validators,"
     968   such as the field values of an ETag or Last-Modified header field, then
     969   a validating GET request &SHOULD; be made conditional to those field values.
     970   The server checks the conditional request's validator against the current
     971   state of the requested resource and, if they match, the server responds
     972   with a 304 (Not Modified) status code to indicate that the cached response
     973   can be refreshed and reused without retransmitting the response payload.
     974   If the validator does not match the current state of the requested
     975   resource, then the server returns a full response, including payload,
     976   so that the request can be satisfied and the cache entry supplanted
     977   without the need for an additional network round-trip.
     978</t>
    1042979</section>
    1043980
Note: See TracChangeset for help on using the changeset viewer.