Changeset 1739 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 08/07/12 14:50:41 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r1738 r1739 284 284 <x:dfn>validator</x:dfn> 285 285 <list> 286 <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that287 is used to find out whether a stored response is an equivalent copy of288 a representation. See &weak-and-strong;.</t>286 <t>A protocol element (e.g., an entity-tag or a <x:ref>Last-Modified</x:ref> 287 time) that is used to find out whether a stored response is an equivalent 288 copy of a representation. See &weak-and-strong;.</t> 289 289 </list> 290 290 </t> … … 297 297 current value will change if the representation body changes; i.e., 298 298 an entity-tag that is not marked as weak (&entity-tags;) or, 299 if no entity-tag is provided, a Last-Modified value that is strong300 in the sense defined by &lastmod-comparison;.</t>299 if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value 300 that is strong in the sense defined by &lastmod-comparison;.</t> 301 301 </list> 302 302 </t> … … 619 619 a cache &MAY; assign a heuristic expiration time when an explicit time is not 620 620 specified, employing algorithms that use other header field values (such as the 621 Last-Modified time) to estimate a plausible expiration time. This622 specification does not provide specific algorithms, but does impose621 <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration time. 622 This specification does not provide specific algorithms, but does impose 623 623 worst-case constraints on their results. 624 624 </t> … … 697 697 </t> 698 698 <t> 699 Also, if the response has a Last-Modifiedheader field699 Also, if the response has a <x:ref>Last-Modified</x:ref> header field 700 700 (&header-last-modified;), caches are encouraged to use a heuristic 701 701 expiration value that is no more than some fraction of the interval since … … 896 896 </t> 897 897 <t> 898 When sending such a conditional request, a cache adds an If-Modified-Since 899 header field whose value is that of the Last-Modified header field from the 900 selected (see <xref target="caching.negotiated.responses"/>) stored 901 response, if available. 902 </t> 903 <t> 904 Additionally, a cache can add an If-None-Match header field whose value is 905 that of the ETag header field(s) from all responses stored for the 906 requested URI, if present. However, if any of the stored responses contains 907 only partial content, the cache shouldn't include its entity-tag in the 908 If-None-Match header field unless the request is for a range that would be 909 fully satisfied by that stored response. 898 When sending such a conditional request, a cache adds an 899 <x:ref>If-Modified-Since</x:ref> header field whose value is that of the 900 <x:ref>Last-Modified</x:ref> header field from the selected 901 (see <xref target="caching.negotiated.responses"/>) stored response, if 902 available. 903 </t> 904 <t> 905 Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field 906 whose value is that of the <x:ref>ETag</x:ref> header field(s) from all 907 responses stored for the requested URI, if present. However, if any of the 908 stored responses contains only partial content, the cache shouldn't 909 include its entity-tag in the If-None-Match header field unless the request 910 is for a range that would be fully satisfied by that stored response. 910 911 </t> 911 912 … … 989 990 If one or more stored GET responses can be selected (as per <xref 990 991 target="caching.negotiated.responses"/>) for a HEAD request, and the 991 Content-Length, ETag or Last-Modified value of a HEAD response differs from 992 that in a selected GET response, the cache &MUST; consider that selected 993 response to be stale. 994 </t> 995 <t> 996 If the Content-Length, ETag and Last-Modified values of a HEAD response 997 (when present) are the same as that in a selected GET response (as per 998 <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update the 999 remaining headers in the stored response using the following rules: 992 Content-Length, <x:ref>ETag</x:ref> or <x:ref>Last-Modified</x:ref> value of 993 a HEAD response differs from that in a selected GET response, the cache 994 &MUST; consider that selected response to be stale. 995 </t> 996 <t> 997 If the Content-Length, <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref> 998 values of a HEAD response (when present) are the same as that in a selected 999 GET response (as per <xref target="caching.negotiated.responses"/>), the 1000 cache &SHOULD; update the remaining headers in the stored response using the 1001 following rules: 1000 1002 <list style="symbols"> 1001 1003 <t>delete any <x:ref>Warning</x:ref> header fields in the stored response … … 2331 2333 <x:defines>304</x:defines> 2332 2334 <x:defines>304 (Not Modified)</x:defines> 2335 <x:defines>ETag</x:defines> 2336 <x:defines>If-Modified-Since</x:defines> 2337 <x:defines>If-None-Match</x:defines> 2338 <x:defines>Last-Modified</x:defines> 2333 2339 </x:source> 2334 2340 </reference>
Note: See TracChangeset
for help on using the changeset viewer.