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.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>
    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>
    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>
    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.
     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.
Note: See TracChangeset for help on using the changeset viewer.