Ignore:
Timestamp:
Feb 1, 2008, 5:04:56 PM (12 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).

File:
1 edited

Legend:

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