Changeset 493
- Timestamp:
- 04/03/09 06:21:25 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p6-cache.xml
r492 r493 473 473 <t>When a response is "fresh" in the cache, it can be used to satisfy subsequent 474 474 requests without contacting the origin server, thereby improving efficiency.</t> 475 <t>The primary mechanism for avoiding requests is for an origin server to provide an475 <t>The primary mechanism for determining freshness is for an origin server to provide an 476 476 explicit expiration time in the future, using either the Expires header (<xref 477 477 target="header.expires" />) or the max-age response cache directive (<xref … … 483 483 stale, so that caches should validate it before using it for subsequent requests. <cref>This wording may cause confusion, because the response may still be served stale.</cref></t> 484 484 <t>Since origin servers do not always provide explicit expiration times, HTTP caches may 485 a ssign heuristic expiration times when they are not specified, employing algorithms that485 also assign heuristic expiration times when they are not specified, employing algorithms that 486 486 use other header values (such as the Last-Modified time) to estimate a plausible 487 487 expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does 488 488 impose worst-case constraints on their results.</t> 489 <t>The calculation to determine if a response has expiredis:</t>489 <t>The calculation to determine if a response is fresh is:</t> 490 490 <figure> 491 491 <artwork type="code">
Note: See TracChangeset
for help on using the changeset viewer.