idnits 2.17.1 draft-ietf-httpbis-p6-cache-18.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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 4, 2012) is 4490 days in the past. Is this intentional? 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-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p4-conditional-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p5-range-18 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p7-auth-18 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- 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 (~~), 6 warnings (==), 5 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) J. Gettys 5 Intended status: Standards Track Alcatel-Lucent 6 Expires: July 7, 2012 J. Mogul 7 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 M. Nottingham, Ed. 19 Rackspace 20 J. Reschke, Ed. 21 greenbytes 22 January 4, 2012 24 HTTP/1.1, part 6: Caching 25 draft-ietf-httpbis-p6-cache-18 27 Abstract 29 The Hypertext Transfer Protocol (HTTP) is an application-level 30 protocol for distributed, collaborative, hypertext information 31 systems. HTTP has been in use by the World Wide Web global 32 information initiative since 1990. This document is Part 6 of the 33 seven-part specification that defines the protocol referred to as 34 "HTTP/1.1" and, taken together, obsoletes RFC 2616. 36 Part 6 defines requirements on HTTP caches and the associated header 37 fields that control cache behavior or indicate cacheable response 38 messages. 40 Editorial Note (To be removed by RFC Editor) 42 Discussion of this draft should take place on the HTTPBIS working 43 group mailing list (ietf-http-wg@w3.org), which is archived at 44 . 46 The current issues list is at 47 and related 48 documents (including fancy diffs) can be found at 49 . 51 The changes in this draft are summarized in Appendix C.19. 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at http://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on July 7, 2012. 70 Copyright Notice 72 Copyright (c) 2012 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 This document may contain material from IETF Documents or IETF 86 Contributions published or made publicly available before November 87 10, 2008. The person(s) controlling the copyright in some of this 88 material may not have granted the IETF Trust the right to allow 89 modifications of such material outside the IETF Standards Process. 90 Without obtaining an adequate license from the person(s) controlling 91 the copyright in such materials, this document may not be modified 92 outside the IETF Standards Process, and derivative works of it may 93 not be created outside the IETF Standards Process, except to format 94 it for publication as an RFC or to translate it into languages other 95 than English. 97 Table of Contents 99 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 100 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 101 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 102 1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7 103 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 104 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8 105 1.4.2. ABNF Rules defined in other Parts of the 106 Specification . . . . . . . . . . . . . . . . . . . . 8 107 1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8 108 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 109 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9 110 2.2. Constructing Responses from Caches . . . . . . . . . . . . 10 111 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 12 112 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 13 113 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 14 114 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 16 115 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 116 2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17 117 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18 118 2.6. Shared Caching of Authenticated Responses . . . . . . . . 18 119 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19 120 2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20 121 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 122 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 123 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 124 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 125 3.2.2. Response Cache-Control Directives . . . . . . . . . . 23 126 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 127 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 128 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 129 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 130 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 131 3.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31 132 3.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 31 133 3.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 31 134 3.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 31 135 3.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 31 136 3.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 31 137 3.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31 138 3.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32 139 3.7. History Lists . . . . . . . . . . . . . . . . . . . . . . 32 140 3.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 32 141 3.8.1. Cache Directive Registry . . . . . . . . . . . . . . . 32 142 3.8.2. Warn Code Registry . . . . . . . . . . . . . . . . . . 33 143 3.9. Header Field Registration . . . . . . . . . . . . . . . . 33 144 4. Security Considerations . . . . . . . . . . . . . . . . . . . 34 145 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 146 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 147 6.1. Normative References . . . . . . . . . . . . . . . . . . . 34 148 6.2. Informative References . . . . . . . . . . . . . . . . . . 35 149 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 150 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 36 151 Appendix C. Change Log (to be removed by RFC Editor before 152 publication) . . . . . . . . . . . . . . . . . . . . 37 153 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 154 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37 155 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 38 156 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38 157 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 39 158 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 39 159 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 39 160 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 40 161 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 40 162 C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 40 163 C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 41 164 C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 41 165 C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41 166 C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 42 167 C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 42 168 C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 42 169 C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42 170 C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 43 171 C.19. Since draft-ietf-httpbis-p6-cache-17 . . . . . . . . . . . 43 172 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 174 1. Introduction 176 HTTP is typically used for distributed information systems, where 177 performance can be improved by the use of response caches. This 178 document defines aspects of HTTP/1.1 related to caching and reusing 179 response messages. 181 1.1. Purpose 183 An HTTP cache is a local store of response messages and the subsystem 184 that controls its message storage, retrieval, and deletion. A cache 185 stores cacheable responses in order to reduce the response time and 186 network bandwidth consumption on future, equivalent requests. Any 187 client or server MAY employ a cache, though a cache cannot be used by 188 a server that is acting as a tunnel. 190 The goal of caching in HTTP/1.1 is to significantly improve 191 performance by reusing a prior response message to satisfy a current 192 request. A stored response is considered "fresh", as defined in 193 Section 2.3, if the response can be reused without "validation" 194 (checking with the origin server to see if the cached response 195 remains valid for this request). A fresh cache response can 196 therefore reduce both latency and network transfers each time it is 197 reused. When a cached response is not fresh, it might still be 198 reusable if it can be freshened by validation (Section 2.4) or if the 199 origin is unavailable. 201 1.2. Terminology 203 This specification uses a number of terms to refer to the roles 204 played by participants in, and objects of, HTTP caching. 206 cache 208 A conformant implementation of a HTTP cache. Note that this 209 implies an HTTP/1.1 cache; this specification does not define 210 conformance for HTTP/1.0 caches. 212 shared cache 214 A cache that stores responses to be reused by more than one user; 215 usually (but not always) deployed as part of an intermediary. 217 private cache 219 A cache that is dedicated to a single user. 221 cacheable 223 A response is cacheable if a cache is allowed to store a copy of 224 the response message for use in answering subsequent requests. 225 Even when a response is cacheable, there might be additional 226 constraints on whether a cache can use the stored copy to satisfy 227 a particular request. 229 explicit expiration time 231 The time at which the origin server intends that a representation 232 no longer be returned by a cache without further validation. 234 heuristic expiration time 236 An expiration time assigned by a cache when no explicit expiration 237 time is available. 239 age 241 The age of a response is the time since it was sent by, or 242 successfully validated with, the origin server. 244 first-hand 246 A response is first-hand if the freshness model is not in use; 247 i.e., its age is 0. 249 freshness lifetime 251 The length of time between the generation of a response and its 252 expiration time. 254 fresh 256 A response is fresh if its age has not yet exceeded its freshness 257 lifetime. 259 stale 261 A response is stale if its age has passed its freshness lifetime 262 (either explicit or heuristic). 264 validator 266 A protocol element (e.g., an entity-tag or a Last-Modified time) 267 that is used to find out whether a stored response is an 268 equivalent copy of a representation. See Section 2.1 of [Part4]. 270 strong validator 272 A validator that is defined by the origin server such that its 273 current value will change if the representation body changes; 274 i.e., an entity-tag that is not marked as weak (Section 2.3 of 275 [Part4]) or, if no entity-tag is provided, a Last-Modified value 276 that is strong in the sense defined by Section 2.2.2 of [Part4]. 278 1.3. Conformance and Error Handling 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 282 document are to be interpreted as described in [RFC2119]. 284 This document defines conformance criteria for several roles in HTTP 285 communication, including Senders, Recipients, Clients, Servers, User- 286 Agents, Origin Servers, Intermediaries, Proxies and Gateways. See 287 Section 2 of [Part1] for definitions of these terms. 289 An implementation is considered conformant if it complies with all of 290 the requirements associated with its role(s). Note that SHOULD-level 291 requirements are relevant here, unless one of the documented 292 exceptions is applicable. 294 This document also uses ABNF to define valid protocol elements 295 (Section 1.4). In addition to the prose requirements placed upon 296 them, Senders MUST NOT generate protocol elements that are invalid. 298 Unless noted otherwise, Recipients MAY take steps to recover a usable 299 protocol element from an invalid construct. However, HTTP does not 300 define specific error handling mechanisms, except in cases where it 301 has direct impact on security. This is because different uses of the 302 protocol require different error handling strategies; for example, a 303 Web browser may wish to transparently recover from a response where 304 the Location header field doesn't parse according to the ABNF, 305 whereby in a systems control protocol using HTTP, this type of error 306 recovery could lead to dangerous consequences. 308 1.4. Syntax Notation 310 This specification uses the ABNF syntax defined in Section 1.2 of 311 [Part1] (which extends the syntax defined in [RFC5234] with a list 312 rule). Appendix B shows the collected ABNF, with the list rule 313 expanded. 315 The following core rules are included by reference, as defined in 316 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 317 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 318 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit 319 sequence of data), SP (space), and VCHAR (any visible US-ASCII 320 character). 322 1.4.1. Core Rules 324 The core rules below are defined in [Part1]: 326 OWS = 327 quoted-string = 328 token = 330 1.4.2. ABNF Rules defined in other Parts of the Specification 332 The ABNF rules below are defined in other parts: 334 field-name = 335 HTTP-date = 336 port = 337 pseudonym = 338 uri-host = 340 1.5. Delta Seconds 342 The delta-seconds rule specifies a non-negative integer, representing 343 time in seconds. 345 delta-seconds = 1*DIGIT 347 If an implementation receives a delta-seconds value larger than the 348 largest positive integer it can represent, or if any of its 349 subsequent calculations overflows, it MUST consider the value to be 350 2147483648 (2^31). Recipients parsing a delta-seconds value MUST use 351 an arithmetic type of at least 31 bits of range, and senders MUST NOT 352 send delta-seconds with a value greater than 2147483648. 354 2. Cache Operation 356 Proper cache operation preserves the semantics of HTTP transfers 357 ([Part2]) while eliminating the transfer of information already held 358 in the cache. Although caching is an entirely OPTIONAL feature of 359 HTTP, we assume that reusing the cached response is desirable and 360 that such reuse is the default behavior when no requirement or 361 locally-desired configuration prevents it. Therefore, HTTP cache 362 requirements are focused on preventing a cache from either storing a 363 non-reusable response or reusing a stored response inappropriately. 365 Each cache entry consists of a cache key and one or more HTTP 366 responses corresponding to prior requests that used the same key. 367 The most common form of cache entry is a successful result of a 368 retrieval request: i.e., a 200 (OK) response containing a 369 representation of the resource identified by the request target. 370 However, it is also possible to cache negative results (e.g., 404 not 371 found), incomplete results (e.g., 206 partial content), and responses 372 to safe methods other than GET if the method's definition allows such 373 caching and defines something suitable for use as a cache key. 375 The default cache key consists of the request method and target URI. 376 However, since HTTP caches in common use today are typically limited 377 to caching responses to GET, most implementations simply decline 378 other methods and use only the URI as the key. 380 If a request target is subject to content negotiation, its cache 381 entry might consist of multiple stored responses, each differentiated 382 by a secondary key for the values of the original request's selecting 383 header fields (Section 2.7). 385 2.1. Response Cacheability 387 A cache MUST NOT store a response to any request, unless: 389 o The request method is understood by the cache and defined as being 390 cacheable, and 392 o the response status code is understood by the cache, and 394 o the "no-store" cache directive (see Section 3.2) does not appear 395 in request or response header fields, and 397 o the "private" cache response directive (see Section 3.2.2 does not 398 appear in the response, if the cache is shared, and 400 o the "Authorization" header field (see Section 4.1 of [Part7]) does 401 not appear in the request, if the cache is shared, unless the 402 response explicitly allows it (see Section 2.6), and 404 o the response either: 406 * contains an Expires header field (see Section 3.3), or 408 * contains a max-age response cache directive (see 409 Section 3.2.2), or 411 * contains a s-maxage response cache directive and the cache is 412 shared, or 414 * contains a Cache Control Extension (see Section 3.2.3) that 415 allows it to be cached, or 417 * has a status code that can be served with heuristic freshness 418 (see Section 2.3.1.1). 420 Note that any of the requirements listed above can be overridden by a 421 cache-control extension; see Section 3.2.3. 423 In this context, a cache has "understood" a request method or a 424 response status code if it recognizes it and implements any cache- 425 specific behavior. 427 Note that, in normal operation, most caches will not store a response 428 that has neither a cache validator nor an explicit expiration time, 429 as such responses are not usually useful to store. However, caches 430 are not prohibited from storing such responses. 432 A response message is considered complete when all of the octets 433 indicated by the message framing ([Part1]) are received prior to the 434 connection being closed. If the request is GET, the response status 435 is 200 (OK), and the entire response header block has been received, 436 a cache MAY store an incomplete response message-body if the cache 437 entry is recorded as incomplete. Likewise, a 206 (Partial Content) 438 response MAY be stored as if it were an incomplete 200 (OK) cache 439 entry. However, a cache MUST NOT store incomplete or partial content 440 responses if it does not support the Range and Content-Range header 441 fields or if it does not understand the range units used in those 442 fields. 444 A cache MAY complete a stored incomplete response by making a 445 subsequent range request ([Part5]) and combining the successful 446 response with the stored entry, as defined in Section 2.8. A cache 447 MUST NOT use an incomplete response to answer requests unless the 448 response has been made complete or the request is partial and 449 specifies a range that is wholly within the incomplete response. A 450 cache MUST NOT send a partial response to a client without explicitly 451 marking it as such using the 206 (Partial Content) status code. 453 2.2. Constructing Responses from Caches 455 For a presented request, a cache MUST NOT return a stored response, 456 unless: 458 o The presented effective request URI (Section 4.3 of [Part1]) and 459 that of the stored response match, and 461 o the request method associated with the stored response allows it 462 to be used for the presented request, and 464 o selecting header fields nominated by the stored response (if any) 465 match those presented (see Section 2.7), and 467 o the presented request does not contain the no-cache pragma 468 (Section 3.4), nor the no-cache cache directive (Section 3.2.1), 469 unless the stored response is successfully validated 470 (Section 2.4), and 472 o the stored response does not contain the no-cache cache directive 473 (Section 3.2.2), unless it is successfully validated 474 (Section 2.4), and 476 o the stored response is either: 478 * fresh (see Section 2.3), or 480 * allowed to be served stale (see Section 2.3.3), or 482 * successfully validated (see Section 2.4). 484 Note that any of the requirements listed above can be overridden by a 485 cache-control extension; see Section 3.2.3. 487 When a stored response is used to satisfy a request without 488 validation, a cache MUST include a single Age header field 489 (Section 3.1) in the response with a value equal to the stored 490 response's current_age; see Section 2.3.2. 492 A cache MUST write through requests with methods that are unsafe 493 (Section 6.1.1 of [Part2]) to the origin server; i.e., a cache must 494 not generate a reply to such a request before having forwarded the 495 request and having received a corresponding response. 497 Also, note that unsafe requests might invalidate already stored 498 responses; see Section 2.5. 500 When more than one suitable response is stored, a cache MUST use the 501 most recent response (as determined by the Date header field). It 502 can also forward a request with "Cache-Control: max-age=0" or "Cache- 503 Control: no-cache" to disambiguate which response to use. 505 A cache that does not have a clock available MUST NOT use stored 506 responses without revalidating them on every use. A cache, 507 especially a shared cache, SHOULD use a mechanism, such as NTP 508 [RFC1305], to synchronize its clock with a reliable external 509 standard. 511 2.3. Freshness Model 513 When a response is "fresh" in the cache, it can be used to satisfy 514 subsequent requests without contacting the origin server, thereby 515 improving efficiency. 517 The primary mechanism for determining freshness is for an origin 518 server to provide an explicit expiration time in the future, using 519 either the Expires header field (Section 3.3) or the max-age response 520 cache directive (Section 3.2.2). Generally, origin servers will 521 assign future explicit expiration times to responses in the belief 522 that the representation is not likely to change in a semantically 523 significant way before the expiration time is reached. 525 If an origin server wishes to force a cache to validate every 526 request, it can assign an explicit expiration time in the past to 527 indicate that the response is already stale. Compliant caches will 528 normally validate the cached response before reusing it for 529 subsequent requests (see Section 2.3.3). 531 Since origin servers do not always provide explicit expiration times, 532 a cache MAY assign a heuristic expiration time when an explicit time 533 is not specified, employing algorithms that use other header field 534 values (such as the Last-Modified time) to estimate a plausible 535 expiration time. This specification does not provide specific 536 algorithms, but does impose worst-case constraints on their results. 538 The calculation to determine if a response is fresh is: 540 response_is_fresh = (freshness_lifetime > current_age) 542 The freshness_lifetime is defined in Section 2.3.1; the current_age 543 is defined in Section 2.3.2. 545 Additionally, clients can influence freshness calculation -- either 546 constraining it relaxing it -- by using the max-age and min-fresh 547 request cache directives. See Section 3.2.1 for details. 549 Note that freshness applies only to cache operation; it cannot be 550 used to force a user agent to refresh its display or reload a 551 resource. See Section 3.7 for an explanation of the difference 552 between caches and history mechanisms. 554 2.3.1. Calculating Freshness Lifetime 556 A cache can calculate the freshness lifetime (denoted as 557 freshness_lifetime) of a response by using the first match of: 559 o If the cache is shared and the s-maxage response cache directive 560 (Section 3.2.2) is present, use its value, or 562 o If the max-age response cache directive (Section 3.2.2) is 563 present, use its value, or 565 o If the Expires response header field (Section 3.3) is present, use 566 its value minus the value of the Date response header field, or 568 o Otherwise, no explicit expiration time is present in the response. 569 A heuristic freshness lifetime might be applicable; see 570 Section 2.3.1.1. 572 Note that this calculation is not vulnerable to clock skew, since all 573 of the information comes from the origin server. 575 2.3.1.1. Calculating Heuristic Freshness 577 If no explicit expiration time is present in a stored response that 578 has a status code whose definition allows heuristic freshness to be 579 used (including the following in Section 7 of [Part2]: 200, 203, 206, 580 300, 301 and 410), a cache MAY calculate a heuristic expiration time. 581 A cache MUST NOT use heuristics to determine freshness for responses 582 with status codes that do not explicitly allow it. 584 When a heuristic is used to calculate freshness lifetime, a cache 585 SHOULD attach a Warning header field with a 113 warn-code to the 586 response if its current_age is more than 24 hours and such a warning 587 is not already present. 589 Also, if the response has a Last-Modified header field (Section 2.2 590 of [Part4]), caches are encouraged to use a heuristic expiration 591 value that is no more than some fraction of the interval since that 592 time. A typical setting of this fraction might be 10%. 594 Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do 595 not calculate heuristic freshness for URIs with query components 596 (i.e., those containing '?'). In practice, this has not been 597 widely implemented. Therefore, servers are encouraged to send 598 explicit directives (e.g., Cache-Control: no-cache) if they wish 599 to preclude caching. 601 2.3.2. Calculating Age 603 HTTP/1.1 uses the Age header field to convey the estimated age of the 604 response message when obtained from a cache. The Age field value is 605 the cache's estimate of the amount of time since the response was 606 generated or validated by the origin server. In essence, the Age 607 value is the sum of the time that the response has been resident in 608 each of the caches along the path from the origin server, plus the 609 amount of time it has been in transit along network paths. 611 The following data is used for the age calculation: 613 age_value 615 The term "age_value" denotes the value of the Age header field 616 (Section 3.1), in a form appropriate for arithmetic operation; or 617 0, if not available. 619 date_value 621 HTTP/1.1 requires origin servers to send a Date header field, if 622 possible, with every response, giving the time at which the 623 response was generated. The term "date_value" denotes the value 624 of the Date header field, in a form appropriate for arithmetic 625 operations. See Section 9.2 of [Part2] for the definition of the 626 Date header field, and for requirements regarding responses 627 without it. 629 now 631 The term "now" means "the current value of the clock at the host 632 performing the calculation". A cache SHOULD use NTP ([RFC1305]) 633 or some similar protocol to synchronize its clocks to a globally 634 accurate time standard. 636 request_time 638 The current value of the clock at the host at the time the request 639 resulting in the stored response was made. 641 response_time 643 The current value of the clock at the host at the time the 644 response was received. 646 A response's age can be calculated in two entirely independent ways: 648 1. the "apparent_age": response_time minus date_value, if the local 649 clock is reasonably well synchronized to the origin server's 650 clock. If the result is negative, the result is replaced by 651 zero. 653 2. the "corrected_age_value", if all of the caches along the 654 response path implement HTTP/1.1. A cache MUST interpret this 655 value relative to the time the request was initiated, not the 656 time that the response was received. 658 apparent_age = max(0, response_time - date_value); 660 response_delay = response_time - request_time; 661 corrected_age_value = age_value + response_delay; 663 These SHOULD be combined as 665 corrected_initial_age = max(apparent_age, corrected_age_value); 667 unless the cache is confident in the value of the Age header (e.g., 668 because there are no HTTP/1.0 hops in the Via header), in which case 669 the corrected_age_value MAY be used as the corrected_initial_age. 671 The current_age of a stored response can then be calculated by adding 672 the amount of time (in seconds) since the stored response was last 673 validated by the origin server to the corrected_initial_age. 675 resident_time = now - response_time; 676 current_age = corrected_initial_age + resident_time; 678 Additionally, to avoid common problems in date parsing: 680 o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date 681 which appears to be more than 50 years in the future is in fact in 682 the past (this helps solve the "year 2000" problem). 684 o Although all date formats are specified to be case-sensitive, 685 recipients SHOULD match day, week and timezone names case- 686 insensitively. 688 o An HTTP/1.1 implementation MAY internally represent a parsed 689 Expires date as earlier than the proper value, but MUST NOT 690 internally represent a parsed Expires date as later than the 691 proper value. 693 o All expiration-related calculations MUST be done in GMT. The 694 local time zone MUST NOT influence the calculation or comparison 695 of an age or expiration time. 697 o If an HTTP header field incorrectly carries a date value with a 698 time zone other than GMT, it MUST be converted into GMT using the 699 most conservative possible conversion. 701 2.3.3. Serving Stale Responses 703 A "stale" response is one that either has explicit expiry information 704 or is allowed to have heuristic expiry calculated, but is not fresh 705 according to the calculations in Section 2.3. 707 A cache MUST NOT return a stale response if it is prohibited by an 708 explicit in-protocol directive (e.g., by a "no-store" or "no-cache" 709 cache directive, a "must-revalidate" cache-response-directive, or an 710 applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 711 see Section 3.2.2). 713 A cache MUST NOT return stale responses unless it is disconnected 714 (i.e., it cannot contact the origin server or otherwise find a 715 forward path) or doing so is explicitly allowed (e.g., by the max- 716 stale request directive; see Section 3.2.1). 718 A cache SHOULD append a Warning header field with the 110 warn-code 719 (see Section 3.6) to stale responses. Likewise, a cache SHOULD add 720 the 112 warn-code to stale responses if the cache is disconnected. 722 If a cache receives a first-hand response (either an entire response, 723 or a 304 (Not Modified) response) that it would normally forward to 724 the requesting client, and the received response is no longer fresh, 725 the cache can forward it to the requesting client without adding a 726 new Warning (but without removing any existing Warning header 727 fields). A cache shouldn't attempt to validate a response simply 728 because that response became stale in transit. 730 2.4. Validation Model 732 When a cache has one or more stored responses for a requested URI, 733 but cannot serve any of them (e.g., because they are not fresh, or 734 one cannot be selected; see Section 2.7), it can use the conditional 735 request mechanism [Part4] in the forwarded request to give the origin 736 server an opportunity to both select a valid stored response to be 737 used, and to update it. This process is known as "validating" or 738 "revalidating" the stored response. 740 When sending such a conditional request, a cache adds an If-Modified- 741 Since header field whose value is that of the Last-Modified header 742 field from the selected (see Section 2.7) stored response, if 743 available. 745 Additionally, a cache can add an If-None-Match header field whose 746 value is that of the ETag header field(s) from all responses stored 747 for the requested URI, if present. However, if any of the stored 748 responses contains only partial content, the cache shouldn't include 749 its entity-tag in the If-None-Match header field unless the request 750 is for a range that would be fully satisfied by that stored response. 752 Cache handling of a response to a conditional request is dependent 753 upon its status code: 755 o A 304 (Not Modified) response status code indicates that the 756 stored response can be updated and reused; see Section 2.4.1. 758 o A full response (i.e., one with a response body) indicates that 759 none of the stored responses nominated in the conditional request 760 is suitable. Instead, the cache can use the full response to 761 satisfy the request and MAY replace the stored response(s). 763 o However, if a cache receives a 5xx response while attempting to 764 validate a response, it can either forward this response to the 765 requesting client, or act as if the server failed to respond. In 766 the latter case, it can return a previously stored response (see 767 Section 2.3.3). 769 2.4.1. Freshening Responses 771 When a cache receives a 304 (Not Modified) response and already has 772 one or more stored 200 (OK) responses for the same cache key, the 773 cache needs to identify which of the stored responses are updated by 774 this new response and then update the stored response(s) with the new 775 information provided in the 304 response. 777 o If the new response contains a strong validator, then that strong 778 validator identifies the selected representation. All of the 779 stored responses with the same strong validator are selected. If 780 none of the stored responses contain the same strong validator, 781 then this new response corresponds to a new selected 782 representation and MUST NOT update the existing stored responses. 784 o If the new response contains a weak validator and that validator 785 corresponds to one of the cache's stored responses, then the most 786 recent of those matching stored responses is selected. 788 o If the new response does not include any form of validator, there 789 is only one stored response, and that stored response also lacks a 790 validator, then that stored response is selected. 792 If a stored response is selected for update, the cache MUST: 794 o delete any Warning header fields in the stored response with warn- 795 code 1xx (see Section 3.6); 797 o retain any Warning header fields in the stored response with warn- 798 code 2xx; and, 800 o use other header fields provided in the 304 response to replace 801 all instances of the corresponding header fields in the stored 802 response. 804 2.5. Request Methods that Invalidate 806 Because unsafe request methods (Section 6.1.1 of [Part2]) such as 807 PUT, POST or DELETE have the potential for changing state on the 808 origin server, intervening caches can use them to keep their contents 809 up-to-date. 811 A cache MUST invalidate the effective Request URI (Section 4.3 of 812 [Part1]) as well as the URI(s) in the Location and Content-Location 813 header fields (if present) when a non-error response to a request 814 with an unsafe method is received. 816 However, a cache MUST NOT invalidate a URI from a Location or 817 Content-Location header field if the host part of that URI differs 818 from the host part in the effective request URI (Section 4.3 of 819 [Part1]). This helps prevent denial of service attacks. 821 A cache MUST invalidate the effective request URI (Section 4.3 of 822 [Part1]) when it receives a non-error response to a request with a 823 method whose safety is unknown. 825 Here, a "non-error response" is one with a 2xx or 3xx status code. 826 "Invalidate" means that the cache will either remove all stored 827 responses related to the effective request URI, or will mark these as 828 "invalid" and in need of a mandatory validation before they can be 829 returned in response to a subsequent request. 831 Note that this does not guarantee that all appropriate responses are 832 invalidated. For example, the request that caused the change at the 833 origin server might not have gone through the cache where a response 834 is stored. 836 2.6. Shared Caching of Authenticated Responses 838 A shared cache MUST NOT use a cached response to a request with an 839 Authorization header field (Section 4.1 of [Part7]) to satisfy any 840 subsequent request unless a cache directive that allows such 841 responses to be stored is present in the response. 843 In this specification, the following Cache-Control response 844 directives (Section 3.2.2) have such an effect: must-revalidate, 845 public, s-maxage. 847 Note that cached responses that contain the "must-revalidate" and/or 848 "s-maxage" response directives are not allowed to be served stale 849 (Section 2.3.3) by shared caches. In particular, a response with 850 either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to 851 satisfy a subsequent request without revalidating it on the origin 852 server. 854 2.7. Caching Negotiated Responses 856 When a cache receives a request that can be satisfied by a stored 857 response that has a Vary header field (Section 3.5), it MUST NOT use 858 that response unless all of the selecting header fields nominated by 859 the Vary header field match in both the original request (i.e., that 860 associated with the stored response), and the presented request. 862 The selecting header fields from two requests are defined to match if 863 and only if those in the first request can be transformed to those in 864 the second request by applying any of the following: 866 o adding or removing whitespace, where allowed in the header field's 867 syntax 869 o combining multiple header fields with the same field name (see 870 Section 3.2 of [Part1]) 872 o normalizing both header field values in a way that is known to 873 have identical semantics, according to the header field's 874 specification (e.g., re-ordering field values when order is not 875 significant; case-normalization, where values are defined to be 876 case-insensitive) 878 If (after any normalization that might take place) a header field is 879 absent from a request, it can only match another request if it is 880 also absent there. 882 A Vary header field-value of "*" always fails to match, and 883 subsequent requests to that resource can only be properly interpreted 884 by the origin server. 886 The stored response with matching selecting header fields is known as 887 the selected response. 889 If multiple selected responses are available, the most recent 890 response (as determined by the Date header field) is used; see 891 Section 2.2. 893 If no selected response is available, the cache can forward the 894 presented request to the origin server in a conditional request; see 895 Section 2.4. 897 2.8. Combining Partial Content 899 A response might transfer only a partial representation if the 900 connection closed prematurely or if the request used one or more 901 Range specifiers ([Part5]). After several such transfers, a cache 902 might have received several ranges of the same representation. A 903 cache MAY combine these ranges into a single stored response, and 904 reuse that response to satisfy later requests, if they all share the 905 same strong validator and the cache complies with the client 906 requirements in Section 4 of [Part5]. 908 When combining the new response with one or more stored responses, a 909 cache MUST: 911 o delete any Warning header fields in the stored response with warn- 912 code 1xx (see Section 3.6); 914 o retain any Warning header fields in the stored response with warn- 915 code 2xx; and, 917 o use other header fields provided in the new response, aside from 918 Content-Range, to replace all instances of the corresponding 919 header fields in the stored response. 921 3. Header Field Definitions 923 This section defines the syntax and semantics of HTTP/1.1 header 924 fields related to caching. 926 3.1. Age 928 The "Age" header field conveys the sender's estimate of the amount of 929 time since the response was generated or successfully validated at 930 the origin server. Age values are calculated as specified in 931 Section 2.3.2. 933 Age = delta-seconds 935 Age field-values are non-negative integers, representing time in 936 seconds (see Section 1.5). 938 The presence of an Age header field in a response implies that a 939 response is not first-hand. However, the converse is not true, since 940 HTTP/1.0 caches might not implement the Age header field. 942 3.2. Cache-Control 944 The "Cache-Control" header field is used to specify directives for 945 caches along the request/response chain. Such cache directives are 946 unidirectional in that the presence of a directive in a request does 947 not imply that the same directive is to be given in the response. 949 A cache MUST obey the requirements of the Cache-Control directives 950 defined in this section. See Section 3.2.3 for information about how 951 Cache-Control directives defined elsewhere are handled. 953 Note: HTTP/1.0 caches might not implement Cache-Control and might 954 only implement Pragma: no-cache (see Section 3.4). 956 A proxy, whether or not it implements a cache, MUST pass cache 957 directives through in forwarded messages, regardless of their 958 significance to that application, since the directives might be 959 applicable to all recipients along the request/response chain. It is 960 not possible to target a directive to a specific cache. 962 Cache directives are identified by a token, to be compared case- 963 insensitively, and have an optional argument. 965 Cache-Control = 1#cache-directive 967 cache-directive = cache-request-directive 968 / cache-response-directive 970 cache-extension = token [ "=" ( token / quoted-string ) ] 972 3.2.1. Request Cache-Control Directives 974 cache-request-directive = 975 "no-cache" 976 / "no-store" 977 / "max-age" "=" delta-seconds 978 / "max-stale" [ "=" delta-seconds ] 979 / "min-fresh" "=" delta-seconds 980 / "no-transform" 981 / "only-if-cached" 982 / cache-extension 984 no-cache 986 The no-cache request directive indicates that a cache MUST NOT use 987 a stored response to satisfy the request without successful 988 validation on the origin server. 990 no-store 992 The no-store request directive indicates that a cache MUST NOT 993 store any part of either this request or any response to it. This 994 directive applies to both private and shared caches. "MUST NOT 995 store" in this context means that the cache MUST NOT intentionally 996 store the information in non-volatile storage, and MUST make a 997 best-effort attempt to remove the information from volatile 998 storage as promptly as possible after forwarding it. 1000 This directive is NOT a reliable or sufficient mechanism for 1001 ensuring privacy. In particular, malicious or compromised caches 1002 might not recognize or obey this directive, and communications 1003 networks might be vulnerable to eavesdropping. 1005 Note that if a request containing this directive is satisfied from 1006 a cache, the no-store request directive does not apply to the 1007 already stored response. 1009 max-age 1011 The max-age request directive indicates that the client is 1012 unwilling to accept a response whose age is greater than the 1013 specified number of seconds. Unless the max-stale request 1014 directive is also present, the client is not willing to accept a 1015 stale response. 1017 max-stale 1019 The max-stale request directive indicates that the client is 1020 willing to accept a response that has exceeded its expiration 1021 time. If max-stale is assigned a value, then the client is 1022 willing to accept a response that has exceeded its expiration time 1023 by no more than the specified number of seconds. If no value is 1024 assigned to max-stale, then the client is willing to accept a 1025 stale response of any age. 1027 min-fresh 1029 The min-fresh request directive indicates that the client is 1030 willing to accept a response whose freshness lifetime is no less 1031 than its current age plus the specified time in seconds. That is, 1032 the client wants a response that will still be fresh for at least 1033 the specified number of seconds. 1035 no-transform 1037 The no-transform request directive indicates that an intermediary 1038 (whether or not it implements a cache) MUST NOT change the 1039 Content-Encoding, Content-Range or Content-Type request header 1040 fields, nor the request representation. 1042 only-if-cached 1044 The only-if-cached request directive indicates that the client 1045 only wishes to obtain a stored response. If it receives this 1046 directive, a cache SHOULD either respond using a stored response 1047 that is consistent with the other constraints of the request, or 1048 respond with a 504 (Gateway Timeout) status code. If a group of 1049 caches is being operated as a unified system with good internal 1050 connectivity, a member cache MAY forward such a request within 1051 that group of caches. 1053 3.2.2. Response Cache-Control Directives 1055 cache-response-directive = 1056 "public" 1057 / "private" [ "=" DQUOTE 1#field-name DQUOTE ] 1058 / "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] 1059 / "no-store" 1060 / "no-transform" 1061 / "must-revalidate" 1062 / "proxy-revalidate" 1063 / "max-age" "=" delta-seconds 1064 / "s-maxage" "=" delta-seconds 1065 / cache-extension 1067 public 1069 The public response directive indicates that a response whose 1070 associated request contains an 'Authentication' header MAY be 1071 stored (see Section 2.6). 1073 private 1075 The private response directive indicates that the response message 1076 is intended for a single user and MUST NOT be stored by a shared 1077 cache. A private cache MAY store the response. 1079 If the private response directive specifies one or more field- 1080 names, this requirement is limited to the field-values associated 1081 with the listed response header fields. That is, a shared cache 1082 MUST NOT store the specified field-names(s), whereas it MAY store 1083 the remainder of the response message. 1085 Note: This usage of the word private only controls where the 1086 response can be stored; it cannot ensure the privacy of the 1087 message content. Also, private response directives with field- 1088 names are often handled by implementations as if an unqualified 1089 private directive was received; i.e., the special handling for the 1090 qualified form is not widely implemented. 1092 no-cache 1094 The no-cache response directive indicates that the response MUST 1095 NOT be used to satisfy a subsequent request without successful 1096 validation on the origin server. This allows an origin server to 1097 prevent a cache from using it to satisfy a request without 1098 contacting it, even by caches that have been configured to return 1099 stale responses. 1101 If the no-cache response directive specifies one or more field- 1102 names, this requirement is limited to the field-values associated 1103 with the listed response header fields. That is, a cache MUST NOT 1104 send the specified field-name(s) in the response to a subsequent 1105 request without successful validation on the origin server. This 1106 allows an origin server to prevent the re-use of certain header 1107 fields in a response, while still allowing caching of the rest of 1108 the response. 1110 Note: Most HTTP/1.0 caches will not recognize or obey this 1111 directive. Also, no-cache response directives with field-names 1112 are often handled by implementations as if an unqualified no-cache 1113 directive was received; i.e., the special handling for the 1114 qualified form is not widely implemented. 1116 no-store 1118 The no-store response directive indicates that a cache MUST NOT 1119 store any part of either the immediate request or response. This 1120 directive applies to both private and shared caches. "MUST NOT 1121 store" in this context means that the cache MUST NOT intentionally 1122 store the information in non-volatile storage, and MUST make a 1123 best-effort attempt to remove the information from volatile 1124 storage as promptly as possible after forwarding it. 1126 This directive is NOT a reliable or sufficient mechanism for 1127 ensuring privacy. In particular, malicious or compromised caches 1128 might not recognize or obey this directive, and communications 1129 networks might be vulnerable to eavesdropping. 1131 must-revalidate 1133 The must-revalidate response directive indicates that once it has 1134 become stale, a cache MUST NOT use the response to satisfy 1135 subsequent requests without successful validation on the origin 1136 server. 1138 The must-revalidate directive is necessary to support reliable 1139 operation for certain protocol features. In all circumstances a 1140 cache MUST obey the must-revalidate directive; in particular, if a 1141 cache cannot reach the origin server for any reason, it MUST 1142 generate a 504 (Gateway Timeout) response. 1144 The must-revalidate directive ought to be used by servers if and 1145 only if failure to validate a request on the representation could 1146 result in incorrect operation, such as a silently unexecuted 1147 financial transaction. 1149 proxy-revalidate 1151 The proxy-revalidate response directive has the same meaning as 1152 the must-revalidate response directive, except that it does not 1153 apply to private caches. 1155 max-age 1157 The max-age response directive indicates that the response is to 1158 be considered stale after its age is greater than the specified 1159 number of seconds. 1161 s-maxage 1163 The s-maxage response directive indicates that, in shared caches, 1164 the maximum age specified by this directive overrides the maximum 1165 age specified by either the max-age directive or the Expires 1166 header field. The s-maxage directive also implies the semantics 1167 of the proxy-revalidate response directive. 1169 no-transform 1171 The no-transform response directive indicates that an intermediary 1172 (regardless of whether it implements a cache) MUST NOT change the 1173 Content-Encoding, Content-Range or Content-Type response header 1174 fields, nor the response representation. 1176 3.2.3. Cache Control Extensions 1178 The Cache-Control header field can be extended through the use of one 1179 or more cache-extension tokens, each with an optional value. 1180 Informational extensions (those that do not require a change in cache 1181 behavior) can be added without changing the semantics of other 1182 directives. Behavioral extensions are designed to work by acting as 1183 modifiers to the existing base of cache directives. Both the new 1184 directive and the standard directive are supplied, such that 1185 applications that do not understand the new directive will default to 1186 the behavior specified by the standard directive, and those that 1187 understand the new directive will recognize it as modifying the 1188 requirements associated with the standard directive. In this way, 1189 extensions to the cache-control directives can be made without 1190 requiring changes to the base protocol. 1192 This extension mechanism depends on an HTTP cache obeying all of the 1193 cache-control directives defined for its native HTTP-version, obeying 1194 certain extensions, and ignoring all directives that it does not 1195 understand. 1197 For example, consider a hypothetical new response directive called 1198 "community" that acts as a modifier to the private directive. We 1199 define this new directive to mean that, in addition to any private 1200 cache, any cache that is shared only by members of the community 1201 named within its value may cache the response. An origin server 1202 wishing to allow the UCI community to use an otherwise private 1203 response in their shared cache(s) could do so by including 1205 Cache-Control: private, community="UCI" 1207 A cache seeing this header field will act correctly even if the cache 1208 does not understand the community cache-extension, since it will also 1209 see and understand the private directive and thus default to the safe 1210 behavior. 1212 A cache MUST ignore unrecognized cache directives; it is assumed that 1213 any cache directive likely to be unrecognized by an HTTP/1.1 cache 1214 will be combined with standard directives (or the response's default 1215 cacheability) such that the cache behavior will remain minimally 1216 correct even if the cache does not understand the extension(s). 1218 The HTTP Cache Directive Registry defines the name space for the 1219 cache directives. 1221 A registration MUST include the following fields: 1223 o Cache Directive Name 1225 o Pointer to specification text 1227 Values to be added to this name space are subject to IETF review 1228 ([RFC5226], Section 4.1). 1230 The registry itself is maintained at 1231 . 1233 3.3. Expires 1235 The "Expires" header field gives the date/time after which the 1236 response is considered stale. See Section 2.3 for further discussion 1237 of the freshness model. 1239 The presence of an Expires field does not imply that the original 1240 resource will change or cease to exist at, before, or after that 1241 time. 1243 The field-value is an absolute date and time as defined by HTTP-date 1244 in Section 8 of [Part2]; a sender MUST use the rfc1123-date format. 1246 Expires = HTTP-date 1248 For example 1250 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1252 A cache MUST treat other invalid date formats, especially including 1253 the value "0", as in the past (i.e., "already expired"). 1255 Note: If a response includes a Cache-Control field with the max- 1256 age directive (see Section 3.2.2), that directive overrides the 1257 Expires field. Likewise, the s-maxage directive overrides Expires 1258 in shared caches. 1260 Historically, HTTP required the Expires field-value to be no more 1261 than a year in the future. While longer freshness lifetimes are no 1262 longer prohibited, extremely large values have been demonstrated to 1263 cause problems (e.g., clock overflows due to use of 32-bit integers 1264 for time values), and most caches will evict a response far sooner 1265 than that. Therefore, senders ought not produce them. 1267 An origin server without a clock MUST NOT assign Expires values to a 1268 response unless these values were associated with the resource by a 1269 system or user with a reliable clock. It MAY assign an Expires value 1270 that is known, at or before server configuration time, to be in the 1271 past (this allows "pre-expiration" of responses without storing 1272 separate Expires values for each resource). 1274 3.4. Pragma 1276 The "Pragma" header field allows backwards compatibility with 1277 HTTP/1.0 caches, so that clients can specify a "no-cache" request 1278 that they will understand (as Cache-Control was not defined until 1279 HTTP/1.1). When the Cache-Control header is also present and 1280 understood in a request, Pragma is ignored. 1282 In HTTP/1.0, Pragma was defined as an extensible field for 1283 implementation-specified directives for recipients. This 1284 specification deprecates such extensions to improve interoperability. 1286 Pragma = 1#pragma-directive 1287 pragma-directive = "no-cache" / extension-pragma 1288 extension-pragma = token [ "=" ( token / quoted-string ) ] 1290 When the Cache-Control header is not present in a request, the no- 1291 cache request pragma-directive MUST have the same effect on caches as 1292 if "Cache-Control: no-cache" were present (see Section 3.2.1). 1294 When sending a no-cache request, a client ought to include both the 1295 pragma and cache-control directives, unless Cache-Control: no-cache 1296 is purposefully omitted to target other Cache-Control response 1297 directives at HTTP/1.1 caches. For example: 1299 GET / HTTP/1.1 1300 Host: www.example.com 1301 Cache-Control: max-age=30 1302 Pragma: no-cache 1304 will constrain HTTP/1.1 caches to serve a response no older than 30 1305 seconds, while precluding implementations that do not understand 1306 Cache-Control from serving a cached response. 1308 Note: Because the meaning of "Pragma: no-cache" in responses is 1309 not specified, it does not provide a reliable replacement for 1310 "Cache-Control: no-cache" in them. 1312 3.5. Vary 1314 The "Vary" header field conveys the set of header fields that were 1315 used to select the representation. 1317 Caches use this information, in part, to determine whether a stored 1318 response can be used to satisfy a given request; see Section 2.7. 1319 determines, while the response is fresh, whether a cache is permitted 1320 to use the response to reply to a subsequent request without 1321 validation; see Section 2.7. 1323 In uncacheable or stale responses, the Vary field value advises the 1324 user agent about the criteria that were used to select the 1325 representation. 1327 Vary = "*" / 1#field-name 1329 The set of header fields named by the Vary field value is known as 1330 the selecting header fields. 1332 A server SHOULD include a Vary header field with any cacheable 1333 response that is subject to server-driven negotiation. Doing so 1334 allows a cache to properly interpret future requests on that resource 1335 and informs the user agent about the presence of negotiation on that 1336 resource. A server MAY include a Vary header field with a non- 1337 cacheable response that is subject to server-driven negotiation, 1338 since this might provide the user agent with useful information about 1339 the dimensions over which the response varies at the time of the 1340 response. 1342 A Vary field value of "*" signals that unspecified parameters not 1343 limited to the header fields (e.g., the network address of the 1344 client), play a role in the selection of the response representation; 1345 therefore, a cache cannot determine whether this response is 1346 appropriate. A proxy MUST NOT generate the "*" value. 1348 The field-names given are not limited to the set of standard header 1349 fields defined by this specification. Field names are case- 1350 insensitive. 1352 3.6. Warning 1354 The "Warning" header field is used to carry additional information 1355 about the status or transformation of a message that might not be 1356 reflected in the message. This information is typically used to warn 1357 about possible incorrectness introduced by caching operations or 1358 transformations applied to the payload of the message. 1360 Warnings can be used for other purposes, both cache-related and 1361 otherwise. The use of a warning, rather than an error status code, 1362 distinguishes these responses from true failures. 1364 Warning header fields can in general be applied to any message, 1365 however some warn-codes are specific to caches and can only be 1366 applied to response messages. 1368 Warning = 1#warning-value 1370 warning-value = warn-code SP warn-agent SP warn-text 1371 [SP warn-date] 1373 warn-code = 3DIGIT 1374 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1375 ; the name or pseudonym of the server adding 1376 ; the Warning header field, for use in debugging 1377 warn-text = quoted-string 1378 warn-date = DQUOTE HTTP-date DQUOTE 1380 Multiple warnings can be attached to a response (either by the origin 1381 server or by a cache), including multiple warnings with the same code 1382 number, only differing in warn-text. 1384 When this occurs, the user agent SHOULD inform the user of as many of 1385 them as possible, in the order that they appear in the response. 1387 Systems that generate multiple Warning header fields are encouraged 1388 to order them with this user agent behavior in mind. New Warning 1389 header fields are added after any existing Warning headers fields. 1391 Warnings are assigned three digit warn-codes. The first digit 1392 indicates whether the Warning is required to be deleted from a stored 1393 response after validation: 1395 o 1xx Warnings describe the freshness or validation status of the 1396 response, and so MUST be deleted by a cache after validation. 1397 They can only be generated by a cache when validating a cached 1398 entry, and MUST NOT be generated in any other situation. 1400 o 2xx Warnings describe some aspect of the representation that is 1401 not rectified by a validation (for example, a lossy compression of 1402 the representation) and MUST NOT be deleted by a cache after 1403 validation, unless a full response is returned, in which case they 1404 MUST be. 1406 If an implementation sends a message with one or more Warning header 1407 fields to a receiver whose version is HTTP/1.0 or lower, then the 1408 sender MUST include in each warning-value a warn-date that matches 1409 the Date header field in the message. 1411 If a system receives a message with a warning-value that includes a 1412 warn-date, and that warn-date is different from the Date value in the 1413 response, then that warning-value MUST be deleted from the message 1414 before storing, forwarding, or using it. (preventing the consequences 1415 of naive caching of Warning header fields.) If all of the warning- 1416 values are deleted for this reason, the Warning header field MUST be 1417 deleted as well. 1419 The following warn-codes are defined by this specification, each with 1420 a recommended warn-text in English, and a description of its meaning. 1422 3.6.1. 110 Response is Stale 1424 A cache SHOULD include this whenever the returned response is stale. 1426 3.6.2. 111 Revalidation Failed 1428 A cache SHOULD include this when returning a stale response because 1429 an attempt to validate the response failed, due to an inability to 1430 reach the server. 1432 3.6.3. 112 Disconnected Operation 1434 A cache SHOULD include this if it is intentionally disconnected from 1435 the rest of the network for a period of time. 1437 3.6.4. 113 Heuristic Expiration 1439 A cache SHOULD include this if it heuristically chose a freshness 1440 lifetime greater than 24 hours and the response's age is greater than 1441 24 hours. 1443 3.6.5. 199 Miscellaneous Warning 1445 The warning text can include arbitrary information to be presented to 1446 a human user, or logged. A system receiving this warning MUST NOT 1447 take any automated action, besides presenting the warning to the 1448 user. 1450 3.6.6. 214 Transformation Applied 1452 MUST be added by a proxy if it applies any transformation to the 1453 representation, such as changing the content-coding, media-type, or 1454 modifying the representation data, unless this Warning code already 1455 appears in the response. 1457 3.6.7. 299 Miscellaneous Persistent 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. 1463 3.6.8. Warn Code Extensions 1465 The HTTP Warn Code Registry defines the name space for warn codes. 1467 A registration MUST include the following fields: 1469 o Warn Code (3 digits) 1471 o Short Description 1473 o Pointer to specification text 1475 Values to be added to this name space are subject to IETF review 1476 ([RFC5226], Section 4.1). 1478 The registry itself is maintained at 1479 . 1481 3.7. History Lists 1483 User agents often have history mechanisms, such as "Back" buttons and 1484 history lists, that can be used to redisplay a representation 1485 retrieved earlier in a session. 1487 The freshness model (Section 2.3) does not necessarily apply to 1488 history mechanisms. I.e., a history mechanism can display a previous 1489 representation even if it has expired. 1491 This does not prohibit the history mechanism from telling the user 1492 that a view might be stale, or from honoring cache directives (e.g., 1493 Cache-Control: no-store). 1495 3.8. IANA Considerations 1497 3.8.1. Cache Directive Registry 1499 The registration procedure for HTTP Cache Directives is defined by 1500 Section 3.2.3 of this document. 1502 The HTTP Cache Directive Registry shall be created at 1503 and be 1504 populated with the registrations below: 1506 +------------------------+------------------------------+ 1507 | Cache Directive | Reference | 1508 +------------------------+------------------------------+ 1509 | max-age | Section 3.2.1, Section 3.2.2 | 1510 | max-stale | Section 3.2.1 | 1511 | min-fresh | Section 3.2.1 | 1512 | must-revalidate | Section 3.2.2 | 1513 | no-cache | Section 3.2.1, Section 3.2.2 | 1514 | no-store | Section 3.2.1, Section 3.2.2 | 1515 | no-transform | Section 3.2.1, Section 3.2.2 | 1516 | only-if-cached | Section 3.2.1 | 1517 | private | Section 3.2.2 | 1518 | proxy-revalidate | Section 3.2.2 | 1519 | public | Section 3.2.2 | 1520 | s-maxage | Section 3.2.2 | 1521 | stale-if-error | [RFC5861], Section 4 | 1522 | stale-while-revalidate | [RFC5861], Section 3 | 1523 +------------------------+------------------------------+ 1525 3.8.2. Warn Code Registry 1527 The registration procedure for HTTP Warn Codes is defined by 1528 Section 3.6.8 of this document. 1530 The HTTP Warn Code Registry shall be created at 1531 and be 1532 populated with the registrations below: 1534 +-----------+----------------------------------+---------------+ 1535 | Warn Code | Short Description | Reference | 1536 +-----------+----------------------------------+---------------+ 1537 | 110 | Response is Stale | Section 3.6.1 | 1538 | 111 | Revalidation Failed | Section 3.6.2 | 1539 | 112 | Disconnected Operation | Section 3.6.3 | 1540 | 113 | Heuristic Expiration | Section 3.6.4 | 1541 | 199 | Miscellaneous Warning | Section 3.6.5 | 1542 | 214 | Transformation Applied | Section 3.6.6 | 1543 | 299 | Miscellaneous Persistent Warning | Section 3.6.7 | 1544 +-----------+----------------------------------+---------------+ 1546 3.9. Header Field Registration 1548 The Message Header Field Registry located at shall be 1550 updated with the permanent registrations below (see [RFC3864]): 1552 +-------------------+----------+----------+-------------+ 1553 | Header Field Name | Protocol | Status | Reference | 1554 +-------------------+----------+----------+-------------+ 1555 | Age | http | standard | Section 3.1 | 1556 | Cache-Control | http | standard | Section 3.2 | 1557 | Expires | http | standard | Section 3.3 | 1558 | Pragma | http | standard | Section 3.4 | 1559 | Vary | http | standard | Section 3.5 | 1560 | Warning | http | standard | Section 3.6 | 1561 +-------------------+----------+----------+-------------+ 1563 The change controller is: "IETF (iesg@ietf.org) - Internet 1564 Engineering Task Force". 1566 4. Security Considerations 1568 Caches expose additional potential vulnerabilities, since the 1569 contents of the cache represent an attractive target for malicious 1570 exploitation. Because cache contents persist after an HTTP request 1571 is complete, an attack on the cache can reveal information long after 1572 a user believes that the information has been removed from the 1573 network. Therefore, cache contents need to be protected as sensitive 1574 information. 1576 5. Acknowledgments 1578 See Section 11 of [Part1]. 1580 6. References 1582 6.1. Normative References 1584 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1585 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1586 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 1587 and Message Parsing", draft-ietf-httpbis-p1-messaging-18 1588 (work in progress), January 2012. 1590 [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1591 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1592 and J. Reschke, Ed., "HTTP/1.1, part 2: Message 1593 Semantics", draft-ietf-httpbis-p2-semantics-18 (work in 1594 progress), January 2012. 1596 [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1597 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1598 and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional 1599 Requests", draft-ietf-httpbis-p4-conditional-18 (work in 1600 progress), January 2012. 1602 [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1603 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1604 and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and 1605 Partial Responses", draft-ietf-httpbis-p5-range-18 (work 1606 in progress), January 2012. 1608 [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 1609 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 1610 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", 1611 draft-ietf-httpbis-p7-auth-18 (work in progress), 1612 January 2012. 1614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1615 Requirement Levels", BCP 14, RFC 2119, March 1997. 1617 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1618 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1620 6.2. Informative References 1622 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1623 Specification, Implementation", RFC 1305, March 1992. 1625 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1626 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1627 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1629 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1630 Procedures for Message Header Fields", BCP 90, RFC 3864, 1631 September 2004. 1633 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1634 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1635 May 2008. 1637 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1638 Content", RFC 5861, April 2010. 1640 Appendix A. Changes from RFC 2616 1642 Make the specified age calculation algorithm less conservative. 1643 (Section 2.3.2) 1645 Remove requirement to consider Content-Location in successful 1646 responses in order to determine the appropriate response to use. 1647 (Section 2.4) 1648 Clarify denial of service attack avoidance requirement. 1649 (Section 2.5) 1651 Change ABNF productions for header fields to only define the field 1652 value. (Section 3) 1654 Do not mention RFC 2047 encoding and multiple languages in Warning 1655 header fields anymore, as these aspects never were implemented. 1656 (Section 3.6) 1658 Appendix B. Collected ABNF 1660 Age = delta-seconds 1662 Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS 1663 cache-directive ] ) 1665 Expires = HTTP-date 1667 HTTP-date = 1669 OWS = 1671 Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS 1672 pragma-directive ] ) 1674 Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] 1675 ) ) 1677 Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] 1678 ) 1680 cache-directive = cache-request-directive / cache-response-directive 1681 cache-extension = token [ "=" ( token / quoted-string ) ] 1682 cache-request-directive = "no-cache" / "no-store" / ( "max-age=" 1683 delta-seconds ) / ( "max-stale" [ "=" delta-seconds ] ) / ( 1684 "min-fresh=" delta-seconds ) / "no-transform" / "only-if-cached" / 1685 cache-extension 1686 cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( "," 1687 OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( 1688 "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS 1689 field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / 1690 "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds 1691 ) / ( "s-maxage=" delta-seconds ) / cache-extension 1693 delta-seconds = 1*DIGIT 1695 extension-pragma = token [ "=" ( token / quoted-string ) ] 1696 field-name = 1698 port = 1699 pragma-directive = "no-cache" / extension-pragma 1700 pseudonym = 1702 quoted-string = 1704 token = 1706 uri-host = 1708 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1709 warn-code = 3DIGIT 1710 warn-date = DQUOTE HTTP-date DQUOTE 1711 warn-text = quoted-string 1712 warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date 1713 ] 1715 ABNF diagnostics: 1717 ; Age defined but not used 1718 ; Cache-Control defined but not used 1719 ; Expires defined but not used 1720 ; Pragma defined but not used 1721 ; Vary defined but not used 1722 ; Warning defined but not used 1724 Appendix C. Change Log (to be removed by RFC Editor before publication) 1726 C.1. Since RFC 2616 1728 Extracted relevant partitions from [RFC2616]. 1730 C.2. Since draft-ietf-httpbis-p6-cache-00 1732 Closed issues: 1734 o : "Trailer" 1735 () 1737 o : "Invalidation 1738 after Update or Delete" 1739 () 1741 o : "Normative and 1742 Informative references" 1744 o : "Date reference 1745 typo" 1747 o : "Connection 1748 header text" 1750 o : "Informative 1751 references" 1753 o : "ISO-8859-1 1754 Reference" 1756 o : "Normative up- 1757 to-date references" 1759 o : "typo in 1760 13.2.2" 1762 Other changes: 1764 o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress 1765 on ) 1767 C.3. Since draft-ietf-httpbis-p6-cache-01 1769 Closed issues: 1771 o : "rel_path not 1772 used" 1774 Other changes: 1776 o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work 1777 in progress on ) 1779 o Add explicit references to BNF syntax and rules imported from 1780 other parts of the specification. 1782 C.4. Since draft-ietf-httpbis-p6-cache-02 1784 Ongoing work on IANA Message Header Field Registration 1785 (): 1787 o Reference RFC 3984, and update header field registrations for 1788 header fields defined in this document. 1790 C.5. Since draft-ietf-httpbis-p6-cache-03 1792 Closed issues: 1794 o : "Vary header 1795 classification" 1797 C.6. Since draft-ietf-httpbis-p6-cache-04 1799 Ongoing work on ABNF conversion 1800 (): 1802 o Use "/" instead of "|" for alternatives. 1804 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 1805 whitespace ("OWS") and required whitespace ("RWS"). 1807 o Rewrite ABNFs to spell out whitespace rules, factor out header 1808 field value format definitions. 1810 C.7. Since draft-ietf-httpbis-p6-cache-05 1812 This is a total rewrite of this part of the specification. 1814 Affected issues: 1816 o : "Definition of 1817 1xx Warn-Codes" 1819 o : "Placement of 1820 13.5.1 and 13.5.2" 1822 o : "The role of 1823 Warning and Semantic Transparency in Caching" 1825 o : "Methods and 1826 Caching" 1828 In addition: Final work on ABNF conversion 1829 (): 1831 o Add appendix containing collected and expanded ABNF, reorganize 1832 ABNF introduction. 1834 C.8. Since draft-ietf-httpbis-p6-cache-06 1836 Closed issues: 1838 o : "base for 1839 numeric protocol elements" 1841 Affected issues: 1843 o : "Vary and non- 1844 existant headers" 1846 C.9. Since draft-ietf-httpbis-p6-cache-07 1848 Closed issues: 1850 o : "Definition of 1851 1xx Warn-Codes" 1853 o : "Content- 1854 Location on 304 responses" 1856 o : "private and 1857 no-cache CC directives with headers" 1859 o : "RFC2047 and 1860 warn-text" 1862 C.10. Since draft-ietf-httpbis-p6-cache-08 1864 Closed issues: 1866 o : "serving 1867 negotiated responses from cache: header-specific canonicalization" 1869 o : "Effect of CC 1870 directives on history lists" 1872 o : "Cache 1873 Extensions can override no-store, etc." 1875 Affected issues: 1877 o : Status codes 1878 and caching 1880 Partly resolved issues: 1882 o : "Placement of 1883 13.5.1 and 13.5.2" 1885 C.11. Since draft-ietf-httpbis-p6-cache-09 1887 Closed issues: 1889 o : "Age 1890 calculation" 1892 o : "Clarify 1893 differences between / requirements for request and response CC 1894 directives" 1896 o : "Caching 1897 authenticated responses" 1899 o : "IANA registry 1900 for cache-control directives" 1902 o : "Heuristic 1903 caching of URLs with query components" 1905 Partly resolved issues: 1907 o : "Term for the 1908 requested resource's URI" 1910 C.12. Since draft-ietf-httpbis-p6-cache-10 1912 Closed issues: 1914 o : "Clarify 1915 entity / representation / variant terminology" 1917 o : "consider 1918 removing the 'changes from 2068' sections" 1920 o : "Allowing 1921 heuristic caching for new status codes" 1923 o Clean up TODOs and prose in "Combining Responses." 1925 C.13. Since draft-ietf-httpbis-p6-cache-11 1927 Closed issues: 1929 o : "Text about 1930 clock requirement for caches belongs in p6" 1932 C.14. Since draft-ietf-httpbis-p6-cache-12 1934 Closed issues: 1936 o : "Header 1937 Classification" 1939 o : "Clarify 1940 'public'" 1942 C.15. Since draft-ietf-httpbis-p6-cache-13 1944 Closed issues: 1946 o : "untangle 1947 ABNFs for header fields" 1949 C.16. Since draft-ietf-httpbis-p6-cache-14 1951 Closed issues: 1953 o : "Mismatch Vary" 1955 o : "Cache 1956 Invalidation only happens upon successful responses" 1958 o : "Recommend 1959 minimum sizes for protocol elements" 1961 o : "Proxies don't 1962 'understand' methods" 1964 o : "Cache 1965 Extensions can override no-store, etc." 1967 o : "Pragma" 1969 C.17. Since draft-ietf-httpbis-p6-cache-15 1971 Closed issues: 1973 o : "Motivate one- 1974 year limit for Expires" 1976 C.18. Since draft-ietf-httpbis-p6-cache-16 1978 Closed issues: 1980 o : "Document 1981 HTTP's error-handling philosophy" 1983 o : "Cache-Control 1984 directive case sensitivity" 1986 C.19. Since draft-ietf-httpbis-p6-cache-17 1988 Closed issues: 1990 o : "Interaction 1991 of request and response Cache-Control" 1993 o : "Refining age 1994 for 1.1 proxy chains" 1996 o : "warn-code 1997 registry" 1999 Index 2001 1 2002 110 Response is Stale (warn code) 31 2003 111 Revalidation Failed (warn code) 31 2004 112 Disconnected Operation (warn code) 31 2005 113 Heuristic Expiration (warn code) 31 2006 199 Miscellaneous Warning (warn code) 31 2008 2 2009 214 Transformation Applied (warn code) 31 2010 299 Miscellaneous Persistent Warning (warn code) 31 2012 A 2013 age 6 2014 Age header field 20 2016 C 2017 cache 5 2018 Cache Directives 2019 max-age 22, 25 2020 max-stale 22 2021 min-fresh 22 2022 must-revalidate 25 2023 no-cache 22, 24 2024 no-store 22, 24 2025 no-transform 23, 25 2026 only-if-cached 23 2027 private 23 2028 proxy-revalidate 25 2029 public 23 2030 s-maxage 25 2031 cache entry 8 2032 cache key 8 2033 Cache-Control header field 21 2034 cacheable 5 2036 E 2037 Expires header field 27 2038 explicit expiration time 6 2040 F 2041 first-hand 6 2042 fresh 6 2043 freshness lifetime 6 2045 G 2046 Grammar 2047 Age 20 2048 Cache-Control 21 2049 cache-extension 21 2050 cache-request-directive 21 2051 cache-response-directive 23 2052 delta-seconds 8 2053 Expires 27 2054 extension-pragma 28 2055 Pragma 28 2056 pragma-directive 28 2057 Vary 29 2058 warn-agent 30 2059 warn-code 30 2060 warn-date 30 2061 warn-text 30 2062 Warning 30 2063 warning-value 30 2065 H 2066 Header Fields 2067 Age 20 2068 Cache-Control 21 2069 Expires 27 2070 Pragma 28 2071 Vary 28 2072 Warning 29 2073 heuristic expiration time 6 2075 M 2076 max-age 2077 Cache Directive 22, 25 2078 max-stale 2079 Cache Directive 22 2080 min-fresh 2081 Cache Directive 22 2082 must-revalidate 2083 Cache Directive 25 2085 N 2086 no-cache 2087 Cache Directive 22, 24 2088 no-store 2089 Cache Directive 22, 24 2090 no-transform 2091 Cache Directive 23, 25 2093 O 2094 only-if-cached 2095 Cache Directive 23 2097 P 2098 Pragma header field 28 2099 private 2100 Cache Directive 23 2101 private cache 5 2102 proxy-revalidate 2103 Cache Directive 25 2104 public 2105 Cache Directive 23 2107 S 2108 s-maxage 2109 Cache Directive 25 2110 shared cache 5 2111 stale 6 2112 strong validator 7 2114 V 2115 validator 6 2116 strong 7 2117 Vary header field 28 2119 W 2120 Warn Codes 2121 110 Response is Stale 31 2122 111 Revalidation Failed 31 2123 112 Disconnected Operation 31 2124 113 Heuristic Expiration 31 2125 199 Miscellaneous Warning 31 2126 214 Transformation Applied 31 2127 299 Miscellaneous Persistent Warning 31 2128 Warning header field 29 2130 Authors' Addresses 2132 Roy T. Fielding (editor) 2133 Adobe Systems Incorporated 2134 345 Park Ave 2135 San Jose, CA 95110 2136 USA 2138 EMail: fielding@gbiv.com 2139 URI: http://roy.gbiv.com/ 2141 Jim Gettys 2142 Alcatel-Lucent Bell Labs 2143 21 Oak Knoll Road 2144 Carlisle, MA 01741 2145 USA 2147 EMail: jg@freedesktop.org 2148 URI: http://gettys.wordpress.com/ 2150 Jeffrey C. Mogul 2151 Hewlett-Packard Company 2152 HP Labs, Large Scale Systems Group 2153 1501 Page Mill Road, MS 1177 2154 Palo Alto, CA 94304 2155 USA 2157 EMail: JeffMogul@acm.org 2158 Henrik Frystyk Nielsen 2159 Microsoft Corporation 2160 1 Microsoft Way 2161 Redmond, WA 98052 2162 USA 2164 EMail: henrikn@microsoft.com 2166 Larry Masinter 2167 Adobe Systems Incorporated 2168 345 Park Ave 2169 San Jose, CA 95110 2170 USA 2172 EMail: LMM@acm.org 2173 URI: http://larry.masinter.net/ 2175 Paul J. Leach 2176 Microsoft Corporation 2177 1 Microsoft Way 2178 Redmond, WA 98052 2180 EMail: paulle@microsoft.com 2182 Tim Berners-Lee 2183 World Wide Web Consortium 2184 MIT Computer Science and Artificial Intelligence Laboratory 2185 The Stata Center, Building 32 2186 32 Vassar Street 2187 Cambridge, MA 02139 2188 USA 2190 EMail: timbl@w3.org 2191 URI: http://www.w3.org/People/Berners-Lee/ 2192 Yves Lafon (editor) 2193 World Wide Web Consortium 2194 W3C / ERCIM 2195 2004, rte des Lucioles 2196 Sophia-Antipolis, AM 06902 2197 France 2199 EMail: ylafon@w3.org 2200 URI: http://www.raubacapeu.net/people/yves/ 2202 Mark Nottingham (editor) 2203 Rackspace 2205 EMail: mnot@mnot.net 2206 URI: http://www.mnot.net/ 2208 Julian F. Reschke (editor) 2209 greenbytes GmbH 2210 Hafenweg 16 2211 Muenster, NW 48155 2212 Germany 2214 Phone: +49 251 2807760 2215 Fax: +49 251 2807761 2216 EMail: julian.reschke@greenbytes.de 2217 URI: http://greenbytes.de/tech/webdav/