Changeset 2234 for draft-ietf-httpbis/latest/p6-cache.xml
- Timestamp:
- 07/05/13 06:14:22 (8 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.xml
r2232 r2234 144 144 </t> 145 145 146 <section anchor="intro.purpose" title="Purpose">147 146 <iref item="cache" /> 148 147 <t> 149 148 An HTTP <x:dfn>cache</x:dfn> is a local store of response messages and the 150 subsystem that controls its message storage, retrieval, and deletion. A151 cache stores cacheable responses in order to reduce the response time and149 subsystem that controls storage, retrieval, and deletion of messages in it. 150 A cache stores cacheable responses in order to reduce the response time and 152 151 network bandwidth consumption on future, equivalent requests. Any client or 153 152 server &MAY; employ a cache, though a cache cannot be used by a server that … … 160 159 <xref target="expiration.model" />, if the response can be reused without 161 160 "validation" (checking with the origin server to see if the cached response 162 remains valid for this request). A fresh cacheresponse can therefore163 reduce both latency and network transferseach time it is reused.161 remains valid for this request). A fresh response can therefore 162 reduce both latency and network overhead each time it is reused. 164 163 When a cached response is not fresh, it might still be reusable if it can 165 164 be freshened by validation (<xref target="validation.model" />) or if the 166 origin is unavailable. 167 </t> 168 </section> 165 origin is unavailable (xref target="serving.stale.responses" />). 166 </t> 169 167 170 168 <section anchor="intro.terminology" title="Terminology"> … … 227 225 <x:dfn>age</x:dfn> 228 226 <list> 229 <t>The age of a response is the time since it was sent by, or230 successfully validatedwith, the origin server.</t>227 <t>The time since a response was sent by, or successfully validated 228 with, the origin server.</t> 231 229 </list> 232 230 </t> … … 244 242 <list> 245 243 <t>The length of time between the generation of a response and its 246 expiration time .</t>244 expiration time (either explicit or heuristic).</t> 247 245 </list> 248 246 </t> … … 259 257 <x:dfn>stale</x:dfn> 260 258 <list> 261 <t>A response is stale if its age has passed its freshness lifetime 262 (either explicit or heuristic).</t> 259 <t>A response is stale if its age has passed its freshness lifetime.</t> 263 260 </list> 264 261 </t> … … 267 264 <x:dfn>validator</x:dfn> 268 265 <list> 269 <t>A protocol element (e.g., an entity-tag or a <x:ref>Last-Modified</x:ref>270 time) that is used to find out whether a stored response is an equivalent271 copy of a representation. See &weak-and-strong;.</t>266 <t>A protocol element (e.g., an entity-tag or a 267 <x:ref>Last-Modified</x:ref> time) that is used to find out whether a 268 stored response is an equivalent copy of a representation. .</t> 272 269 </list> 273 270 </t> … … 278 275 <list> 279 276 <t>A validator that is defined by the origin server such that its 280 current value will change if the representation data changes; i.e., 281 an entity-tag that is not marked as weak (&entity-tags;) or, 282 if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value 283 that is strong in the sense defined by &lastmod-comparison;.</t> 277 current value will change if the representation data changes. 278 See &weak-and-strong;</t> 284 279 </list> 285 280 </t> … … 336 331 in the cache. Although caching is an entirely &OPTIONAL; feature of HTTP, 337 332 we assume that reusing the cached response is desirable and that such 338 reuse is the default behavior when no requirement or local ly-desired333 reuse is the default behavior when no requirement or local 339 334 configuration prevents it. Therefore, HTTP cache requirements are focused 340 335 on preventing a cache from either storing a non-reusable response or 341 reusing a stored response inappropriately. 336 reusing a stored response inappropriately, rather than mandating that 337 caches always store and reuse particular responses. 342 338 </t> 343 339 <t> … … 354 350 </t> 355 351 <t> 356 The default<x:dfn>cache key</x:dfn> consists of the request method and352 The primary <x:dfn>cache key</x:dfn> consists of the request method and 357 353 target URI. However, since HTTP caches in common use today are typically 358 354 limited to caching responses to GET, many implementations simply decline 359 other methods and use only the URI as the key.355 other methods and use only the URI as the primary cache key. 360 356 </t> 361 357 <t> … … 390 386 <t>contains a max-age response cache directive (see <xref 391 387 target="cache-response-directive.max-age" />), or</t> 392 <t>contains a s-maxage response cache directive and the cache is 388 <t>contains a s-maxage response cache directive (see <xref 389 target="cache-response-directive.s-maxage" />) and the cache is 393 390 shared, or</t> 394 391 <t>contains a Cache Control Extension (see <xref … … 409 406 <t> 410 407 In this context, a cache has "understood" a request method or a response 411 status code if it recognizes it and implements a ny cache-specific412 behavior.413 </t> 414 <t> 415 Note that, in normal operation, manycaches will not store a response that408 status code if it recognizes it and implements all specified 409 caching-related behavior. 410 </t> 411 <t> 412 Note that, in normal operation, some caches will not store a response that 416 413 has neither a cache validator nor an explicit expiration time, as such 417 414 responses are not usually useful to store. However, caches are not … … 474 471 title="Constructing Responses from Caches"> 475 472 <t> 476 For a presented request, a cache &MUST-NOT; senda stored response,473 When presented with a request, a cache &MUST-NOT; reuse a stored response, 477 474 unless: 478 475 <list style="symbols"> … … 507 504 </t> 508 505 <t> 509 When a stored response is used to satisfy a request without validation, 510 a cache &MUST; send a single <x:ref>Age</x:ref> header field 511 (<xref target="header.age"/>) in the response with a value equal to the 512 stored response's current_age; see <xref target="age.calculations" />. 506 When a stored response is used to satisfy a request without validation, a 507 cache &MUST; generate an <x:ref>Age</x:ref> header field (<xref 508 target="header.age"/>), replacing any present in the response with a value 509 equal to the stored response's current_age; see <xref 510 target="age.calculations" />. 513 511 </t> 514 512 <t> … … 525 523 When more than one suitable response is stored, a cache &MUST; use the 526 524 most recent response (as determined by the <x:ref>Date</x:ref> header 527 field). It can also forward arequest with "Cache-Control: max-age=0" or525 field). It can also forward the request with "Cache-Control: max-age=0" or 528 526 "Cache-Control: no-cache" to disambiguate which response to use. 529 527 </t> 530 528 <t> 531 529 A cache that does not have a clock available &MUST-NOT; use stored 532 responses without revalidating them on every use.533 </t> 534 535 536 <section anchor="expiration.model" title="Freshness Model">530 responses without revalidating them upon every use. 531 </t> 532 533 534 <section anchor="expiration.model" title="Freshness"> 537 535 <t> 538 536 When a response is "fresh" in the cache, it can be used to satisfy … … 571 569 </figure> 572 570 <t> 573 Thefreshness_lifetime is defined in <xref574 target="calculating.freshness.lifetime" />; thecurrent_age is defined in571 freshness_lifetime is defined in <xref 572 target="calculating.freshness.lifetime" />; current_age is defined in 575 573 <xref target="age.calculations" />. 576 574 </t> … … 613 611 When there is more than one value present for a given directive (e.g., two 614 612 <x:ref>Expires</x:ref> header fields, multiple Cache-Control: max-age 615 directives), it is considered invalid. Caches are encouraged to consider 616 responses that have invalid freshness information to be stale. 613 directives), the directive's value is considered invalid. Caches are 614 encouraged to consider responses that have invalid freshness information to 615 be stale. 617 616 </t> 618 617 </section> … … 653 652 from calculating heuristic freshness for URIs with query components 654 653 (i.e., those containing '?'). In practice, this has not been widely 655 implemented. Therefore, servers are encouraged to send explicit654 implemented. Therefore, origin servers are encouraged to send explicit 656 655 directives (e.g., Cache-Control: no-cache) if they wish to preclude 657 656 caching. … … 811 810 </t> 812 811 <t> 813 If a cache receives a first-hand response (either an entire response, or a814 <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward815 to the requesting client, and the received response is no longer fresh, the816 cache can forward it to the requesting client without adding a new817 <x:ref>Warning</x:ref> (but without removing any existing Warning header818 fields). A cache shouldn't attempt to validate a response simply because819 that response became stale in transit.820 </t> 821 </section> 822 </section> 823 824 <section anchor="validation.model" title="Validation Model">812 note that if a cache receives a first-hand response (either an entire 813 response, or a <x:ref>304 (Not Modified)</x:ref> response) that it would 814 normally forward to the requesting client, and the received response is no 815 longer fresh, the cache can forward it to the requesting client without 816 adding a new <x:ref>Warning</x:ref> (but without removing any existing 817 Warning header fields). A cache shouldn't attempt to validate a response 818 simply because that response became stale in transit. 819 </t> 820 </section> 821 </section> 822 823 <section anchor="validation.model" title="Validation"> 825 824 <t> 826 825 When a cache has one or more stored responses for a requested URI, but … … 841 840 <t> 842 841 Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field 843 whose value is that of the <x:ref>ETag</x:ref> header field(s) from all 844 responses stored for the requested URI, if present. However, if any of the 845 stored responses contains only partial content, the cache shouldn't 846 include its entity-tag in the If-None-Match header field unless the request 847 is for a range that would be fully satisfied by that stored response. 842 whose value is that of the <x:ref>ETag</x:ref> header field(s) from 843 relevant responses stored for the primary cache key, if present. However, 844 if any of the stored responses contains only partial content, the cache 845 shouldn't include its entity-tag in the If-None-Match header field unless 846 the request is for a range that would be fully satisfied by that stored 847 response. 848 848 </t> 849 849 … … 889 889 <t> 890 890 If the new response contains a strong validator, then that strong 891 validator identifies the selected representation . All of the stored892 responses with the same strong validator are selected.893 If none of the stored responses contain the same strong validator,894 then the newresponse &MUST-NOT; be used to update any stored responses.891 validator identifies the selected representation for update. All of the 892 stored responses with the same strong validator are selected. If none of 893 the stored responses contain the same strong validator, then the new 894 response &MUST-NOT; be used to update any stored responses. 895 895 </t> 896 896 <t> 897 897 If the new response contains a weak validator and that validator 898 898 corresponds to one of the cache's stored responses, then the most 899 recent of those matching stored responses is selected .899 recent of those matching stored responses is selected for update. 900 900 </t> 901 901 <t> … … 904 904 source other than the Last-Modified response header field), and there is 905 905 only one stored response, and that stored response also lacks a 906 validator, then that stored response is selected .906 validator, then that stored response is selected for update. 907 907 </t> 908 908 </list> … … 1079 1079 <t> 1080 1080 Note that this does not guarantee that all appropriate responses are 1081 invalidated. For example, the request that caused the change at the origin1082 server might not have gone through the cache where a response is stored.1083 </t>1081 invalidated. For example, a state-changing request might invalidate 1082 responses in the caches it travels through, but relevant responses still 1083 might be stored in other caches that it has not.</t> 1084 1084 </section> 1085 1085 … … 1135 1135 <x:note> 1136 1136 <t> 1137 &Note; HTTP/1.0 caches might not implement Cache-Control and 1138 might only implement Pragma: no-cache (see <xref target="header.pragma" 1139 />). 1137 &Note; some HTTP/1.0 caches might not implement Cache-Control. 1140 1138 </t> 1141 1139 </x:note> … … 1235 1233 <t> 1236 1234 The "max-stale" request directive indicates that the client is willing 1237 to accept a response that has exceeded its expirationtime. If max-stale1235 to accept a response that has exceeded its freshness lifetime. If max-stale 1238 1236 is assigned a value, then the client is willing to accept a response 1239 that has exceeded its expirationtime by no more than the specified1237 that has exceeded its freshness lifetime by no more than the specified 1240 1238 number of seconds. If no value is assigned to max-stale, then the client 1241 1239 is willing to accept a stale response of any age. … … 1337 1335 </t> 1338 1336 <t> 1339 The field-names given are not limited to the set of standardheader1337 The field-names given are not limited to the set of header 1340 1338 fields defined by this specification. Field names are case-insensitive. 1341 1339 </t> … … 1383 1381 </t> 1384 1382 <t> 1385 The field-names given are not limited to the set of standardheader1383 The field-names given are not limited to the set of header 1386 1384 fields defined by this specification. Field names are case-insensitive. 1387 1385 </t> 1388 1386 <t> 1389 &Note; Many HTTP/1.0 caches will not recognize or obey1390 this directive. Also, no-cache response directives with field-names are1391 often handled by implementations as if an unqualified no-cache directive1392 was received; i.e., the special handling for the qualified form is not1393 widely implemented.1387 &Note; Although it has been back-ported to many implementations, some 1388 HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache 1389 response directives with field-names are often handled by implementations 1390 as if an unqualified no-cache directive was received; i.e., the special 1391 handling for the qualified form is not widely implemented. 1394 1392 </t> 1395 1393 <t> … … 1510 1508 <t> 1511 1509 The Cache-Control header field can be extended through the use of one or 1512 more cache-extension tokens, each with an optional value. Informational 1513 extensions (those that do not require a change in cache behavior) can be 1514 added without changing the semantics of other directives. Behavioral 1515 extensions are designed to work by acting as modifiers to the existing base 1516 of cache directives. Both the new directive and the standard directive are 1517 supplied, such that applications that do not understand the new directive 1518 will default to the behavior specified by the standard directive, and those 1519 that understand the new directive will recognize it as modifying the 1520 requirements associated with the standard directive. In this way, 1521 extensions to the cache-control directives can be made without requiring 1522 changes to the base protocol. 1510 more cache-extension tokens, each with an optional value. 1511 </t> 1512 <t> 1513 Informational extensions (those that do not require a change in cache 1514 behavior) can be added without changing the semantics of other directives. 1515 Behavioral extensions are designed to work by acting as modifiers to the 1516 existing base of cache directives. 1517 </t> 1518 <t> 1519 Both the new directive and the standard directive are supplied, such that 1520 applications that do not understand the new directive will default to the 1521 behavior specified by the standard directive, and those that understand the 1522 new directive will recognize it as modifying the requirements associated 1523 with the standard directive. In this way, extensions to the cache-control 1524 directives can be made without requiring changes to the base protocol. 1523 1525 </t> 1524 1526 <t> … … 1561 1563 argument is present,</t> 1562 1564 <t>When the directive requires an argument, what it means when it is 1563 missing.</t> 1565 missing,</t> 1566 <t>Whether the directive is specific to requests, responses, or able 1567 to be used in either.</t> 1564 1568 </list> 1565 1569 </t>
Note: See TracChangeset
for help on using the changeset viewer.