Changeset 2179 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 11/02/13 06:10:25 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r2177 r2179 395 395 target="cache.control.extensions" />) that allows it to be cached, 396 396 or</t> 397 <t>has a status code that can be served with heuristic freshness 398 (see <xref target="heuristic.freshness" />).</t> 397 <t>has a status code that is defined as cacheable 398 (see <xref target="heuristic.freshness" />), or</t> 399 <t>contains a public response cache directive.</t> 399 400 </list> 400 401 </t> … … 556 557 </t> 557 558 <t> 558 Since origin servers do not always provide explicit expiration times, a 559 cache &MAY; assign a heuristic expiration time when an explicit time is not 560 specified, employing algorithms that use other header field values (such as 561 the <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration 562 time. This specification does not provide specific algorithms, but does 563 impose worst-case constraints on their results. 559 Since origin servers do not always provide explicit expiration times, 560 caches are also allowed to use a heuristic to determine an expiration time 561 under certain circumstances (see <xref target="heuristic.freshness"/>). 564 562 </t> 565 563 <figure> … … 621 619 <section anchor="heuristic.freshness" title="Calculating Heuristic Freshness"> 622 620 <t> 623 A cache &MUST-NOT; use heuristics to determine freshness unless no explicit 624 expiration time is present in a stored response and either the status code 625 is defined as cacheable by default (including the following in 626 &status-codes;: <x:ref>200 (OK)</x:ref>, <x:ref>203 (Non-Authoritative 627 Information)</x:ref>, <x:ref>206 (Partial Content)</x:ref>, <x:ref>300 628 (Multiple Choices)</x:ref>, <x:ref>301 (Moved Permanently)</x:ref> and 629 <x:ref>410 (Gone)</x:ref>) or the response has been explicitly marked as 630 cacheable (e.g., by using the public directive without a max-age). 621 Since origin servers do not always provide explicit expiration times, a 622 cache &MAY; assign a heuristic expiration time when an explicit time is not 623 specified, employing algorithms that use other header field values (such as 624 the <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration 625 time. This specification does not provide specific algorithms, but does 626 impose worst-case constraints on their results. 627 </t> 628 <t> 629 A cache &MUST-NOT; use heuristics to determine freshness when an explicit 630 expiration time is present in the stored response. Because of the 631 requirements in <xref target="response.cacheability"/>, this means that, 632 effectively, heuristics can only be used on responses without explicit 633 freshness whose status codes are defined as cacheable, and responses 634 without explicit freshness that have been marked as explicitly cacheable 635 (e.g., with a "public" response cache directive). 636 </t> 637 <t> 638 If the response has a <x:ref>Last-Modified</x:ref> header field 639 (&header-last-modified;), caches are encouraged to use a heuristic 640 expiration value that is no more than some fraction of the interval since 641 that time. A typical setting of this fraction might be 10%. 631 642 </t> 632 643 <t> … … 635 646 response if its current_age is more than 24 hours and such a warning is not 636 647 already present. 637 </t>638 <t>639 Also, if the response has a <x:ref>Last-Modified</x:ref> header field640 (&header-last-modified;), caches are encouraged to use a heuristic641 expiration value that is no more than some fraction of the interval since642 that time. A typical setting of this fraction might be 10%.643 648 </t> 644 649 <x:note> … … 1297 1302 <t> 1298 1303 The "public" response directive indicates that any cache &MAY; store the 1299 response and reuse it for later requests, even if the response would 1300 normally be non-cacheable or cacheable only within a non-shared cache. 1301 (See <xref target="caching.authenticated.responses"/> for additional 1302 details related to the use of public in response to a request containing 1303 <x:ref>Authorization</x:ref>.) 1304 response, even if the response would normally be non-cacheable or cacheable 1305 only within a non-shared cache. (See <xref 1306 target="caching.authenticated.responses"/> for additional details related 1307 to the use of public in response to a request containing 1308 <x:ref>Authorization</x:ref>, and <xref target="response.cacheability"/> 1309 for details of how public affects responses that would normally not be 1310 stored, due to their status codes not being defined as cacheable.) 1304 1311 </t> 1305 1312 </section>
Note: See TracChangeset
for help on using the changeset viewer.