Changeset 183 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 02/02/08 01:04:56 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r182 r183 16 16 <!ENTITY ID-YEAR "2008"> 17 17 <!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'/>"> 18 19 <!ENTITY combining-byte-ranges "<xref target='Part5' x:rel='#combining.byte.ranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 20 <!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'/>">22 21 <!ENTITY full-date "<xref target='Part1' x:rel='#full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 22 <!ENTITY header-authorization "<xref target='Part7' x:rel='#header.authorization' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 23 <!ENTITY header-connection "<xref target='Part1' x:rel='#header.connection' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 24 <!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'/>">27 25 <!ENTITY message-headers "<xref target='Part1' x:rel='#message.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 26 <!ENTITY message-length "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 962 960 server (or possibly an intermediate cache with a fresh response) to 963 961 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> 1042 979 </section> 1043 980
Note: See TracChangeset
for help on using the changeset viewer.