idnits 2.17.1 draft-ietf-httpbis-p6-cache-25.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2616, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2013) is 3812 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-25 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-25 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 2616 (if approved) M. Nottingham, Ed. 5 Intended status: Standards Track Akamai 6 Expires: May 21, 2014 J. Reschke, Ed. 7 greenbytes 8 November 17, 2013 10 Hypertext Transfer Protocol (HTTP/1.1): Caching 11 draft-ietf-httpbis-p6-cache-25 13 Abstract 15 The Hypertext Transfer Protocol (HTTP) is an application-level 16 protocol for distributed, collaborative, hypertext information 17 systems. This document defines requirements on HTTP caches and the 18 associated header fields that control cache behavior or indicate 19 cacheable response messages. 21 Editorial Note (To be removed by RFC Editor) 23 Discussion of this draft takes place on the HTTPBIS working group 24 mailing list (ietf-http-wg@w3.org), which is archived at 25 . 27 The current issues list is at 28 and related 29 documents (including fancy diffs) can be found at 30 . 32 The changes in this draft are summarized in Appendix D.1. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 21, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 This document may contain material from IETF Documents or IETF 66 Contributions published or made publicly available before November 67 10, 2008. The person(s) controlling the copyright in some of this 68 material may not have granted the IETF Trust the right to allow 69 modifications of such material outside the IETF Standards Process. 70 Without obtaining an adequate license from the person(s) controlling 71 the copyright in such materials, this document may not be modified 72 outside the IETF Standards Process, and derivative works of it may 73 not be created outside the IETF Standards Process, except to format 74 it for publication as an RFC or to translate it into languages other 75 than English. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 81 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 82 1.2.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 5 83 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 5 84 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 6 85 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 7 86 3.2. Storing Responses to Authenticated Requests . . . . . . . 7 87 3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8 88 4. Constructing Responses from Caches . . . . . . . . . . . . . . 8 89 4.1. Calculating Secondary Keys with Vary . . . . . . . . . . . 9 90 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 10 91 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 92 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 12 93 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 94 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 95 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15 96 4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15 97 4.3.2. Handling a Received Validation Request . . . . . . . . 16 98 4.3.3. Handling a Validation Response . . . . . . . . . . . . 17 99 4.3.4. Freshening Stored Responses upon Validation . . . . . 18 100 4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 19 101 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19 102 5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 103 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 105 5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 106 5.2.2. Response Cache-Control Directives . . . . . . . . . . 23 107 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 108 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 109 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 110 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 111 5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 31 112 5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31 113 5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31 114 5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31 115 5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31 116 5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31 117 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31 118 6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 119 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 120 7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32 121 7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32 122 7.1.2. Considerations for New Cache Control Directives . . . 32 123 7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 33 124 7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33 125 7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33 126 7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33 127 7.3. Header Field Registration . . . . . . . . . . . . . . . . 34 128 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 129 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 130 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 131 10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 132 10.2. Informative References . . . . . . . . . . . . . . . . . . 36 133 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 134 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38 135 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 136 Appendix D. Change Log (to be removed by RFC Editor before 137 publication) . . . . . . . . . . . . . . . . . . . . 39 138 D.1. Since draft-ietf-httpbis-p6-cache-24 . . . . . . . . . . . 40 139 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 141 1. Introduction 143 HTTP is typically used for distributed information systems, where 144 performance can be improved by the use of response caches. This 145 document defines aspects of HTTP/1.1 related to caching and reusing 146 response messages. 148 An HTTP cache is a local store of response messages and the subsystem 149 that controls storage, retrieval, and deletion of messages in it. A 150 cache stores cacheable responses in order to reduce the response time 151 and network bandwidth consumption on future, equivalent requests. 152 Any client or server MAY employ a cache, though a cache cannot be 153 used by a server that is acting as a tunnel. 155 A shared cache is a cache that stores responses to be reused by more 156 than one user; shared caches are usually (but not always) deployed as 157 a part of an intermediary. A private cache, in contrast, is 158 dedicated to a single user. 160 The goal of caching in HTTP/1.1 is to significantly improve 161 performance by reusing a prior response message to satisfy a current 162 request. A stored response is considered "fresh", as defined in 163 Section 4.2, if the response can be reused without "validation" 164 (checking with the origin server to see if the cached response 165 remains valid for this request). A fresh response can therefore 166 reduce both latency and network overhead each time it is reused. 167 When a cached response is not fresh, it might still be reusable if it 168 can be freshened by validation (Section 4.3) or if the origin is 169 unavailable (Section 4.2.4). 171 1.1. Conformance and Error Handling 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 Conformance criteria and considerations regarding error handling are 178 defined in Section 2.5 of [Part1]. 180 1.2. Syntax Notation 182 This specification uses the Augmented Backus-Naur Form (ABNF) 183 notation of [RFC5234] with the list rule extension defined in Section 184 7 of [Part1]. Appendix B describes rules imported from other 185 documents. Appendix C shows the collected ABNF with the list rule 186 expanded. 188 1.2.1. Delta Seconds 190 The delta-seconds rule specifies a non-negative integer, representing 191 time in seconds. 193 delta-seconds = 1*DIGIT 195 A recipient parsing a delta-seconds value and converting it to binary 196 form ought to use an arithmetic type of at least 31 bits of non- 197 negative integer range. If a cache receives a delta-seconds value 198 greater than the greatest integer it can represent, or if any of its 199 subsequent calculations overflows, the cache MUST consider the value 200 to be either 2147483648 (2^31) or the greatest positive integer it 201 can conveniently represent. 203 Note: The value 2147483648 is here for historical reasons, 204 effectively represents infinity (over 68 years), and does not need 205 to be stored in binary form; an implementation could produce it as 206 a canned string if any overflow occurs, even if the calculations 207 are performed with an arithmetic type incapable of directly 208 representing that number. What matters here is that an overflow 209 be detected and not treated as a negative value in later 210 calculations. 212 2. Overview of Cache Operation 214 Proper cache operation preserves the semantics of HTTP transfers 215 ([Part2]) while eliminating the transfer of information already held 216 in the cache. Although caching is an entirely OPTIONAL feature of 217 HTTP, we assume that reusing the cached response is desirable and 218 that such reuse is the default behavior when no requirement or local 219 configuration prevents it. Therefore, HTTP cache requirements are 220 focused on preventing a cache from either storing a non-reusable 221 response or reusing a stored response inappropriately, rather than 222 mandating that caches always store and reuse particular responses. 224 Each cache entry consists of a cache key and one or more HTTP 225 responses corresponding to prior requests that used the same key. 226 The most common form of cache entry is a successful result of a 227 retrieval request: i.e., a 200 (OK) response to a GET request, which 228 contains a representation of the resource identified by the request 229 target (Section 4.3.1 of [Part2]). However, it is also possible to 230 cache permanent redirects, negative results (e.g., 404 (Not Found)), 231 incomplete results (e.g., 206 (Partial Content)), and responses to 232 methods other than GET if the method's definition allows such caching 233 and defines something suitable for use as a cache key. 235 The primary cache key consists of the request method and target URI. 237 However, since HTTP caches in common use today are typically limited 238 to caching responses to GET, many caches simply decline other methods 239 and use only the URI as the primary cache key. 241 If a request target is subject to content negotiation, its cache 242 entry might consist of multiple stored responses, each differentiated 243 by a secondary key for the values of the original request's selecting 244 header fields (Section 4.1). 246 3. Storing Responses in Caches 248 A cache MUST NOT store a response to any request, unless: 250 o The request method is understood by the cache and defined as being 251 cacheable, and 253 o the response status code is understood by the cache, and 255 o the "no-store" cache directive (see Section 5.2) does not appear 256 in request or response header fields, and 258 o the "private" cache response directive (see Section 5.2.2.6) does 259 not appear in the response, if the cache is shared, and 261 o the Authorization header field (see Section 4.1 of [Part7]) does 262 not appear in the request, if the cache is shared, unless the 263 response explicitly allows it (see Section 3.2), and 265 o the response either: 267 * contains an Expires header field (see Section 5.3), or 269 * contains a max-age response cache directive (see 270 Section 5.2.2.8), or 272 * contains a s-maxage response cache directive (see 273 Section 5.2.2.9) and the cache is shared, or 275 * contains a Cache Control Extension (see Section 5.2.3) that 276 allows it to be cached, or 278 * has a status code that is defined as cacheable by default (see 279 Section 4.2.2), or 281 * contains a public response cache directive (see 282 Section 5.2.2.5). 284 Note that any of the requirements listed above can be overridden by a 285 cache-control extension; see Section 5.2.3. 287 In this context, a cache has "understood" a request method or a 288 response status code if it recognizes it and implements all specified 289 caching-related behavior. 291 Note that, in normal operation, some caches will not store a response 292 that has neither a cache validator nor an explicit expiration time, 293 as such responses are not usually useful to store. However, caches 294 are not prohibited from storing such responses. 296 3.1. Storing Incomplete Responses 298 A response message is considered complete when all of the octets 299 indicated by the message framing ([Part1]) are received prior to the 300 connection being closed. If the request method is GET, the response 301 status code is 200 (OK), and the entire response header section has 302 been received, a cache MAY store an incomplete response message body 303 if the cache entry is recorded as incomplete. Likewise, a 206 304 (Partial Content) response MAY be stored as if it were an incomplete 305 200 (OK) cache entry. However, a cache MUST NOT store incomplete or 306 partial content responses if it does not support the Range and 307 Content-Range header fields or if it does not understand the range 308 units used in those fields. 310 A cache MAY complete a stored incomplete response by making a 311 subsequent range request ([Part5]) and combining the successful 312 response with the stored entry, as defined in Section 3.3. A cache 313 MUST NOT use an incomplete response to answer requests unless the 314 response has been made complete or the request is partial and 315 specifies a range that is wholly within the incomplete response. A 316 cache MUST NOT send a partial response to a client without explicitly 317 marking it as such using the 206 (Partial Content) status code. 319 3.2. Storing Responses to Authenticated Requests 321 A shared cache MUST NOT use a cached response to a request with an 322 Authorization header field (Section 4.1 of [Part7]) to satisfy any 323 subsequent request unless a cache directive that allows such 324 responses to be stored is present in the response. 326 In this specification, the following Cache-Control response 327 directives (Section 5.2.2) have such an effect: must-revalidate, 328 public, s-maxage. 330 Note that cached responses that contain the "must-revalidate" and/or 331 "s-maxage" response directives are not allowed to be served stale 332 (Section 4.2.4) by shared caches. In particular, a response with 333 either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to 334 satisfy a subsequent request without revalidating it on the origin 335 server. 337 3.3. Combining Partial Content 339 A response might transfer only a partial representation if the 340 connection closed prematurely or if the request used one or more 341 Range specifiers ([Part5]). After several such transfers, a cache 342 might have received several ranges of the same representation. A 343 cache MAY combine these ranges into a single stored response, and 344 reuse that response to satisfy later requests, if they all share the 345 same strong validator and the cache complies with the client 346 requirements in Section 4.3 of [Part5]. 348 When combining the new response with one or more stored responses, a 349 cache MUST: 351 o delete any Warning header fields in the stored response with warn- 352 code 1xx (see Section 5.5); 354 o retain any Warning header fields in the stored response with warn- 355 code 2xx; and, 357 o use other header fields provided in the new response, aside from 358 Content-Range, to replace all instances of the corresponding 359 header fields in the stored response. 361 4. Constructing Responses from Caches 363 When presented with a request, a cache MUST NOT reuse a stored 364 response, unless: 366 o The presented effective request URI (Section 5.5 of [Part1]) and 367 that of the stored response match, and 369 o the request method associated with the stored response allows it 370 to be used for the presented request, and 372 o selecting header fields nominated by the stored response (if any) 373 match those presented (see Section 4.1), and 375 o the presented request does not contain the no-cache pragma 376 (Section 5.4), nor the no-cache cache directive (Section 5.2.1), 377 unless the stored response is successfully validated 378 (Section 4.3), and 380 o the stored response does not contain the no-cache cache directive 381 (Section 5.2.2.2), unless it is successfully validated 382 (Section 4.3), and 384 o the stored response is either: 386 * fresh (see Section 4.2), or 388 * allowed to be served stale (see Section 4.2.4), or 390 * successfully validated (see Section 4.3). 392 Note that any of the requirements listed above can be overridden by a 393 cache-control extension; see Section 5.2.3. 395 When a stored response is used to satisfy a request without 396 validation, a cache MUST generate an Age header field (Section 5.1), 397 replacing any present in the response with a value equal to the 398 stored response's current_age; see Section 4.2.3. 400 A cache MUST write through requests with methods that are unsafe 401 (Section 4.2.1 of [Part2]) to the origin server; i.e., a cache is not 402 allowed to generate a reply to such a request before having forwarded 403 the request and having received a corresponding response. 405 Also, note that unsafe requests might invalidate already stored 406 responses; see Section 4.4. 408 When more than one suitable response is stored, a cache MUST use the 409 most recent response (as determined by the Date header field). It 410 can also forward the request with "Cache-Control: max-age=0" or 411 "Cache-Control: no-cache" to disambiguate which response to use. 413 A cache that does not have a clock available MUST NOT use stored 414 responses without revalidating them upon every use. 416 4.1. Calculating Secondary Keys with Vary 418 When a cache receives a request that can be satisfied by a stored 419 response that has a Vary header field (Section 7.1.4 of [Part2]), it 420 MUST NOT use that response unless all of the selecting header fields 421 nominated by the Vary header field match in both the original request 422 (i.e., that associated with the stored response), and the presented 423 request. 425 The selecting header fields from two requests are defined to match if 426 and only if those in the first request can be transformed to those in 427 the second request by applying any of the following: 429 o adding or removing whitespace, where allowed in the header field's 430 syntax 432 o combining multiple header fields with the same field name (see 433 Section 3.2 of [Part1]) 435 o normalizing both header field values in a way that is known to 436 have identical semantics, according to the header field's 437 specification (e.g., re-ordering field values when order is not 438 significant; case-normalization, where values are defined to be 439 case-insensitive) 441 If (after any normalization that might take place) a header field is 442 absent from a request, it can only match another request if it is 443 also absent there. 445 A Vary header field-value of "*" always fails to match. 447 The stored response with matching selecting header fields is known as 448 the selected response. 450 If multiple selected responses are available (potentially including 451 responses without a Vary header field), the cache will need to choose 452 one to use. When a selecting header field has a known mechanism for 453 doing so (e.g., qvalues on Accept and similar request header fields), 454 that mechanism MAY be used to select preferred responses; of the 455 remainder, the most recent response (as determined by the Date header 456 field) is used, as per Section 4. 458 If no selected response is available, the cache cannot satisfy the 459 presented request. Typically, it is forwarded to the origin server 460 in a (possibly conditional; see Section 4.3) request. 462 4.2. Freshness 464 A fresh response is one whose age has not yet exceeded its freshness 465 lifetime. Conversely, a stale response is one where it has. 467 A response's freshness lifetime is the length of time between its 468 generation by the origin server and its expiration time. An explicit 469 expiration time is the time at which the origin server intends that a 470 stored response can no longer be used by a cache without further 471 validation, whereas a heuristic expiration time is assigned by a 472 cache when no explicit expiration time is available. 474 A response's age is the time that has passed since it was generated 475 by, or successfully validated with, the origin server. 477 When a response is "fresh" in the cache, it can be used to satisfy 478 subsequent requests without contacting the origin server, thereby 479 improving efficiency. 481 The primary mechanism for determining freshness is for an origin 482 server to provide an explicit expiration time in the future, using 483 either the Expires header field (Section 5.3) or the max-age response 484 cache directive (Section 5.2.2.8). Generally, origin servers will 485 assign future explicit expiration times to responses in the belief 486 that the representation is not likely to change in a semantically 487 significant way before the expiration time is reached. 489 If an origin server wishes to force a cache to validate every 490 request, it can assign an explicit expiration time in the past to 491 indicate that the response is already stale. Compliant caches will 492 normally validate a stale cached response before reusing it for 493 subsequent requests (see Section 4.2.4). 495 Since origin servers do not always provide explicit expiration times, 496 caches are also allowed to use a heuristic to determine an expiration 497 time under certain circumstances (see Section 4.2.2). 499 The calculation to determine if a response is fresh is: 501 response_is_fresh = (freshness_lifetime > current_age) 503 freshness_lifetime is defined in Section 4.2.1; current_age is 504 defined in Section 4.2.3. 506 Clients can send the max-age or min-fresh cache directives in a 507 request to constrain or relax freshness calculations for the 508 corresponding response (Section 5.2.1). 510 When calculating freshness, to avoid common problems in date parsing: 512 o Although all date formats are specified to be case-sensitive, a 513 cache recipient SHOULD match day, week, and timezone names case- 514 insensitively. 516 o If a cache recipient's internal implementation of time has less 517 resolution than the value of an HTTP-date, the recipient MUST 518 internally represent a parsed Expires date as the nearest time 519 equal to or earlier than the received value. 521 o A cache recipient MUST NOT allow local time zones to influence the 522 calculation or comparison of an age or expiration time. 524 o A cache recipient SHOULD consider a date with a zone abbreviation 525 other than GMT or UTC to be invalid for calculating expiration. 527 Note that freshness applies only to cache operation; it cannot be 528 used to force a user agent to refresh its display or reload a 529 resource. See Section 6 for an explanation of the difference between 530 caches and history mechanisms. 532 4.2.1. Calculating Freshness Lifetime 534 A cache can calculate the freshness lifetime (denoted as 535 freshness_lifetime) of a response by using the first match of: 537 o If the cache is shared and the s-maxage response cache directive 538 (Section 5.2.2.9) is present, use its value, or 540 o If the max-age response cache directive (Section 5.2.2.8) is 541 present, use its value, or 543 o If the Expires response header field (Section 5.3) is present, use 544 its value minus the value of the Date response header field, or 546 o Otherwise, no explicit expiration time is present in the response. 547 A heuristic freshness lifetime might be applicable; see 548 Section 4.2.2. 550 Note that this calculation is not vulnerable to clock skew, since all 551 of the information comes from the origin server. 553 When there is more than one value present for a given directive 554 (e.g., two Expires header fields, multiple Cache-Control: max-age 555 directives), the directive's value is considered invalid. Caches are 556 encouraged to consider responses that have invalid freshness 557 information to be stale. 559 4.2.2. Calculating Heuristic Freshness 561 Since origin servers do not always provide explicit expiration times, 562 a cache MAY assign a heuristic expiration time when an explicit time 563 is not specified, employing algorithms that use other header field 564 values (such as the Last-Modified time) to estimate a plausible 565 expiration time. This specification does not provide specific 566 algorithms, but does impose worst-case constraints on their results. 568 A cache MUST NOT use heuristics to determine freshness when an 569 explicit expiration time is present in the stored response. Because 570 of the requirements in Section 3, this means that, effectively, 571 heuristics can only be used on responses without explicit freshness 572 whose status codes are defined as cacheable by default (see Section 573 6.1 of [Part2]), and those responses without explicit freshness that 574 have been marked as explicitly cacheable (e.g., with a "public" 575 response cache directive). 577 If the response has a Last-Modified header field (Section 2.2 of 578 [Part4]), caches are encouraged to use a heuristic expiration value 579 that is no more than some fraction of the interval since that time. 580 A typical setting of this fraction might be 10%. 582 When a heuristic is used to calculate freshness lifetime, a cache 583 SHOULD generate a Warning header field with a 113 warn-code (see 584 Section 5.5.4) in the response if its current_age is more than 24 585 hours and such a warning is not already present. 587 Note: Section 13.9 of [RFC2616] prohibited caches from calculating 588 heuristic freshness for URIs with query components (i.e., those 589 containing '?'). In practice, this has not been widely 590 implemented. Therefore, origin servers are encouraged to send 591 explicit directives (e.g., Cache-Control: no-cache) if they wish 592 to preclude caching. 594 4.2.3. Calculating Age 596 The Age header field is used to convey an estimated age of the 597 response message when obtained from a cache. The Age field value is 598 the cache's estimate of the number of seconds since the response was 599 generated or validated by the origin server. In essence, the Age 600 value is the sum of the time that the response has been resident in 601 each of the caches along the path from the origin server, plus the 602 amount of time it has been in transit along network paths. 604 The following data is used for the age calculation: 606 age_value 608 The term "age_value" denotes the value of the Age header field 609 (Section 5.1), in a form appropriate for arithmetic operation; or 610 0, if not available. 612 date_value 614 The term "date_value" denotes the value of the Date header field, 615 in a form appropriate for arithmetic operations. See Section 616 7.1.1.2 of [Part2] for the definition of the Date header field, 617 and for requirements regarding responses without it. 619 now 621 The term "now" means "the current value of the clock at the host 622 performing the calculation". A host ought to use NTP ([RFC5905]) 623 or some similar protocol to synchronize its clocks to Coordinated 624 Universal Time. 626 request_time 628 The current value of the clock at the host at the time the request 629 resulting in the stored response was made. 631 response_time 633 The current value of the clock at the host at the time the 634 response was received. 636 A response's age can be calculated in two entirely independent ways: 638 1. the "apparent_age": response_time minus date_value, if the local 639 clock is reasonably well synchronized to the origin server's 640 clock. If the result is negative, the result is replaced by 641 zero. 643 2. the "corrected_age_value", if all of the caches along the 644 response path implement HTTP/1.1. A cache MUST interpret this 645 value relative to the time the request was initiated, not the 646 time that the response was received. 648 apparent_age = max(0, response_time - date_value); 650 response_delay = response_time - request_time; 651 corrected_age_value = age_value + response_delay; 653 These are combined as 655 corrected_initial_age = max(apparent_age, corrected_age_value); 657 unless the cache is confident in the value of the Age header field 658 (e.g., because there are no HTTP/1.0 hops in the Via header field), 659 in which case the corrected_age_value MAY be used as the 660 corrected_initial_age. 662 The current_age of a stored response can then be calculated by adding 663 the amount of time (in seconds) since the stored response was last 664 validated by the origin server to the corrected_initial_age. 666 resident_time = now - response_time; 667 current_age = corrected_initial_age + resident_time; 669 4.2.4. Serving Stale Responses 671 A "stale" response is one that either has explicit expiry information 672 or is allowed to have heuristic expiry calculated, but is not fresh 673 according to the calculations in Section 4.2. 675 A cache MUST NOT generate a stale response if it is prohibited by an 676 explicit in-protocol directive (e.g., by a "no-store" or "no-cache" 677 cache directive, a "must-revalidate" cache-response-directive, or an 678 applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 679 see Section 5.2.2). 681 A cache MUST NOT send stale responses unless it is disconnected 682 (i.e., it cannot contact the origin server or otherwise find a 683 forward path) or doing so is explicitly allowed (e.g., by the max- 684 stale request directive; see Section 5.2.1). 686 A cache SHOULD generate a Warning header field with the 110 warn-code 687 (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD 688 generate a 112 warn-code (see Section 5.5.3) in stale responses if 689 the cache is disconnected. 691 A cache SHOULD NOT generate a new Warning header field when 692 forwarding a response that does not have an Age header field, even if 693 the response is already stale. A cache need not validate a response 694 that merely became stale in transit. 696 4.3. Validation 698 When a cache has one or more stored responses for a requested URI, 699 but cannot serve any of them (e.g., because they are not fresh, or 700 one cannot be selected; see Section 4.1), it can use the conditional 701 request mechanism [Part4] in the forwarded request to give the next 702 inbound server an opportunity to select a valid stored response to 703 use, updating the stored metadata in the process, or to replace the 704 stored response(s) with a new response. This process is known as 705 "validating" or "revalidating" the stored response. 707 4.3.1. Sending a Validation Request 709 When sending a conditional request for cache validation, a cache 710 sends one or more precondition header fields containing validator 711 metadata from its stored response(s), which is then compared by 712 recipients to determine whether a stored response is equivalent to a 713 current representation of the resource. 715 One such validator is the timestamp given in a Last-Modified header 716 field (Section 2.2 of [Part4]), which can be used in an If-Modified- 717 Since header field for response validation, or in an If-Unmodified- 718 Since or If-Range header field for representation selection (i.e., 719 the client is referring specifically to a previously obtained 720 representation with that timestamp). 722 Another validator is the entity-tag given in an ETag header field 723 (Section 2.3 of [Part4]). One or more entity-tags, indicating one or 724 more stored responses, can be used in an If-None-Match header field 725 for response validation, or in an If-Match or If-Range header field 726 for representation selection (i.e., the client is referring 727 specifically to one or more previously obtained representations with 728 the listed entity-tags). 730 4.3.2. Handling a Received Validation Request 732 Each client in the request chain may have its own cache, so it is 733 common for a cache at an intermediary to receive conditional requests 734 from other (outbound) caches. Likewise, some user agents make use of 735 conditional requests to limit data transfers to recently modified 736 representations or to complete the transfer of a partially retrieved 737 representation. 739 If a cache receives a request that can be satisfied by reusing one of 740 its stored 200 (OK) or 206 (Partial Content) responses, the cache 741 SHOULD evaluate any applicable conditional header field preconditions 742 received in that request with respect to the corresponding validators 743 contained within the selected response. A cache MUST NOT evaluate 744 conditional header fields that are only applicable to an origin 745 server, found in a request with semantics that cannot be satisfied 746 with a cached response, or applied to a target resource for which it 747 has no stored responses; such preconditions are likely intended for 748 some other (inbound) server. 750 The proper evaluation of conditional requests by a cache depends on 751 the received precondition header fields and their precedence, as 752 defined in Section 6 of [Part4]. The If-Match and If-Unmodified- 753 Since conditional header fields are not applicable to a cache. 755 A request containing an If-None-Match header field (Section 3.2 of 756 [Part4]) indicates that the client wants to validate one or more of 757 its own stored responses in comparison to whichever stored response 758 is selected by the cache. If the field-value is "*", or if the 759 field-value is a list of entity-tags and at least one of them match 760 the entity-tag of the selected stored response, a cache recipient 761 SHOULD generate a 304 (Not Modified) response (using the metadata of 762 the selected stored response) instead of sending that stored 763 response. 765 When a cache decides to revalidate its own stored responses for a 766 request that contains an If-None-Match list of entity-tags, the cache 767 MAY combine the received list with a list of entity-tags from its own 768 stored set of responses (fresh or stale) and send the union of the 769 two lists as a replacement If-None-Match header field value in the 770 forwarded request. If a stored response contains only partial 771 content, the cache MUST NOT include its entity-tag in the union 772 unless the request is for a range that would be fully satisfied by 773 that partial stored response. If the response to the forwarded 774 request is 304 (Not Modified) and has an ETag header field value with 775 an entity-tag that is not in the client's list, the cache MUST 776 generate a 200 (OK) response for the client by reusing its 777 corresponding stored response, as updated by the 304 response 778 metadata (Section 4.3.4). 780 If an If-None-Match header field is not present, a request containing 781 an If-Modified-Since header field (Section 3.3 of [Part4]) indicates 782 that the client wants to validate one or more of its own stored 783 responses by modification date. A cache recipient SHOULD generate a 784 304 (Not Modified) response (using the metadata of the selected 785 stored response) if one of the following cases is true: 1) the 786 selected stored response has a Last-Modified field-value that is 787 earlier than or equal to the conditional timestamp; 2) no Last- 788 Modified field is present in the selected stored response, but it has 789 a Date field-value that is earlier than or equal to the conditional 790 timestamp; or, 3) neither Last-Modified nor Date is present in the 791 selected stored response, but the cache recorded it as having been 792 received at a time earlier than or equal to the conditional 793 timestamp. 795 A cache that implements partial responses to range requests, as 796 defined in [Part5], also needs to evaluate a received If-Range header 797 field (Section 3.2 of [Part5]) with respect to its selected stored 798 response. 800 4.3.3. Handling a Validation Response 802 Cache handling of a response to a conditional request is dependent 803 upon its status code: 805 o A 304 (Not Modified) response status code indicates that the 806 stored response can be updated and reused; see Section 4.3.4. 808 o A full response (i.e., one with a payload body) indicates that 809 none of the stored responses nominated in the conditional request 810 is suitable. Instead, the cache MUST use the full response to 811 satisfy the request and MAY replace the stored response(s). 813 o However, if a cache receives a 5xx (Server Error) response while 814 attempting to validate a response, it can either forward this 815 response to the requesting client, or act as if the server failed 816 to respond. In the latter case, the cache MAY send a previously 817 stored response (see Section 4.2.4). 819 4.3.4. Freshening Stored Responses upon Validation 821 When a cache receives a 304 (Not Modified) response and already has 822 one or more stored 200 (OK) responses for the same cache key, the 823 cache needs to identify which of the stored responses are updated by 824 this new response and then update the stored response(s) with the new 825 information provided in the 304 response. 827 The stored response to update is identified by using the first match 828 (if any) of: 830 o If the new response contains a strong validator (see Section 2.1 831 of [Part4]), then that strong validator identifies the selected 832 representation for update. All of the stored responses with the 833 same strong validator are selected. If none of the stored 834 responses contain the same strong validator, then the cache MUST 835 NOT use the new response to update any stored responses. 837 o If the new response contains a weak validator and that validator 838 corresponds to one of the cache's stored responses, then the most 839 recent of those matching stored responses is selected for update. 841 o If the new response does not include any form of validator (such 842 as in the case where a client generates an If-Modified-Since 843 request from a source other than the Last-Modified response header 844 field), and there is only one stored response, and that stored 845 response also lacks a validator, then that stored response is 846 selected for update. 848 If a stored response is selected for update, the cache MUST: 850 o delete any Warning header fields in the stored response with warn- 851 code 1xx (see Section 5.5); 853 o retain any Warning header fields in the stored response with warn- 854 code 2xx; and, 856 o use other header fields provided in the 304 (Not Modified) 857 response to replace all instances of the corresponding header 858 fields in the stored response. 860 4.3.5. Freshening Responses via HEAD 862 A response to the HEAD method is identical to what an equivalent 863 request made with a GET would have been, except it lacks a body. 864 This property of HEAD responses can be used to invalidate or update a 865 cached GET response if the more efficient conditional GET request 866 mechanism is not available (due to no validators being present in the 867 stored response) or if transmission of the representation body is not 868 desired even if it has changed. 870 When a cache makes an inbound HEAD request for a given request target 871 and receives a 200 (OK) response, the cache SHOULD update or 872 invalidate each of its stored GET responses that could have been 873 selected for that request (see Section 4.1). 875 For each of the stored responses that could have been selected, if 876 the stored response and HEAD response have matching values for any 877 received validator fields (ETag and Last-Modified) and, if the HEAD 878 response has a Content-Length header field, the value of Content- 879 Length matches that of the stored response, the cache SHOULD update 880 the stored response a described below; otherwise, the cache SHOULD 881 consider the stored response to be stale. 883 If a cache updates a stored response with the metadata provided in a 884 HEAD response, the cache MUST: 886 o delete any Warning header fields in the stored response with warn- 887 code 1xx (see Section 5.5); 889 o retain any Warning header fields in the stored response with warn- 890 code 2xx; and, 892 o use other header fields provided in the HEAD response to replace 893 all instances of the corresponding header fields in the stored 894 response and append new header fields to the stored response's 895 header section unless otherwise restricted by the Cache-Control 896 header field. 898 4.4. Invalidation 900 Because unsafe request methods (Section 4.2.1 of [Part2]) such as 901 PUT, POST or DELETE have the potential for changing state on the 902 origin server, intervening caches can use them to keep their contents 903 up-to-date. 905 A cache MUST invalidate the effective Request URI (Section 5.5 of 906 [Part1]) as well as the URI(s) in the Location and Content-Location 907 response header fields (if present) when a non-error status code is 908 received in response to an unsafe request method. 910 However, a cache MUST NOT invalidate a URI from a Location or 911 Content-Location response header field if the host part of that URI 912 differs from the host part in the effective request URI (Section 5.5 913 of [Part1]). This helps prevent denial of service attacks. 915 A cache MUST invalidate the effective request URI (Section 5.5 of 916 [Part1]) when it receives a non-error response to a request with a 917 method whose safety is unknown. 919 Here, a "non-error response" is one with a 2xx (Successful) or 3xx 920 (Redirection) status code. "Invalidate" means that the cache will 921 either remove all stored responses related to the effective request 922 URI, or will mark these as "invalid" and in need of a mandatory 923 validation before they can be sent in response to a subsequent 924 request. 926 Note that this does not guarantee that all appropriate responses are 927 invalidated. For example, a state-changing request might invalidate 928 responses in the caches it travels through, but relevant responses 929 still might be stored in other caches that it has not. 931 5. Header Field Definitions 933 This section defines the syntax and semantics of HTTP/1.1 header 934 fields related to caching. 936 5.1. Age 938 The "Age" header field conveys the sender's estimate of the amount of 939 time since the response was generated or successfully validated at 940 the origin server. Age values are calculated as specified in 941 Section 4.2.3. 943 Age = delta-seconds 945 The Age field-value is a non-negative integer, representing time in 946 seconds (see Section 1.2.1). 948 The presence of an Age header field implies that the response was not 949 generated or validated by the origin server for this request. 950 However, lack of an Age header field does not imply the origin was 951 contacted, since the response might have been received from an 952 HTTP/1.0 cache that does not implement Age. 954 5.2. Cache-Control 956 The "Cache-Control" header field is used to specify directives for 957 caches along the request/response chain. Such cache directives are 958 unidirectional in that the presence of a directive in a request does 959 not imply that the same directive is to be given in the response. 961 A cache MUST obey the requirements of the Cache-Control directives 962 defined in this section. See Section 5.2.3 for information about how 963 Cache-Control directives defined elsewhere are handled. 965 Note: Some HTTP/1.0 caches might not implement Cache-Control. 967 A proxy, whether or not it implements a cache, MUST pass cache 968 directives through in forwarded messages, regardless of their 969 significance to that application, since the directives might be 970 applicable to all recipients along the request/response chain. It is 971 not possible to target a directive to a specific cache. 973 Cache directives are identified by a token, to be compared case- 974 insensitively, and have an optional argument, that can use both token 975 and quoted-string syntax. For the directives defined below that 976 define arguments, recipients ought to accept both forms, even if one 977 is documented to be preferred. For any directive not defined by this 978 specification, a recipient MUST accept both forms. 980 Cache-Control = 1#cache-directive 982 cache-directive = token [ "=" ( token / quoted-string ) ] 984 For the cache directives defined below, no argument is defined (nor 985 allowed) unless stated otherwise. 987 5.2.1. Request Cache-Control Directives 989 5.2.1.1. max-age 991 Argument syntax: 993 delta-seconds (see Section 1.2.1) 995 The "max-age" request directive indicates that the client is 996 unwilling to accept a response whose age is greater than the 997 specified number of seconds. Unless the max-stale request directive 998 is also present, the client is not willing to accept a stale 999 response. 1001 This directive uses the token form of the argument syntax; e.g., 1002 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate the 1003 quoted-string form. 1005 5.2.1.2. max-stale 1007 Argument syntax: 1009 delta-seconds (see Section 1.2.1) 1011 The "max-stale" request directive indicates that the client is 1012 willing to accept a response that has exceeded its freshness 1013 lifetime. If max-stale is assigned a value, then the client is 1014 willing to accept a response that has exceeded its freshness lifetime 1015 by no more than the specified number of seconds. If no value is 1016 assigned to max-stale, then the client is willing to accept a stale 1017 response of any age. 1019 This directive uses the token form of the argument syntax; e.g., 1020 'max-stale=10', not 'max-stale="10"'. A sender SHOULD NOT generate 1021 the quoted-string form. 1023 5.2.1.3. min-fresh 1025 Argument syntax: 1027 delta-seconds (see Section 1.2.1) 1029 The "min-fresh" request directive indicates that the client is 1030 willing to accept a response whose freshness lifetime is no less than 1031 its current age plus the specified time in seconds. That is, the 1032 client wants a response that will still be fresh for at least the 1033 specified number of seconds. 1035 This directive uses the token form of the argument syntax; e.g., 1036 'min-fresh=20', not 'min-fresh="20"'. A sender SHOULD NOT generate 1037 the quoted-string form. 1039 5.2.1.4. no-cache 1041 The "no-cache" request directive indicates that a cache MUST NOT use 1042 a stored response to satisfy the request without successful 1043 validation on the origin server. 1045 5.2.1.5. no-store 1047 The "no-store" request directive indicates that a cache MUST NOT 1048 store any part of either this request or any response to it. This 1049 directive applies to both private and shared caches. "MUST NOT 1050 store" in this context means that the cache MUST NOT intentionally 1051 store the information in non-volatile storage, and MUST make a best- 1052 effort attempt to remove the information from volatile storage as 1053 promptly as possible after forwarding it. 1055 This directive is NOT a reliable or sufficient mechanism for ensuring 1056 privacy. In particular, malicious or compromised caches might not 1057 recognize or obey this directive, and communications networks might 1058 be vulnerable to eavesdropping. 1060 Note that if a request containing this directive is satisfied from a 1061 cache, the no-store request directive does not apply to the already 1062 stored response. 1064 5.2.1.6. no-transform 1066 The "no-transform" request directive indicates that an intermediary 1067 (whether or not it implements a cache) MUST NOT transform the 1068 payload, as defined in Section 5.7.2 of [Part1]. 1070 5.2.1.7. only-if-cached 1072 The "only-if-cached" request directive indicates that the client only 1073 wishes to obtain a stored response. If it receives this directive, a 1074 cache SHOULD either respond using a stored response that is 1075 consistent with the other constraints of the request, or respond with 1076 a 504 (Gateway Timeout) status code. If a group of caches is being 1077 operated as a unified system with good internal connectivity, a 1078 member cache MAY forward such a request within that group of caches. 1080 5.2.2. Response Cache-Control Directives 1082 5.2.2.1. must-revalidate 1084 The "must-revalidate" response directive indicates that once it has 1085 become stale, a cache MUST NOT use the response to satisfy subsequent 1086 requests without successful validation on the origin server. 1088 The must-revalidate directive is necessary to support reliable 1089 operation for certain protocol features. In all circumstances a 1090 cache MUST obey the must-revalidate directive; in particular, if a 1091 cache cannot reach the origin server for any reason, it MUST generate 1092 a 504 (Gateway Timeout) response. 1094 The must-revalidate directive ought to be used by servers if and only 1095 if failure to validate a request on the representation could result 1096 in incorrect operation, such as a silently unexecuted financial 1097 transaction. 1099 5.2.2.2. no-cache 1101 Argument syntax: 1103 #field-name 1105 The "no-cache" response directive indicates that the response MUST 1106 NOT be used to satisfy a subsequent request without successful 1107 validation on the origin server. This allows an origin server to 1108 prevent a cache from using it to satisfy a request without contacting 1109 it, even by caches that have been configured to send stale responses. 1111 If the no-cache response directive specifies one or more field-names, 1112 then a cache MAY use the response to satisfy a subsequent request, 1113 subject to any other restrictions on caching. However, any header 1114 fields in the response that have the field-name(s) listed MUST NOT be 1115 sent in the response to a subsequent request without successful 1116 revalidation with the origin server. This allows an origin server to 1117 prevent the re-use of certain header fields in a response, while 1118 still allowing caching of the rest of the response. 1120 The field-names given are not limited to the set of header fields 1121 defined by this specification. Field names are case-insensitive. 1123 This directive uses the quoted-string form of the argument syntax. A 1124 sender SHOULD NOT generate the token form (even if quoting appears 1125 not to be needed for single-entry lists). 1127 Note: Although it has been back-ported to many implementations, some 1128 HTTP/1.0 caches will not recognize or obey this directive. Also, no- 1129 cache response directives with field-names are often handled by 1130 caches as if an unqualified no-cache directive was received; i.e., 1131 the special handling for the qualified form is not widely 1132 implemented. 1134 5.2.2.3. no-store 1136 The "no-store" response directive indicates that a cache MUST NOT 1137 store any part of either the immediate request or response. This 1138 directive applies to both private and shared caches. "MUST NOT 1139 store" in this context means that the cache MUST NOT intentionally 1140 store the information in non-volatile storage, and MUST make a best- 1141 effort attempt to remove the information from volatile storage as 1142 promptly as possible after forwarding it. 1144 This directive is NOT a reliable or sufficient mechanism for ensuring 1145 privacy. In particular, malicious or compromised caches might not 1146 recognize or obey this directive, and communications networks might 1147 be vulnerable to eavesdropping. 1149 5.2.2.4. no-transform 1151 The "no-transform" response directive indicates that an intermediary 1152 (regardless of whether it implements a cache) MUST NOT transform the 1153 payload, as defined in Section 5.7.2 of [Part1]. 1155 5.2.2.5. public 1157 The "public" response directive indicates that any cache MAY store 1158 the response, even if the response would normally be non-cacheable or 1159 cacheable only within a private cache. (See Section 3.2 for 1160 additional details related to the use of public in response to a 1161 request containing Authorization, and Section 3 for details of how 1162 public affects responses that would normally not be stored, due to 1163 their status codes not being defined as cacheable by default; see 1164 Section 4.2.2.) 1166 5.2.2.6. private 1168 Argument syntax: 1170 #field-name 1172 The "private" response directive indicates that the response message 1173 is intended for a single user and MUST NOT be stored by a shared 1174 cache. A private cache MAY store the response and reuse it for later 1175 requests, even if the response would normally be non-cacheable. 1177 If the private response directive specifies one or more field-names, 1178 this requirement is limited to the field-values associated with the 1179 listed response header fields. That is, a shared cache MUST NOT 1180 store the specified field-names(s), whereas it MAY store the 1181 remainder of the response message. 1183 The field-names given are not limited to the set of header fields 1184 defined by this specification. Field names are case-insensitive. 1186 This directive uses the quoted-string form of the argument syntax. A 1187 sender SHOULD NOT generate the token form (even if quoting appears 1188 not to be needed for single-entry lists). 1190 Note: This usage of the word "private" only controls where the 1191 response can be stored; it cannot ensure the privacy of the message 1192 content. Also, private response directives with field-names are 1193 often handled by caches as if an unqualified private directive was 1194 received; i.e., the special handling for the qualified form is not 1195 widely implemented. 1197 5.2.2.7. proxy-revalidate 1199 The "proxy-revalidate" response directive has the same meaning as the 1200 must-revalidate response directive, except that it does not apply to 1201 private caches. 1203 5.2.2.8. max-age 1205 Argument syntax: 1207 delta-seconds (see Section 1.2.1) 1209 The "max-age" response directive indicates that the response is to be 1210 considered stale after its age is greater than the specified number 1211 of seconds. 1213 This directive uses the token form of the argument syntax; e.g., 1214 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate the 1215 quoted-string form. 1217 5.2.2.9. s-maxage 1219 Argument syntax: 1221 delta-seconds (see Section 1.2.1) 1223 The "s-maxage" response directive indicates that, in shared caches, 1224 the maximum age specified by this directive overrides the maximum age 1225 specified by either the max-age directive or the Expires header 1226 field. The s-maxage directive also implies the semantics of the 1227 proxy-revalidate response directive. 1229 This directive uses the token form of the argument syntax; e.g., 1230 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT generate the 1231 quoted-string form. 1233 5.2.3. Cache Control Extensions 1235 The Cache-Control header field can be extended through the use of one 1236 or more cache-extension tokens, each with an optional value. 1238 Informational extensions (those that do not require a change in cache 1239 behavior) can be added without changing the semantics of other 1240 directives. Behavioral extensions are designed to work by acting as 1241 modifiers to the existing base of cache directives. 1243 Both the new directive and the standard directive are supplied, such 1244 that applications that do not understand the new directive will 1245 default to the behavior specified by the standard directive, and 1246 those that understand the new directive will recognize it as 1247 modifying the requirements associated with the standard directive. 1248 In this way, extensions to the cache-control directives can be made 1249 without requiring changes to the base protocol. 1251 This extension mechanism depends on an HTTP cache obeying all of the 1252 cache-control directives defined for its native HTTP-version, obeying 1253 certain extensions, and ignoring all directives that it does not 1254 understand. 1256 For example, consider a hypothetical new response directive called 1257 "community" that acts as a modifier to the private directive. We 1258 define this new directive to mean that, in addition to any private 1259 cache, any cache that is shared only by members of the community 1260 named within its value is allowed to cache the response. An origin 1261 server wishing to allow the UCI community to use an otherwise private 1262 response in their shared cache(s) could do so by including 1264 Cache-Control: private, community="UCI" 1266 A cache seeing this header field will act correctly even if the cache 1267 does not understand the community cache-extension, since it will also 1268 see and understand the private directive and thus default to the safe 1269 behavior. 1271 A cache MUST ignore unrecognized cache directives; it is assumed that 1272 any cache directive likely to be unrecognized by an HTTP/1.1 cache 1273 will be combined with standard directives (or the response's default 1274 cacheability) such that the cache behavior will remain minimally 1275 correct even if the cache does not understand the extension(s). 1277 5.3. Expires 1279 The "Expires" header field gives the date/time after which the 1280 response is considered stale. See Section 4.2 for further discussion 1281 of the freshness model. 1283 The presence of an Expires field does not imply that the original 1284 resource will change or cease to exist at, before, or after that 1285 time. 1287 The Expires value is an HTTP-date timestamp, as defined in Section 1288 7.1.1.1 of [Part2]. 1290 Expires = HTTP-date 1292 For example 1294 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1296 A cache recipient MUST interpret invalid date formats, especially the 1297 value "0", as representing a time in the past (i.e., "already 1298 expired"). 1300 If a response includes a Cache-Control field with the max-age 1301 directive (Section 5.2.2.8), a recipient MUST ignore the Expires 1302 field. Likewise, if a response includes the s-maxage directive 1303 (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires 1304 field. In both these cases, the value in Expires is only intended 1305 for recipients that have not yet implemented the Cache-Control field. 1307 An origin server without a clock MUST NOT generate an Expires field 1308 unless its value represents a fixed time in the past (always expired) 1309 or its value has been associated with the resource by a system or 1310 user with a reliable clock. 1312 Historically, HTTP required the Expires field-value to be no more 1313 than a year in the future. While longer freshness lifetimes are no 1314 longer prohibited, extremely large values have been demonstrated to 1315 cause problems (e.g., clock overflows due to use of 32-bit integers 1316 for time values), and many caches will evict a response far sooner 1317 than that. 1319 5.4. Pragma 1321 The "Pragma" header field allows backwards compatibility with 1322 HTTP/1.0 caches, so that clients can specify a "no-cache" request 1323 that they will understand (as Cache-Control was not defined until 1324 HTTP/1.1). When the Cache-Control header field is also present and 1325 understood in a request, Pragma is ignored. 1327 In HTTP/1.0, Pragma was defined as an extensible field for 1328 implementation-specified directives for recipients. This 1329 specification deprecates such extensions to improve interoperability. 1331 Pragma = 1#pragma-directive 1332 pragma-directive = "no-cache" / extension-pragma 1333 extension-pragma = token [ "=" ( token / quoted-string ) ] 1335 When the Cache-Control header field is not present in a request, 1336 caches MUST consider the no-cache request pragma-directive as having 1337 the same effect as if "Cache-Control: no-cache" were present (see 1338 Section 5.2.1). 1340 When sending a no-cache request, a client ought to include both the 1341 pragma and cache-control directives, unless Cache-Control: no-cache 1342 is purposefully omitted to target other Cache-Control response 1343 directives at HTTP/1.1 caches. For example: 1345 GET / HTTP/1.1 1346 Host: www.example.com 1347 Cache-Control: max-age=30 1348 Pragma: no-cache 1350 will constrain HTTP/1.1 caches to serve a response no older than 30 1351 seconds, while precluding implementations that do not understand 1352 Cache-Control from serving a cached response. 1354 Note: Because the meaning of "Pragma: no-cache" in responses is 1355 not specified, it does not provide a reliable replacement for 1356 "Cache-Control: no-cache" in them. 1358 5.5. Warning 1360 The "Warning" header field is used to carry additional information 1361 about the status or transformation of a message that might not be 1362 reflected in the status code. This information is typically used to 1363 warn about possible incorrectness introduced by caching operations or 1364 transformations applied to the payload of the message. 1366 Warnings can be used for other purposes, both cache-related and 1367 otherwise. The use of a warning, rather than an error status code, 1368 distinguishes these responses from true failures. 1370 Warning header fields can in general be applied to any message, 1371 however some warn-codes are specific to caches and can only be 1372 applied to response messages. 1374 Warning = 1#warning-value 1376 warning-value = warn-code SP warn-agent SP warn-text 1377 [ SP warn-date ] 1379 warn-code = 3DIGIT 1380 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1381 ; the name or pseudonym of the server adding 1382 ; the Warning header field, for use in debugging 1383 ; a single "-" is recommended when agent unknown 1384 warn-text = quoted-string 1385 warn-date = DQUOTE HTTP-date DQUOTE 1387 Multiple warnings can be generated in a response (either by the 1388 origin server or by a cache), including multiple warnings with the 1389 same warn-code number that only differ in warn-text. 1391 A user agent that receives one or more Warning header fields SHOULD 1392 inform the user of as many of them as possible, in the order that 1393 they appear in the response. Senders that generate multiple Warning 1394 header fields are encouraged to order them with this user agent 1395 behavior in mind. A sender that generates new Warning header fields 1396 MUST append them after any existing Warning header fields. 1398 Warnings are assigned three digit warn-codes. The first digit 1399 indicates whether the Warning is required to be deleted from a stored 1400 response after validation: 1402 o 1xx warn-codes describe the freshness or validation status of the 1403 response, and so MUST be deleted by a cache after validation. 1404 They can only be generated by a cache when validating a cached 1405 entry, and MUST NOT be generated in any other situation. 1407 o 2xx warn-codes describe some aspect of the representation that is 1408 not rectified by a validation (for example, a lossy compression of 1409 the representation) and MUST NOT be deleted by a cache after 1410 validation, unless a full response is sent, in which case they 1411 MUST be. 1413 If a sender generates one or more 1xx warn-codes in a message to be 1414 sent to a recipient known to implement only HTTP/1.0, the sender MUST 1415 include in each corresponding warning-value a warn-date that matches 1416 the Date header field in the message. For example: 1418 HTTP/1.1 200 OK 1419 Date: Sat, 25 Aug 2012 23:34:45 GMT 1420 Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT" 1422 If a recipient that uses, evaluates, or displays Warning header 1423 fields receives a warn-date that is different from the Date value in 1424 the same message, the recipient MUST exclude the warning-value 1425 containing that warn-date before storing, forwarding, or using the 1426 message. This allows recipients to exclude warning-values that were 1427 improperly retained after a cache validation. If all of the warning- 1428 values are excluded, the recipient MUST exclude the Warning header 1429 field as well. 1431 The following warn-codes are defined by this specification, each with 1432 a recommended warn-text in English, and a description of its meaning. 1433 The procedure for defining additional warn codes is described in 1434 Section 7.2.1. 1436 5.5.1. Warning: 110 - "Response is Stale" 1438 A cache SHOULD generate this whenever the sent response is stale. 1440 5.5.2. Warning: 111 - "Revalidation Failed" 1442 A cache SHOULD generate this when sending a stale response because an 1443 attempt to validate the response failed, due to an inability to reach 1444 the server. 1446 5.5.3. Warning: 112 - "Disconnected Operation" 1448 A cache SHOULD generate this if it is intentionally disconnected from 1449 the rest of the network for a period of time. 1451 5.5.4. Warning: 113 - "Heuristic Expiration" 1453 A cache SHOULD generate this if it heuristically chose a freshness 1454 lifetime greater than 24 hours and the response's age is greater than 1455 24 hours. 1457 5.5.5. Warning: 199 - "Miscellaneous Warning" 1459 The warning text can include arbitrary information to be presented to 1460 a human user, or logged. A system receiving this warning MUST NOT 1461 take any automated action, besides presenting the warning to the 1462 user. 1464 5.5.6. Warning: 214 - "Transformation Applied" 1466 MUST be added by a proxy if it applies any transformation to the 1467 representation, such as changing the content-coding, media-type, or 1468 modifying the representation data, unless this Warning code already 1469 appears in the response. 1471 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" 1473 The warning text can include arbitrary information to be presented to 1474 a human user, or logged. A system receiving this warning MUST NOT 1475 take any automated action. 1477 6. History Lists 1479 User agents often have history mechanisms, such as "Back" buttons and 1480 history lists, that can be used to redisplay a representation 1481 retrieved earlier in a session. 1483 The freshness model (Section 4.2) does not necessarily apply to 1484 history mechanisms. I.e., a history mechanism can display a previous 1485 representation even if it has expired. 1487 This does not prohibit the history mechanism from telling the user 1488 that a view might be stale, or from honoring cache directives (e.g., 1489 Cache-Control: no-store). 1491 7. IANA Considerations 1493 7.1. Cache Directive Registry 1495 The HTTP Cache Directive Registry defines the name space for the 1496 cache directives. It will be created and maintained at (the 1497 suggested URI) 1498 . 1500 7.1.1. Procedure 1502 A registration MUST include the following fields: 1504 o Cache Directive Name 1506 o Pointer to specification text 1508 Values to be added to this name space require IETF Review (see 1509 [RFC5226], Section 4.1). 1511 7.1.2. Considerations for New Cache Control Directives 1513 New extension directives ought to consider defining: 1515 o What it means for a directive to be specified multiple times, 1517 o When the directive does not take an argument, what it means when 1518 an argument is present, 1520 o When the directive requires an argument, what it means when it is 1521 missing, 1523 o Whether the directive is specific to requests, responses, or able 1524 to be used in either. 1526 See also Section 5.2.3. 1528 7.1.3. Registrations 1530 The HTTP Cache Directive Registry shall be populated with the 1531 registrations below: 1533 +------------------------+----------------------------------+ 1534 | Cache Directive | Reference | 1535 +------------------------+----------------------------------+ 1536 | max-age | Section 5.2.1.1, Section 5.2.2.8 | 1537 | max-stale | Section 5.2.1.2 | 1538 | min-fresh | Section 5.2.1.3 | 1539 | must-revalidate | Section 5.2.2.1 | 1540 | no-cache | Section 5.2.1.4, Section 5.2.2.2 | 1541 | no-store | Section 5.2.1.5, Section 5.2.2.3 | 1542 | no-transform | Section 5.2.1.6, Section 5.2.2.4 | 1543 | only-if-cached | Section 5.2.1.7 | 1544 | private | Section 5.2.2.6 | 1545 | proxy-revalidate | Section 5.2.2.7 | 1546 | public | Section 5.2.2.5 | 1547 | s-maxage | Section 5.2.2.9 | 1548 | stale-if-error | [RFC5861], Section 4 | 1549 | stale-while-revalidate | [RFC5861], Section 3 | 1550 +------------------------+----------------------------------+ 1552 7.2. Warn Code Registry 1554 The HTTP Warn Code Registry defines the name space for warn codes. 1555 It will be created and maintained at (the suggested URI) 1556 . 1558 7.2.1. Procedure 1560 A registration MUST include the following fields: 1562 o Warn Code (3 digits) 1564 o Short Description 1566 o Pointer to specification text 1568 Values to be added to this name space require IETF Review (see 1569 [RFC5226], Section 4.1). 1571 7.2.2. Registrations 1573 The HTTP Warn Code Registry shall be populated with the registrations 1574 below: 1576 +-----------+----------------------------------+---------------+ 1577 | Warn Code | Short Description | Reference | 1578 +-----------+----------------------------------+---------------+ 1579 | 110 | Response is Stale | Section 5.5.1 | 1580 | 111 | Revalidation Failed | Section 5.5.2 | 1581 | 112 | Disconnected Operation | Section 5.5.3 | 1582 | 113 | Heuristic Expiration | Section 5.5.4 | 1583 | 199 | Miscellaneous Warning | Section 5.5.5 | 1584 | 214 | Transformation Applied | Section 5.5.6 | 1585 | 299 | Miscellaneous Persistent Warning | Section 5.5.7 | 1586 +-----------+----------------------------------+---------------+ 1588 7.3. Header Field Registration 1590 HTTP header fields are registered within the Message Header Field 1591 Registry maintained at . 1594 This document defines the following HTTP header fields, so their 1595 associated registry entries shall be updated according to the 1596 permanent registrations below (see [BCP90]): 1598 +-------------------+----------+----------+-------------+ 1599 | Header Field Name | Protocol | Status | Reference | 1600 +-------------------+----------+----------+-------------+ 1601 | Age | http | standard | Section 5.1 | 1602 | Cache-Control | http | standard | Section 5.2 | 1603 | Expires | http | standard | Section 5.3 | 1604 | Pragma | http | standard | Section 5.4 | 1605 | Warning | http | standard | Section 5.5 | 1606 +-------------------+----------+----------+-------------+ 1608 The change controller is: "IETF (iesg@ietf.org) - Internet 1609 Engineering Task Force". 1611 8. Security Considerations 1613 This section is meant to inform developers, information providers, 1614 and users of known security concerns specific to HTTP/1.1 caching. 1615 More general security considerations are addressed in HTTP messaging 1616 [Part1] and semantics [Part2]. 1618 Caches expose additional potential vulnerabilities, since the 1619 contents of the cache represent an attractive target for malicious 1620 exploitation. Because cache contents persist after an HTTP request 1621 is complete, an attack on the cache can reveal information long after 1622 a user believes that the information has been removed from the 1623 network. Therefore, cache contents need to be protected as sensitive 1624 information. 1626 Furthermore, the very use of a cache can bring about privacy 1627 concerns. For example, if two users share a cache, and the first one 1628 browses to a site, the second may be able to detect that the other 1629 has been to that site, because the resources from it load more 1630 quickly, thanks to the cache. 1632 Implementation flaws might allow attackers to insert content into a 1633 cache ("cache poisoning"), leading to compromise of clients that 1634 trust that content. Because of their nature, these attacks are 1635 difficult to mitigate. 1637 Likewise, implementation flaws (as well as misunderstanding of cache 1638 operation) might lead to caching of sensitive information (e.g., 1639 authentication credentials) that is thought to be private, exposing 1640 it to unauthorized parties. 1642 Note that the Set-Cookie response header field [RFC6265] does not 1643 inhibit caching; a cacheable response with a Set-Cookie header field 1644 can be (and often is) used to satisfy subsequent requests to caches. 1645 Servers who wish to control caching of these responses are encouraged 1646 to emit appropriate Cache-Control response header fields. 1648 9. Acknowledgments 1650 See Section 10 of [Part1]. 1652 10. References 1654 10.1. Normative References 1656 [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1657 Protocol (HTTP/1.1): Message Syntax and Routing", 1658 draft-ietf-httpbis-p1-messaging-25 (work in progress), 1659 November 2013. 1661 [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1662 Protocol (HTTP/1.1): Semantics and Content", 1663 draft-ietf-httpbis-p2-semantics-25 (work in progress), 1664 November 2013. 1666 [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1667 Protocol (HTTP/1.1): Conditional Requests", 1668 draft-ietf-httpbis-p4-conditional-25 (work in progress), 1669 November 2013. 1671 [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1672 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 1673 draft-ietf-httpbis-p5-range-25 (work in progress), 1674 November 2013. 1676 [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1677 Protocol (HTTP/1.1): Authentication", 1678 draft-ietf-httpbis-p7-auth-25 (work in progress), 1679 November 2013. 1681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1682 Requirement Levels", BCP 14, RFC 2119, March 1997. 1684 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1685 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1687 10.2. Informative References 1689 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1690 Procedures for Message Header Fields", BCP 90, RFC 3864, 1691 September 2004. 1693 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1694 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1695 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1697 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1698 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1699 May 2008. 1701 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1702 Content", RFC 5861, April 2010. 1704 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1705 "Network Time Protocol Version 4: Protocol and Algorithms 1706 Specification", RFC 5905, June 2010. 1708 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1709 April 2011. 1711 Appendix A. Changes from RFC 2616 1713 The specification has been substantially rewritten for clarity. 1715 The conditions under which an authenticated response can be cached 1716 have been clarified. (Section 3.2) 1718 New status codes can now define that caches are allowed to use 1719 heuristic freshness with them. Caches are now allowed to calculate 1720 heuristic freshness for URIs with query components. (Section 4.2.2) 1722 The algorithm for calculating age is now less conservative. Caches 1723 are now required to handle dates with timezones as if they're 1724 invalid, because it's not possible to accurately guess. 1725 (Section 4.2.3) 1727 The Content-Location response header field is no longer used to 1728 determine the appropriate response to use when validating. 1729 (Section 4.3) 1731 The algorithm for selecting a cached negotiated response to use has 1732 been clarified in several ways. In particular, it now explicitly 1733 allows header-specific canonicalization when processing selecting 1734 header fields. (Section 4.1) 1736 Requirements regarding denial of service attack avoidance when 1737 performing invalidation have been clarified. (Section 4.4) 1739 Cache invalidation only occurs when a successful response is 1740 received. (Section 4.4) 1742 Cache directives are explicitly defined to be case-insensitive. 1743 Handling of multiple instances of cache directives when only one is 1744 expected is now defined. (Section 5.2) 1746 The "no-store" cache request directive doesn't apply to responses; 1747 i.e., a cache can satisfy a request with no-store on it, and does not 1748 invalidate it. (Section 5.2.1.5) 1750 The qualified forms of the private and no-cache cache directives are 1751 noted to not be widely implemented; e.g., "private=foo" is 1752 interpreted by many caches as simply "private". Additionally, the 1753 meaning of the qualified form of no-cache has been clarified. 1754 (Section 5.2.2) 1756 The "no-cache" response cache directive's meaning has been clarified. 1757 (Section 5.2.2.2) 1759 The one-year limit on Expires header field values has been removed; 1760 instead, the reasoning for using a sensible value is given. 1761 (Section 5.3) 1763 The Pragma header field is now only defined for backwards 1764 compatibility; future pragmas are deprecated. (Section 5.4) 1766 Some requirements regarding production and processing of the Warning 1767 header fields have been relaxed, as it is not widely implemented. 1769 Furthermore, the Warning header field no longer uses RFC 2047 1770 encoding, nor allows multiple languages, as these aspects were not 1771 implemented. (Section 5.5) 1773 This specification introduces the Cache Directive and Warn Code 1774 Registries, and defines considerations for new cache directives. 1775 (Section 7.1 and Section 7.2) 1777 Appendix B. Imported ABNF 1779 The following core rules are included by reference, as defined in 1780 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 1781 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 1782 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 1783 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 1784 character). 1786 The rules below are defined in [Part1]: 1788 OWS = 1789 field-name = 1790 quoted-string = 1791 token = 1793 port = 1794 pseudonym = 1795 uri-host = 1797 The rules below are defined in other parts: 1799 HTTP-date = 1801 Appendix C. Collected ABNF 1803 In the collected ABNF below, list rules are expanded as per Section 1804 1.2 of [Part1]. 1806 Age = delta-seconds 1808 Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS 1809 cache-directive ] ) 1811 Expires = HTTP-date 1813 HTTP-date = 1815 OWS = 1817 Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS 1818 pragma-directive ] ) 1820 Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] 1821 ) 1823 cache-directive = token [ "=" ( token / quoted-string ) ] 1825 delta-seconds = 1*DIGIT 1827 extension-pragma = token [ "=" ( token / quoted-string ) ] 1829 field-name = 1831 port = 1832 pragma-directive = "no-cache" / extension-pragma 1833 pseudonym = 1835 quoted-string = 1837 token = 1839 uri-host = 1841 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1842 warn-code = 3DIGIT 1843 warn-date = DQUOTE HTTP-date DQUOTE 1844 warn-text = quoted-string 1845 warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date 1846 ] 1848 Appendix D. Change Log (to be removed by RFC Editor before publication) 1850 Changes up to the IETF Last Call draft are summarized in . 1853 D.1. Since draft-ietf-httpbis-p6-cache-24 1855 Closed issues: 1857 o : "RFC 1305 ref 1858 needs to be updated to 5905" 1860 o : "dangling 1861 reference to cacheable status codes" 1863 o : "APPSDIR 1864 review of draft-ietf-httpbis-p6-cache-24" 1866 Index 1868 1 1869 110 (warn-code) 31 1870 111 (warn-code) 31 1871 112 (warn-code) 31 1872 113 (warn-code) 31 1873 199 (warn-code) 31 1875 2 1876 214 (warn-code) 31 1877 299 (warn-code) 31 1879 A 1880 age 10 1881 Age header field 20 1883 C 1884 cache 4 1885 cache entry 5 1886 cache key 5 1887 Cache-Control header field 21 1889 D 1890 Disconnected Operation (warn-text) 31 1892 E 1893 Expires header field 27 1894 explicit expiration time 10 1896 F 1897 fresh 10 1898 freshness lifetime 10 1900 G 1901 Grammar 1902 Age 20 1903 Cache-Control 21 1904 cache-directive 21 1905 delta-seconds 5 1906 Expires 27 1907 extension-pragma 28 1908 Pragma 28 1909 pragma-directive 28 1910 warn-agent 29 1911 warn-code 29 1912 warn-date 29 1913 warn-text 29 1914 Warning 29 1915 warning-value 29 1917 H 1918 Heuristic Expiration (warn-text) 31 1919 heuristic expiration time 10 1921 M 1922 max-age (cache directive) 21, 26 1923 max-stale (cache directive) 22 1924 min-fresh (cache directive) 22 1925 Miscellaneous Persistent Warning (warn-text) 31 1926 Miscellaneous Warning (warn-text) 31 1927 must-revalidate (cache directive) 23 1929 N 1930 no-cache (cache directive) 22, 24 1931 no-store (cache directive) 22, 24 1932 no-transform (cache directive) 23, 25 1934 O 1935 only-if-cached (cache directive) 23 1937 P 1938 Pragma header field 28 1939 private (cache directive) 25 1940 private cache 4 1941 proxy-revalidate (cache directive) 26 1942 public (cache directive) 25 1944 R 1945 Response is Stale (warn-text) 31 1946 Revalidation Failed (warn-text) 31 1948 S 1949 s-maxage (cache directive) 26 1950 shared cache 4 1951 stale 10 1952 strong validator 18 1954 T 1955 Transformation Applied (warn-text) 31 1957 V 1958 validator 15 1960 W 1961 Warning header field 29 1963 Authors' Addresses 1965 Roy T. Fielding (editor) 1966 Adobe Systems Incorporated 1967 345 Park Ave 1968 San Jose, CA 95110 1969 USA 1971 EMail: fielding@gbiv.com 1972 URI: http://roy.gbiv.com/ 1974 Mark Nottingham (editor) 1975 Akamai 1977 EMail: mnot@mnot.net 1978 URI: http://www.mnot.net/ 1980 Julian F. Reschke (editor) 1981 greenbytes GmbH 1982 Hafenweg 16 1983 Muenster, NW 48155 1984 Germany 1986 EMail: julian.reschke@greenbytes.de 1987 URI: http://greenbytes.de/tech/webdav/