Changeset 2247 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 08/05/13 13:06:21 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r2246 r2247 204 204 </artwork></figure> 205 205 <t> 206 If a n implementationreceives a delta-seconds value larger than the largest206 If a cache receives a delta-seconds value larger than the largest 207 207 positive integer it can represent, or if any of its subsequent calculations 208 208 overflows, it &MUST; consider the value to be 2147483648 209 209 (2<x:sup>31</x:sup>). Recipients parsing a delta-seconds value &MUST; use 210 210 an arithmetic type of at least 31 bits of range, and senders &MUST-NOT; 211 senddelta-seconds with a value greater than 2147483648.211 generate delta-seconds with a value greater than 2147483648. 212 212 </t> 213 213 </section> … … 246 246 The primary <x:dfn>cache key</x:dfn> consists of the request method and 247 247 target URI. However, since HTTP caches in common use today are typically 248 limited to caching responses to GET, many implementations simply decline248 limited to caching responses to GET, many caches simply decline 249 249 other methods and use only the URI as the primary cache key. 250 250 </t> … … 736 736 </t> 737 737 <t> 738 A cache &MUST-NOT; senda stale response if it is prohibited by an738 A cache &MUST-NOT; generate a stale response if it is prohibited by an 739 739 explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 740 740 directive, a "must-revalidate" cache-response-directive, or an applicable … … 760 760 an entire response, or a <x:ref>304 (Not Modified)</x:ref> response) that 761 761 it would normally forward to the requesting client, and the received 762 response is no longer fresh, the cache canforward it to the requesting762 response is no longer fresh, the cache &MAY; forward it to the requesting 763 763 client without adding a new <x:ref>Warning</x:ref> (but without removing 764 764 any existing Warning header fields). A cache shouldn't attempt to validate … … 845 845 &weak-and-strong;), then that strong validator identifies the selected 846 846 representation for update. All of the stored responses with the same 847 strong validator are selected. If none of the stored responses contain 848 the same strong validator, then the new response &MUST-NOT; be usedto847 strong validator are selected. If none of the stored responses contain the 848 same strong validator, then the cache &MUST-NOT; use the new response to 849 849 update any stored responses. 850 850 </t> … … 1283 1283 &Note; Although it has been back-ported to many implementations, some 1284 1284 HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache 1285 response directives with field-names are often handled by implementations1285 response directives with field-names are often handled by caches 1286 1286 as if an unqualified no-cache directive was received; i.e., the special 1287 1287 handling for the qualified form is not widely implemented. … … 1367 1367 where the response can be stored; it cannot ensure the privacy of the 1368 1368 message content. Also, private response directives with field-names are 1369 often handled by implementations as if an unqualified private directive1369 often handled by caches as if an unqualified private directive 1370 1370 was received; i.e., the special handling for the qualified form is not 1371 1371 widely implemented. … … 1579 1579 <t> 1580 1580 When the <x:ref>Cache-Control</x:ref> header field is not present in a 1581 request, the no-cache request pragma-directive &MUST; have the same effect1582 on caches as if "Cache-Control: no-cache" were present (see <xref1583 target="cache-request-directive" />).1581 request, caches &MUST; consider the no-cache request pragma-directive as 1582 having the same effect as if "Cache-Control: no-cache" were present (see 1583 <xref target="cache-request-directive" />). 1584 1584 </t> 1585 1585 <t>
Note: See TracChangeset
for help on using the changeset viewer.