Changeset 183
- Timestamp:
- 02/02/08 01:04:56 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r182 r183 745 745 ETag: W/"xyzzy" 746 746 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> 748 758 <div id="rfc.iref.h.2"></div> 749 759 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.if-match" href="#header.if-match">If-Match</a></h2> … … 899 909 </p> 900 910 <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. 901 914 </p> 902 915 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> -
draft-ietf-httpbis/latest/p4-conditional.xml
r182 r183 614 614 ETag: "" 615 615 </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> 616 633 </section> 617 634 … … 927 944 HTTP/1.1 servers &SHOULD; send Last-Modified whenever feasible. 928 945 </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> 929 951 </section> 930 952 -
draft-ietf-httpbis/latest/p6-cache.html
r182 r183 512 512 </ul> 513 513 </li> 514 <li class="tocline0">4. <a href="#validation.model">Validation Model</a><ul class="toc"> 515 <li class="tocline1">4.1 <a href="#last-modified.dates">Last-Modified Dates</a></li> 516 <li class="tocline1">4.2 <a href="#entity.tag.cache.validators">Entity Tag Cache Validators</a></li> 517 <li class="tocline1">4.3 <a href="#non-validating.conditionals">Non-validating Conditionals</a></li> 518 </ul> 519 </li> 514 <li class="tocline0">4. <a href="#validation.model">Validation Model</a></li> 520 515 <li class="tocline0">5. <a href="#response.cacheability">Response Cacheability</a></li> 521 516 <li class="tocline0">6. <a href="#constructing.responses.from.caches">Constructing Responses From Caches</a><ul class="toc"> … … 933 928 <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 934 929 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> <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> <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> <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. 977 938 </p> 978 939 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h1> … … 2051 2012 </ul> 2052 2013 </li> 2053 <li class="indline1"><em>Part4</em> <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> <a class="iref" href="#rfc.xref.Part4.2">4.2</a></li> 2055 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.1">4</a></li> 2056 <li class="indline1"><em>Section 6</em> <a class="iref" href="#rfc.xref.Part4.3">4.2</a></li> 2057 </ul> 2058 </li> 2014 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">4</a>, <a class="iref" href="#Part4"><b>19.1</b></a></li> 2059 2015 <li class="indline1"><em>Part5</em> <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"> 2060 2016 <li class="indline1"><em>Section 4</em> <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 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.