idnits 2.17.00 (12 Aug 2021) /tmp/idnits28350/draft-ietf-httpbis-cache-01.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, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (May 31, 2018) is 1450 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) == Unused Reference: 'RFC3986' is defined on line 1688, but no explicit reference was found in the text == Unused Reference: 'RFC7234' is defined on line 1733, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-01 -- Possible downref: Normative reference to a draft: ref. 'Messaging' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-01 -- Possible downref: Normative reference to a draft: ref. 'Semantics' -- Possible downref: Non-RFC (?) normative reference: ref. 'USASCII' -- 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 (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group R. Fielding, Ed. 3 Internet-Draft Adobe 4 Obsoletes: 7234 (if approved) M. Nottingham, Ed. 5 Intended status: Standards Track Fastly 6 Expires: December 2, 2018 J. Reschke, Ed. 7 greenbytes 8 May 31, 2018 10 HTTP Caching 11 draft-ietf-httpbis-cache-01 13 Abstract 15 The Hypertext Transfer Protocol (HTTP) is a stateless application- 16 level protocol for distributed, collaborative, hypertext information 17 systems. This document defines HTTP caches and the associated header 18 fields that control cache behavior or indicate cacheable response 19 messages. 21 This document obsoletes RFC 7234. 23 Editorial Note 25 This note is to be removed before publishing as an RFC. 27 Discussion of this draft takes place on the HTTP working group 28 mailing list (ietf-http-wg@w3.org), which is archived at 29 . 31 Working Group information can be found at ; 32 source code and issues list for this draft can be found at 33 . 35 The changes in this draft are summarized in Appendix C.2. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 2, 2018. 54 Copyright Notice 56 Copyright (c) 2018 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 This document may contain material from IETF Documents or IETF 70 Contributions published or made publicly available before November 71 10, 2008. The person(s) controlling the copyright in some of this 72 material may not have granted the IETF Trust the right to allow 73 modifications of such material outside the IETF Standards Process. 74 Without obtaining an adequate license from the person(s) controlling 75 the copyright in such materials, this document may not be modified 76 outside the IETF Standards Process, and derivative works of it may 77 not be created outside the IETF Standards Process, except to format 78 it for publication as an RFC or to translate it into languages other 79 than English. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 85 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 86 1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 5 87 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 88 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 89 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . 8 90 3.2. Storing Responses to Authenticated Requests . . . . . . . 8 91 3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8 92 4. Constructing Responses from Caches . . . . . . . . . . . . . 9 93 4.1. Calculating Secondary Keys with Vary . . . . . . . . . . 10 94 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11 95 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 12 96 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 13 97 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 14 98 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 99 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 16 100 4.3.1. Sending a Validation Request . . . . . . . . . . . . 16 101 4.3.2. Handling a Received Validation Request . . . . . . . 17 102 4.3.3. Handling a Validation Response . . . . . . . . . . . 18 103 4.3.4. Freshening Stored Responses upon Validation . . . . . 18 104 4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 19 105 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 20 106 5. Header Field Definitions . . . . . . . . . . . . . . . . . . 21 107 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 108 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 22 109 5.2.1. Request Cache-Control Directives . . . . . . . . . . 23 110 5.2.2. Response Cache-Control Directives . . . . . . . . . . 25 111 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 28 112 5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 29 113 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 29 114 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 30 115 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 31 116 5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . 33 117 5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . 33 118 5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 33 119 5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 34 120 5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . 34 121 5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 34 122 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 34 123 5.5.8. Warn Code Registry . . . . . . . . . . . . . . . . . 34 124 6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 34 125 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 126 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 127 8.1. Header Field Registration . . . . . . . . . . . . . . . . 36 128 8.2. Cache Directive Registration . . . . . . . . . . . . . . 36 129 8.3. Warn Code Registration . . . . . . . . . . . . . . . . . 36 130 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 131 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 132 9.2. Informative References . . . . . . . . . . . . . . . . . 37 133 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 134 Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 39 135 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 39 136 C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 39 137 C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 39 138 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 139 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 142 1. Introduction 144 The Hypertext Transfer Protocol (HTTP) is a stateless application- 145 level request/response protocol that uses extensible semantics and 146 self-descriptive messages for flexible interaction with network-based 147 hypertext information systems. HTTP is defined by a series of 148 documents that collectively form the HTTP/1.1 specification: 150 o "HTTP Semantics" [Semantics] 152 o "HTTP Caching" (this document) 154 o "HTTP/1.1 Messaging" [Messaging] 156 HTTP is typically used for distributed information systems, where 157 performance can be improved by the use of response caches. This 158 document defines aspects of HTTP related to caching and reusing 159 response messages. 161 An HTTP cache is a local store of response messages and the subsystem 162 that controls storage, retrieval, and deletion of messages in it. A 163 cache stores cacheable responses in order to reduce the response time 164 and network bandwidth consumption on future, equivalent requests. 165 Any client or server MAY employ a cache, though a cache cannot be 166 used by a server that is acting as a tunnel. 168 A shared cache is a cache that stores responses to be reused by more 169 than one user; shared caches are usually (but not always) deployed as 170 a part of an intermediary. A private cache, in contrast, is 171 dedicated to a single user; often, they are deployed as a component 172 of a user agent. 174 The goal of caching in HTTP/1.1 is to significantly improve 175 performance by reusing a prior response message to satisfy a current 176 request. A stored response is considered "fresh", as defined in 177 Section 4.2, if the response can be reused without "validation" 178 (checking with the origin server to see if the cached response 179 remains valid for this request). A fresh response can therefore 180 reduce both latency and network overhead each time it is reused. 181 When a cached response is not fresh, it might still be reusable if it 182 can be freshened by validation (Section 4.3) or if the origin is 183 unavailable (Section 4.2.4). 185 This document obsoletes RFC 7234, with the changes being summarized 186 in Appendix B. 188 1.1. Requirements Notation 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 192 document are to be interpreted as described in [RFC2119]. 194 Conformance criteria and considerations regarding error handling are 195 defined in Section 3 of [Semantics]. 197 1.2. Syntax Notation 199 This specification uses the Augmented Backus-Naur Form (ABNF) 200 notation of [RFC5234] with a list extension, defined in Section 11 of 201 [Semantics], that allows for compact definition of comma-separated 202 lists using a '#' operator (similar to how the '*' operator indicates 203 repetition). Appendix A shows the collected grammar with all list 204 operators expanded to standard ABNF notation. 206 The following core rules are included by reference, as defined in 207 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 208 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 209 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 210 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any 211 visible [USASCII] character). 213 The rules below are defined in [Semantics]: 215 HTTP-date = 216 OWS = 217 field-name = 218 quoted-string = 219 token = 220 uri-host = 221 port = 222 pseudonym = 224 1.3. Delta Seconds 226 The delta-seconds rule specifies a non-negative integer, representing 227 time in seconds. 229 delta-seconds = 1*DIGIT 231 A recipient parsing a delta-seconds value and converting it to binary 232 form ought to use an arithmetic type of at least 31 bits of non- 233 negative integer range. If a cache receives a delta-seconds value 234 greater than the greatest integer it can represent, or if any of its 235 subsequent calculations overflows, the cache MUST consider the value 236 to be either 2147483648 (2^31) or the greatest positive integer it 237 can conveniently represent. 239 Note: The value 2147483648 is here for historical reasons, 240 effectively represents infinity (over 68 years), and does not need 241 to be stored in binary form; an implementation could produce it as 242 a canned string if any overflow occurs, even if the calculations 243 are performed with an arithmetic type incapable of directly 244 representing that number. What matters here is that an overflow 245 be detected and not treated as a negative value in later 246 calculations. 248 2. Overview of Cache Operation 250 Proper cache operation preserves the semantics of HTTP transfers 251 ([Semantics]) while eliminating the transfer of information already 252 held in the cache. Although caching is an entirely OPTIONAL feature 253 of HTTP, it can be assumed that reusing a cached response is 254 desirable and that such reuse is the default behavior when no 255 requirement or local configuration prevents it. Therefore, HTTP 256 cache requirements are focused on preventing a cache from either 257 storing a non-reusable response or reusing a stored response 258 inappropriately, rather than mandating that caches always store and 259 reuse particular responses. 261 Each cache entry consists of a cache key and one or more HTTP 262 responses corresponding to prior requests that used the same key. 263 The most common form of cache entry is a successful result of a 264 retrieval request: i.e., a 200 (OK) response to a GET request, which 265 contains a representation of the resource identified by the request 266 target (Section 7.3.1 of [Semantics]). However, it is also possible 267 to cache permanent redirects, negative results (e.g., 404 (Not 268 Found)), incomplete results (e.g., 206 (Partial Content)), and 269 responses to methods other than GET if the method's definition allows 270 such caching and defines something suitable for use as a cache key. 272 The primary cache key consists of the request method and target URI. 273 However, since HTTP caches in common use today are typically limited 274 to caching responses to GET, many caches simply decline other methods 275 and use only the URI as the primary cache key. 277 If a request target is subject to content negotiation, its cache 278 entry might consist of multiple stored responses, each differentiated 279 by a secondary key for the values of the original request's selecting 280 header fields (Section 4.1). 282 3. Storing Responses in Caches 284 A cache MUST NOT store a response to any request, unless: 286 o The request method is understood by the cache and defined as being 287 cacheable, and 289 o the response status code is understood by the cache, and 291 o the "no-store" cache directive (see Section 5.2) does not appear 292 in request or response header fields, and 294 o the "private" response directive (see Section 5.2.2.6) does not 295 appear in the response, if the cache is shared, and 297 o the Authorization header field (see Section 8.5.3 of [Semantics]) 298 does not appear in the request, if the cache is shared, unless the 299 response explicitly allows it (see Section 3.2), and 301 o the response either: 303 * contains an Expires header field (see Section 5.3), or 305 * contains a max-age response directive (see Section 5.2.2.8), or 307 * contains a s-maxage response directive (see Section 5.2.2.9) 308 and the cache is shared, or 310 * contains a Cache Control Extension (see Section 5.2.3) that 311 allows it to be cached, or 313 * has a status code that is defined as cacheable by default (see 314 Section 4.2.2), or 316 * contains a public response directive (see Section 5.2.2.5). 318 Note that any of the requirements listed above can be overridden by a 319 cache-control extension; see Section 5.2.3. 321 In this context, a cache has "understood" a request method or a 322 response status code if it recognizes it and implements all specified 323 caching-related behavior. 325 Note that, in normal operation, some caches will not store a response 326 that has neither a cache validator nor an explicit expiration time, 327 as such responses are not usually useful to store. However, caches 328 are not prohibited from storing such responses. 330 3.1. Storing Incomplete Responses 332 A response message is considered complete when all of the octets 333 indicated by the message framing ([Messaging]) are received prior to 334 the connection being closed. If the request method is GET, the 335 response status code is 200 (OK), and the entire response header 336 section has been received, a cache MAY store an incomplete response 337 message body if the cache entry is recorded as incomplete. Likewise, 338 a 206 (Partial Content) response MAY be stored as if it were an 339 incomplete 200 (OK) cache entry. However, a cache MUST NOT store 340 incomplete or partial-content responses if it does not support the 341 Range and Content-Range header fields or if it does not understand 342 the range units used in those fields. 344 A cache MAY complete a stored incomplete response by making a 345 subsequent range request (Section 8.3 of [Semantics]) and combining 346 the successful response with the stored entry, as defined in 347 Section 3.3. A cache MUST NOT use an incomplete response to answer 348 requests unless the response has been made complete or the request is 349 partial and specifies a range that is wholly within the incomplete 350 response. A cache MUST NOT send a partial response to a client 351 without explicitly marking it as such using the 206 (Partial Content) 352 status code. 354 3.2. Storing Responses to Authenticated Requests 356 A shared cache MUST NOT use a cached response to a request with an 357 Authorization header field (Section 8.5.3 of [Semantics]) to satisfy 358 any subsequent request unless a cache directive that allows such 359 responses to be stored is present in the response. 361 In this specification, the following Cache-Control response 362 directives (Section 5.2.2) have such an effect: must-revalidate, 363 public, and s-maxage. 365 Note that cached responses that contain the "must-revalidate" and/or 366 "s-maxage" response directives are not allowed to be served stale 367 (Section 4.2.4) by shared caches. In particular, a response with 368 either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to 369 satisfy a subsequent request without revalidating it on the origin 370 server. 372 3.3. Combining Partial Content 374 A response might transfer only a partial representation if the 375 connection closed prematurely or if the request used one or more 376 Range specifiers (Section 8.3 of [Semantics]). After several such 377 transfers, a cache might have received several ranges of the same 378 representation. A cache MAY combine these ranges into a single 379 stored response, and reuse that response to satisfy later requests, 380 if they all share the same strong validator and the cache complies 381 with the client requirements in Section 9.3.7.3 of [Semantics]. 383 When combining the new response with one or more stored responses, a 384 cache MUST: 386 o delete any Warning header fields in the stored response with warn- 387 code 1xx (see Section 5.5); 389 o retain any Warning header fields in the stored response with warn- 390 code 2xx; and, 392 o use other header fields provided in the new response, aside from 393 Content-Range, to replace all instances of the corresponding 394 header fields in the stored response. 396 4. Constructing Responses from Caches 398 When presented with a request, a cache MUST NOT reuse a stored 399 response, unless: 401 o The presented effective request URI (Section 5.3 of [Semantics]) 402 and that of the stored response match, and 404 o the request method associated with the stored response allows it 405 to be used for the presented request, and 407 o selecting header fields nominated by the stored response (if any) 408 match those presented (see Section 4.1), and 410 o the presented request does not contain the no-cache pragma 411 (Section 5.4), nor the no-cache cache directive (Section 5.2.1), 412 unless the stored response is successfully validated 413 (Section 4.3), and 415 o the stored response does not contain the no-cache cache directive 416 (Section 5.2.2.2), unless it is successfully validated 417 (Section 4.3), and 419 o the stored response is either: 421 * fresh (see Section 4.2), or 423 * allowed to be served stale (see Section 4.2.4), or 425 * successfully validated (see Section 4.3). 427 Note that any of the requirements listed above can be overridden by a 428 cache-control extension; see Section 5.2.3. 430 When a stored response is used to satisfy a request without 431 validation, a cache MUST generate an Age header field (Section 5.1), 432 replacing any present in the response with a value equal to the 433 stored response's current_age; see Section 4.2.3. 435 A cache MUST write through requests with methods that are unsafe 436 (Section 7.2.1 of [Semantics]) to the origin server; i.e., a cache is 437 not allowed to generate a reply to such a request before having 438 forwarded the request and having received a corresponding response. 440 Also, note that unsafe requests might invalidate already-stored 441 responses; see Section 4.4. 443 When more than one suitable response is stored, a cache MUST use the 444 most recent response (as determined by the Date header field). It 445 can also forward the request with "Cache-Control: max-age=0" or 446 "Cache-Control: no-cache" to disambiguate which response to use. 448 A cache that does not have a clock available MUST NOT use stored 449 responses without revalidating them upon every use. 451 4.1. Calculating Secondary Keys with Vary 453 When a cache receives a request that can be satisfied by a stored 454 response that has a Vary header field (Section 10.1.4 of 455 [Semantics]), it MUST NOT use that response unless all of the 456 selecting header fields nominated by the Vary header field match in 457 both the original request (i.e., that associated with the stored 458 response), and the presented request. 460 The selecting header fields from two requests are defined to match if 461 and only if those in the first request can be transformed to those in 462 the second request by applying any of the following: 464 o adding or removing whitespace, where allowed in the header field's 465 syntax 467 o combining multiple header fields with the same field name (see 468 Section 4.2 of [Semantics]) 470 o normalizing both header field values in a way that is known to 471 have identical semantics, according to the header field's 472 specification (e.g., reordering field values when order is not 473 significant; case-normalization, where values are defined to be 474 case-insensitive) 476 If (after any normalization that might take place) a header field is 477 absent from a request, it can only match another request if it is 478 also absent there. 480 A Vary header field-value of "*" always fails to match. 482 The stored response with matching selecting header fields is known as 483 the selected response. 485 If multiple selected responses are available (potentially including 486 responses without a Vary header field), the cache will need to choose 487 one to use. When a selecting header field has a known mechanism for 488 doing so (e.g., qvalues on Accept and similar request header fields), 489 that mechanism MAY be used to select preferred responses; of the 490 remainder, the most recent response (as determined by the Date header 491 field) is used, as per Section 4. 493 If no selected response is available, the cache cannot satisfy the 494 presented request. Typically, it is forwarded to the origin server 495 in a (possibly conditional; see Section 4.3) request. 497 4.2. Freshness 499 A fresh response is one whose age has not yet exceeded its freshness 500 lifetime. Conversely, a stale response is one where it has. 502 A response's freshness lifetime is the length of time between its 503 generation by the origin server and its expiration time. An explicit 504 expiration time is the time at which the origin server intends that a 505 stored response can no longer be used by a cache without further 506 validation, whereas a heuristic expiration time is assigned by a 507 cache when no explicit expiration time is available. 509 A response's age is the time that has passed since it was generated 510 by, or successfully validated with, the origin server. 512 When a response is "fresh" in the cache, it can be used to satisfy 513 subsequent requests without contacting the origin server, thereby 514 improving efficiency. 516 The primary mechanism for determining freshness is for an origin 517 server to provide an explicit expiration time in the future, using 518 either the Expires header field (Section 5.3) or the max-age response 519 directive (Section 5.2.2.8). Generally, origin servers will assign 520 future explicit expiration times to responses in the belief that the 521 representation is not likely to change in a semantically significant 522 way before the expiration time is reached. 524 If an origin server wishes to force a cache to validate every 525 request, it can assign an explicit expiration time in the past to 526 indicate that the response is already stale. Compliant caches will 527 normally validate a stale cached response before reusing it for 528 subsequent requests (see Section 4.2.4). 530 Since origin servers do not always provide explicit expiration times, 531 caches are also allowed to use a heuristic to determine an expiration 532 time under certain circumstances (see Section 4.2.2). 534 The calculation to determine if a response is fresh is: 536 response_is_fresh = (freshness_lifetime > current_age) 538 freshness_lifetime is defined in Section 4.2.1; current_age is 539 defined in Section 4.2.3. 541 Clients can send the max-age or min-fresh cache directives in a 542 request to constrain or relax freshness calculations for the 543 corresponding response (Section 5.2.1). 545 When calculating freshness, to avoid common problems in date parsing: 547 o Although all date formats are specified to be case-sensitive, a 548 cache recipient SHOULD match day, week, and time-zone names case- 549 insensitively. 551 o If a cache recipient's internal implementation of time has less 552 resolution than the value of an HTTP-date, the recipient MUST 553 internally represent a parsed Expires date as the nearest time 554 equal to or earlier than the received value. 556 o A cache recipient MUST NOT allow local time zones to influence the 557 calculation or comparison of an age or expiration time. 559 o A cache recipient SHOULD consider a date with a zone abbreviation 560 other than GMT or UTC to be invalid for calculating expiration. 562 Note that freshness applies only to cache operation; it cannot be 563 used to force a user agent to refresh its display or reload a 564 resource. See Section 6 for an explanation of the difference between 565 caches and history mechanisms. 567 4.2.1. Calculating Freshness Lifetime 569 A cache can calculate the freshness lifetime (denoted as 570 freshness_lifetime) of a response by using the first match of the 571 following: 573 o If the cache is shared and the s-maxage response directive 574 (Section 5.2.2.9) is present, use its value, or 576 o If the max-age response directive (Section 5.2.2.8) is present, 577 use its value, or 579 o If the Expires response header field (Section 5.3) is present, use 580 its value minus the value of the Date response header field, or 582 o Otherwise, no explicit expiration time is present in the response. 583 A heuristic freshness lifetime might be applicable; see 584 Section 4.2.2. 586 Note that this calculation is not vulnerable to clock skew, since all 587 of the information comes from the origin server. 589 When there is more than one value present for a given directive 590 (e.g., two Expires header fields, multiple Cache-Control: max-age 591 directives), the directive's value is considered invalid. Caches are 592 encouraged to consider responses that have invalid freshness 593 information to be stale. 595 4.2.2. Calculating Heuristic Freshness 597 Since origin servers do not always provide explicit expiration times, 598 a cache MAY assign a heuristic expiration time when an explicit time 599 is not specified, employing algorithms that use other header field 600 values (such as the Last-Modified time) to estimate a plausible 601 expiration time. This specification does not provide specific 602 algorithms, but does impose worst-case constraints on their results. 604 A cache MUST NOT use heuristics to determine freshness when an 605 explicit expiration time is present in the stored response. Because 606 of the requirements in Section 3, this means that, effectively, 607 heuristics can only be used on responses without explicit freshness 608 whose status codes are defined as cacheable by default (see 609 Section 9.1 of [Semantics]), and those responses without explicit 610 freshness that have been marked as explicitly cacheable (e.g., with a 611 "public" response directive). 613 If the response has a Last-Modified header field (Section 10.2.2 of 614 [Semantics]), caches are encouraged to use a heuristic expiration 615 value that is no more than some fraction of the interval since that 616 time. A typical setting of this fraction might be 10%. 618 When a heuristic is used to calculate freshness lifetime, a cache 619 SHOULD generate a Warning header field with a 113 warn-code (see 620 Section 5.5.4) in the response if its current_age is more than 24 621 hours and such a warning is not already present. 623 Note: Section 13.9 of [RFC2616] prohibited caches from calculating 624 heuristic freshness for URIs with query components (i.e., those 625 containing '?'). In practice, this has not been widely 626 implemented. Therefore, origin servers are encouraged to send 627 explicit directives (e.g., Cache-Control: no-cache) if they wish 628 to preclude caching. 630 4.2.3. Calculating Age 632 The Age header field is used to convey an estimated age of the 633 response message when obtained from a cache. The Age field value is 634 the cache's estimate of the number of seconds since the response was 635 generated or validated by the origin server. In essence, the Age 636 value is the sum of the time that the response has been resident in 637 each of the caches along the path from the origin server, plus the 638 amount of time it has been in transit along network paths. 640 The following data is used for the age calculation: 642 age_value 643 The term "age_value" denotes the value of the Age header field 644 (Section 5.1), in a form appropriate for arithmetic operation; or 645 0, if not available. 647 date_value 648 The term "date_value" denotes the value of the Date header field, 649 in a form appropriate for arithmetic operations. See 650 Section 10.1.1.2 of [Semantics] for the definition of the Date 651 header field, and for requirements regarding responses without it. 653 now 654 The term "now" means "the current value of the clock at the host 655 performing the calculation". A host ought to use NTP ([RFC5905]) 656 or some similar protocol to synchronize its clocks to Coordinated 657 Universal Time. 659 request_time 660 The current value of the clock at the host at the time the request 661 resulting in the stored response was made. 663 response_time 664 The current value of the clock at the host at the time the 665 response was received. 667 A response's age can be calculated in two entirely independent ways: 669 1. the "apparent_age": response_time minus date_value, if the local 670 clock is reasonably well synchronized to the origin server's 671 clock. If the result is negative, the result is replaced by 672 zero. 674 2. the "corrected_age_value", if all of the caches along the 675 response path implement HTTP/1.1. A cache MUST interpret this 676 value relative to the time the request was initiated, not the 677 time that the response was received. 679 apparent_age = max(0, response_time - date_value); 681 response_delay = response_time - request_time; 682 corrected_age_value = age_value + response_delay; 684 These are combined as 686 corrected_initial_age = max(apparent_age, corrected_age_value); 688 unless the cache is confident in the value of the Age header field 689 (e.g., because there are no HTTP/1.0 hops in the Via header field), 690 in which case the corrected_age_value MAY be used as the 691 corrected_initial_age. 693 The current_age of a stored response can then be calculated by adding 694 the amount of time (in seconds) since the stored response was last 695 validated by the origin server to the corrected_initial_age. 697 resident_time = now - response_time; 698 current_age = corrected_initial_age + resident_time; 700 4.2.4. Serving Stale Responses 702 A "stale" response is one that either has explicit expiry information 703 or is allowed to have heuristic expiry calculated, but is not fresh 704 according to the calculations in Section 4.2. 706 A cache MUST NOT generate a stale response if it is prohibited by an 707 explicit in-protocol directive (e.g., by a "no-store" or "no-cache" 708 cache directive, a "must-revalidate" cache-response-directive, or an 709 applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 710 see Section 5.2.2). 712 A cache MUST NOT send stale responses unless it is disconnected 713 (i.e., it cannot contact the origin server or otherwise find a 714 forward path) or doing so is explicitly allowed (e.g., by the max- 715 stale request directive; see Section 5.2.1). 717 A cache SHOULD generate a Warning header field with the 110 warn-code 718 (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD 719 generate a 112 warn-code (see Section 5.5.3) in stale responses if 720 the cache is disconnected. 722 A cache SHOULD NOT generate a new Warning header field when 723 forwarding a response that does not have an Age header field, even if 724 the response is already stale. A cache need not validate a response 725 that merely became stale in transit. 727 4.3. Validation 729 When a cache has one or more stored responses for a requested URI, 730 but cannot serve any of them (e.g., because they are not fresh, or 731 one cannot be selected; see Section 4.1), it can use the conditional 732 request mechanism Section 8.2 of [Semantics] in the forwarded request 733 to give the next inbound server an opportunity to select a valid 734 stored response to use, updating the stored metadata in the process, 735 or to replace the stored response(s) with a new response. This 736 process is known as "validating" or "revalidating" the stored 737 response. 739 4.3.1. Sending a Validation Request 741 When sending a conditional request for cache validation, a cache 742 sends one or more precondition header fields containing validator 743 metadata from its stored response(s), which is then compared by 744 recipients to determine whether a stored response is equivalent to a 745 current representation of the resource. 747 One such validator is the timestamp given in a Last-Modified header 748 field (Section 10.2.2 of [Semantics]), which can be used in an If- 749 Modified-Since header field for response validation, or in an If- 750 Unmodified-Since or If-Range header field for representation 751 selection (i.e., the client is referring specifically to a previously 752 obtained representation with that timestamp). 754 Another validator is the entity-tag given in an ETag header field 755 (Section 10.2.3 of [Semantics]). One or more entity-tags, indicating 756 one or more stored responses, can be used in an If-None-Match header 757 field for response validation, or in an If-Match or If-Range header 758 field for representation selection (i.e., the client is referring 759 specifically to one or more previously obtained representations with 760 the listed entity-tags). 762 4.3.2. Handling a Received Validation Request 764 Each client in the request chain may have its own cache, so it is 765 common for a cache at an intermediary to receive conditional requests 766 from other (outbound) caches. Likewise, some user agents make use of 767 conditional requests to limit data transfers to recently modified 768 representations or to complete the transfer of a partially retrieved 769 representation. 771 If a cache receives a request that can be satisfied by reusing one of 772 its stored 200 (OK) or 206 (Partial Content) responses, the cache 773 SHOULD evaluate any applicable conditional header field preconditions 774 received in that request with respect to the corresponding validators 775 contained within the selected response. A cache MUST NOT evaluate 776 conditional header fields that are only applicable to an origin 777 server, found in a request with semantics that cannot be satisfied 778 with a cached response, or applied to a target resource for which it 779 has no stored responses; such preconditions are likely intended for 780 some other (inbound) server. 782 The proper evaluation of conditional requests by a cache depends on 783 the received precondition header fields and their precedence, as 784 defined in Section 8.2.2 of [Semantics]. The If-Match and If- 785 Unmodified-Since conditional header fields are not applicable to a 786 cache. 788 A request containing an If-None-Match header field (Section 8.2.4 of 789 [Semantics]) indicates that the client wants to validate one or more 790 of its own stored responses in comparison to whichever stored 791 response is selected by the cache. If the field-value is "*", or if 792 the field-value is a list of entity-tags and at least one of them 793 matches the entity-tag of the selected stored response, a cache 794 recipient SHOULD generate a 304 (Not Modified) response (using the 795 metadata of the selected stored response) instead of sending that 796 stored response. 798 When a cache decides to revalidate its own stored responses for a 799 request that contains an If-None-Match list of entity-tags, the cache 800 MAY combine the received list with a list of entity-tags from its own 801 stored set of responses (fresh or stale) and send the union of the 802 two lists as a replacement If-None-Match header field value in the 803 forwarded request. If a stored response contains only partial 804 content, the cache MUST NOT include its entity-tag in the union 805 unless the request is for a range that would be fully satisfied by 806 that partial stored response. If the response to the forwarded 807 request is 304 (Not Modified) and has an ETag header field value with 808 an entity-tag that is not in the client's list, the cache MUST 809 generate a 200 (OK) response for the client by reusing its 810 corresponding stored response, as updated by the 304 response 811 metadata (Section 4.3.4). 813 If an If-None-Match header field is not present, a request containing 814 an If-Modified-Since header field (Section 8.2.5 of [Semantics]) 815 indicates that the client wants to validate one or more of its own 816 stored responses by modification date. A cache recipient SHOULD 817 generate a 304 (Not Modified) response (using the metadata of the 818 selected stored response) if one of the following cases is true: 1) 819 the selected stored response has a Last-Modified field-value that is 820 earlier than or equal to the conditional timestamp; 2) no Last- 821 Modified field is present in the selected stored response, but it has 822 a Date field-value that is earlier than or equal to the conditional 823 timestamp; or, 3) neither Last-Modified nor Date is present in the 824 selected stored response, but the cache recorded it as having been 825 received at a time earlier than or equal to the conditional 826 timestamp. 828 A cache that implements partial responses to range requests, as 829 defined in Section 8.3 of [Semantics], also needs to evaluate a 830 received If-Range header field (Section 8.2.7 of [Semantics]) with 831 respect to its selected stored response. 833 4.3.3. Handling a Validation Response 835 Cache handling of a response to a conditional request is dependent 836 upon its status code: 838 o A 304 (Not Modified) response status code indicates that the 839 stored response can be updated and reused; see Section 4.3.4. 841 o A full response (i.e., one with a payload body) indicates that 842 none of the stored responses nominated in the conditional request 843 is suitable. Instead, the cache MUST use the full response to 844 satisfy the request and MAY replace the stored response(s). 846 o However, if a cache receives a 5xx (Server Error) response while 847 attempting to validate a response, it can either forward this 848 response to the requesting client, or act as if the server failed 849 to respond. In the latter case, the cache MAY send a previously 850 stored response (see Section 4.2.4). 852 4.3.4. Freshening Stored Responses upon Validation 854 When a cache receives a 304 (Not Modified) response and already has 855 one or more stored 200 (OK) responses for the same cache key, the 856 cache needs to identify which of the stored responses are updated by 857 this new response and then update the stored response(s) with the new 858 information provided in the 304 response. 860 The stored response to update is identified by using the first match 861 (if any) of the following: 863 o If the new response contains a strong validator (see 864 Section 10.2.1 of [Semantics]), then that strong validator 865 identifies the selected representation for update. All of the 866 stored responses with the same strong validator are selected. If 867 none of the stored responses contain the same strong validator, 868 then the cache MUST NOT use the new response to update any stored 869 responses. 871 o If the new response contains a weak validator and that validator 872 corresponds to one of the cache's stored responses, then the most 873 recent of those matching stored responses is selected for update. 875 o If the new response does not include any form of validator (such 876 as in the case where a client generates an If-Modified-Since 877 request from a source other than the Last-Modified response header 878 field), and there is only one stored response, and that stored 879 response also lacks a validator, then that stored response is 880 selected for update. 882 If a stored response is selected for update, the cache MUST: 884 o delete any Warning header fields in the stored response with warn- 885 code 1xx (see Section 5.5); 887 o retain any Warning header fields in the stored response with warn- 888 code 2xx; and, 890 o use other header fields provided in the 304 (Not Modified) 891 response to replace all instances of the corresponding header 892 fields in the stored response. 894 4.3.5. Freshening Responses via HEAD 896 A response to the HEAD method is identical to what an equivalent 897 request made with a GET would have been, except it lacks a body. 898 This property of HEAD responses can be used to invalidate or update a 899 cached GET response if the more efficient conditional GET request 900 mechanism is not available (due to no validators being present in the 901 stored response) or if transmission of the representation body is not 902 desired even if it has changed. 904 When a cache makes an inbound HEAD request for a given request target 905 and receives a 200 (OK) response, the cache SHOULD update or 906 invalidate each of its stored GET responses that could have been 907 selected for that request (see Section 4.1). 909 For each of the stored responses that could have been selected, if 910 the stored response and HEAD response have matching values for any 911 received validator fields (ETag and Last-Modified) and, if the HEAD 912 response has a Content-Length header field, the value of Content- 913 Length matches that of the stored response, the cache SHOULD update 914 the stored response as described below; otherwise, the cache SHOULD 915 consider the stored response to be stale. 917 If a cache updates a stored response with the metadata provided in a 918 HEAD response, the cache MUST: 920 o delete any Warning header fields in the stored response with warn- 921 code 1xx (see Section 5.5); 923 o retain any Warning header fields in the stored response with warn- 924 code 2xx; and, 926 o use other header fields provided in the HEAD response to replace 927 all instances of the corresponding header fields in the stored 928 response and append new header fields to the stored response's 929 header section unless otherwise restricted by the Cache-Control 930 header field. 932 4.4. Invalidation 934 Because unsafe request methods (Section 7.2.1 of [Semantics]) such as 935 PUT, POST or DELETE have the potential for changing state on the 936 origin server, intervening caches can use them to keep their contents 937 up to date. 939 A cache MUST invalidate the effective Request URI (Section 5.3 of 940 [Semantics]) as well as the URI(s) in the Location and Content- 941 Location response header fields (if present) when a non-error status 942 code is received in response to an unsafe request method. 944 However, a cache MUST NOT invalidate a URI from a Location or 945 Content-Location response header field if the host part of that URI 946 differs from the host part in the effective request URI (Section 5.3 947 of [Semantics]). This helps prevent denial-of-service attacks. 949 A cache MUST invalidate the effective request URI (Section 5.3 of 950 [Semantics]) when it receives a non-error response to a request with 951 a method whose safety is unknown. 953 Here, a "non-error response" is one with a 2xx (Successful) or 3xx 954 (Redirection) status code. "Invalidate" means that the cache will 955 either remove all stored responses related to the effective request 956 URI or will mark these as "invalid" and in need of a mandatory 957 validation before they can be sent in response to a subsequent 958 request. 960 Note that this does not guarantee that all appropriate responses are 961 invalidated. For example, a state-changing request might invalidate 962 responses in the caches it travels through, but relevant responses 963 still might be stored in other caches that it has not. 965 5. Header Field Definitions 967 This section defines the syntax and semantics of HTTP/1.1 header 968 fields related to caching. 970 +-------------------+----------+----------+--------------+ 971 | Header Field Name | Protocol | Status | Reference | 972 +-------------------+----------+----------+--------------+ 973 | Age | http | standard | Section 5.1 | 974 | Cache-Control | http | standard | Section 5.2 | 975 | Expires | http | standard | Section 5.3 | 976 | Pragma | http | standard | Section 5.4 | 977 | Warning | http | standard | Section 5.5 | 978 +-------------------+----------+----------+--------------+ 980 5.1. Age 982 The "Age" header field conveys the sender's estimate of the amount of 983 time since the response was generated or successfully validated at 984 the origin server. Age values are calculated as specified in 985 Section 4.2.3. 987 Age = delta-seconds 989 The Age field-value is a non-negative integer, representing time in 990 seconds (see Section 1.3). 992 The presence of an Age header field implies that the response was not 993 generated or validated by the origin server for this request. 994 However, lack of an Age header field does not imply the origin was 995 contacted, since the response might have been received from an 996 HTTP/1.0 cache that does not implement Age. 998 5.2. Cache-Control 1000 The "Cache-Control" header field is used to specify directives for 1001 caches along the request/response chain. Such cache directives are 1002 unidirectional in that the presence of a directive in a request does 1003 not imply that the same directive is to be given in the response. 1005 A cache MUST obey the requirements of the Cache-Control directives 1006 defined in this section. See Section 5.2.3 for information about how 1007 Cache-Control directives defined elsewhere are handled. 1009 Note: Some HTTP/1.0 caches might not implement Cache-Control. 1011 A proxy, whether or not it implements a cache, MUST pass cache 1012 directives through in forwarded messages, regardless of their 1013 significance to that application, since the directives might be 1014 applicable to all recipients along the request/response chain. It is 1015 not possible to target a directive to a specific cache. 1017 Cache directives are identified by a token, to be compared case- 1018 insensitively, and have an optional argument, that can use both token 1019 and quoted-string syntax. For the directives defined below that 1020 define arguments, recipients ought to accept both forms, even if one 1021 is documented to be preferred. For any directive not defined by this 1022 specification, a recipient MUST accept both forms. 1024 Cache-Control = 1#cache-directive 1026 cache-directive = token [ "=" ( token / quoted-string ) ] 1028 For the cache directives defined below, no argument is defined (nor 1029 allowed) unless stated otherwise. 1031 +------------------------+-----------------------------------+ 1032 | Cache Directive | Reference | 1033 +------------------------+-----------------------------------+ 1034 | max-age | Section 5.2.1.1, Section 5.2.2.8 | 1035 | max-stale | Section 5.2.1.2 | 1036 | min-fresh | Section 5.2.1.3 | 1037 | must-revalidate | Section 5.2.2.1 | 1038 | no-cache | Section 5.2.1.4, Section 5.2.2.2 | 1039 | no-store | Section 5.2.1.5, Section 5.2.2.3 | 1040 | no-transform | Section 5.2.1.6, Section 5.2.2.4 | 1041 | only-if-cached | Section 5.2.1.7 | 1042 | private | Section 5.2.2.6 | 1043 | proxy-revalidate | Section 5.2.2.7 | 1044 | public | Section 5.2.2.5 | 1045 | s-maxage | Section 5.2.2.9 | 1046 | stale-if-error | [RFC5861], Section 4 | 1047 | stale-while-revalidate | [RFC5861], Section 3 | 1048 +------------------------+-----------------------------------+ 1050 5.2.1. Request Cache-Control Directives 1052 5.2.1.1. max-age 1054 Argument syntax: 1056 delta-seconds (see Section 1.3) 1058 The "max-age" request directive indicates that the client is 1059 unwilling to accept a response whose age is greater than the 1060 specified number of seconds. Unless the max-stale request directive 1061 is also present, the client is not willing to accept a stale 1062 response. 1064 This directive uses the token form of the argument syntax: e.g., 1065 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the 1066 quoted-string form. 1068 5.2.1.2. max-stale 1070 Argument syntax: 1072 delta-seconds (see Section 1.3) 1074 The "max-stale" request directive indicates that the client is 1075 willing to accept a response that has exceeded its freshness 1076 lifetime. If max-stale is assigned a value, then the client is 1077 willing to accept a response that has exceeded its freshness lifetime 1078 by no more than the specified number of seconds. If no value is 1079 assigned to max-stale, then the client is willing to accept a stale 1080 response of any age. 1082 This directive uses the token form of the argument syntax: e.g., 1083 'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate 1084 the quoted-string form. 1086 5.2.1.3. min-fresh 1088 Argument syntax: 1090 delta-seconds (see Section 1.3) 1092 The "min-fresh" request directive indicates that the client is 1093 willing to accept a response whose freshness lifetime is no less than 1094 its current age plus the specified time in seconds. That is, the 1095 client wants a response that will still be fresh for at least the 1096 specified number of seconds. 1098 This directive uses the token form of the argument syntax: e.g., 1099 'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate 1100 the quoted-string form. 1102 5.2.1.4. no-cache 1104 The "no-cache" request directive indicates that a cache MUST NOT use 1105 a stored response to satisfy the request without successful 1106 validation on the origin server. 1108 5.2.1.5. no-store 1110 The "no-store" request directive indicates that a cache MUST NOT 1111 store any part of either this request or any response to it. This 1112 directive applies to both private and shared caches. "MUST NOT 1113 store" in this context means that the cache MUST NOT intentionally 1114 store the information in non-volatile storage, and MUST make a best- 1115 effort attempt to remove the information from volatile storage as 1116 promptly as possible after forwarding it. 1118 This directive is NOT a reliable or sufficient mechanism for ensuring 1119 privacy. In particular, malicious or compromised caches might not 1120 recognize or obey this directive, and communications networks might 1121 be vulnerable to eavesdropping. 1123 Note that if a request containing this directive is satisfied from a 1124 cache, the no-store request directive does not apply to the already 1125 stored response. 1127 5.2.1.6. no-transform 1129 The "no-transform" request directive indicates that an intermediary 1130 (whether or not it implements a cache) MUST NOT transform the 1131 payload, as defined in Section 5.6.2 of [Semantics]. 1133 5.2.1.7. only-if-cached 1135 The "only-if-cached" request directive indicates that the client only 1136 wishes to obtain a stored response. If it receives this directive, a 1137 cache SHOULD either respond using a stored response that is 1138 consistent with the other constraints of the request, or respond with 1139 a 504 (Gateway Timeout) status code. If a group of caches is being 1140 operated as a unified system with good internal connectivity, a 1141 member cache MAY forward such a request within that group of caches. 1143 5.2.2. Response Cache-Control Directives 1145 5.2.2.1. must-revalidate 1147 The "must-revalidate" response directive indicates that once it has 1148 become stale, a cache MUST NOT use the response to satisfy subsequent 1149 requests without successful validation on the origin server. 1151 The must-revalidate directive is necessary to support reliable 1152 operation for certain protocol features. In all circumstances a 1153 cache MUST obey the must-revalidate directive; in particular, if a 1154 cache cannot reach the origin server for any reason, it MUST generate 1155 a 504 (Gateway Timeout) response. 1157 The must-revalidate directive ought to be used by servers if and only 1158 if failure to validate a request on the representation could result 1159 in incorrect operation, such as a silently unexecuted financial 1160 transaction. 1162 5.2.2.2. no-cache 1164 Argument syntax: 1166 #field-name 1168 The "no-cache" response directive indicates that the response MUST 1169 NOT be used to satisfy a subsequent request without successful 1170 validation on the origin server. This allows an origin server to 1171 prevent a cache from using it to satisfy a request without contacting 1172 it, even by caches that have been configured to send stale responses. 1174 If the no-cache response directive specifies one or more field-names, 1175 then a cache MAY use the response to satisfy a subsequent request, 1176 subject to any other restrictions on caching. However, any header 1177 fields in the response that have the field-name(s) listed MUST NOT be 1178 sent in the response to a subsequent request without successful 1179 revalidation with the origin server. This allows an origin server to 1180 prevent the re-use of certain header fields in a response, while 1181 still allowing caching of the rest of the response. 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: Although it has been back-ported to many implementations, some 1191 HTTP/1.0 caches will not recognize or obey this directive. Also, no- 1192 cache response directives with field-names are often handled by 1193 caches as if an unqualified no-cache directive was received; i.e., 1194 the special handling for the qualified form is not widely 1195 implemented. 1197 5.2.2.3. no-store 1199 The "no-store" response directive indicates that a cache MUST NOT 1200 store any part of either the immediate request or response. This 1201 directive applies to both private and shared caches. "MUST NOT 1202 store" in this context means that the cache MUST NOT intentionally 1203 store the information in non-volatile storage, and MUST make a best- 1204 effort attempt to remove the information from volatile storage as 1205 promptly as possible after forwarding it. 1207 This directive is NOT a reliable or sufficient mechanism for ensuring 1208 privacy. In particular, malicious or compromised caches might not 1209 recognize or obey this directive, and communications networks might 1210 be vulnerable to eavesdropping. 1212 5.2.2.4. no-transform 1214 The "no-transform" response directive indicates that an intermediary 1215 (regardless of whether it implements a cache) MUST NOT transform the 1216 payload, as defined in Section 5.6.2 of [Semantics]. 1218 5.2.2.5. public 1220 The "public" response directive indicates that any cache MAY store 1221 the response, even if the response would normally be non-cacheable or 1222 cacheable only within a private cache. (See Section 3.2 for 1223 additional details related to the use of public in response to a 1224 request containing Authorization, and Section 3 for details of how 1225 public affects responses that would normally not be stored, due to 1226 their status codes not being defined as cacheable by default; see 1227 Section 4.2.2.) 1229 5.2.2.6. private 1231 Argument syntax: 1233 #field-name 1235 The "private" response directive indicates that the response message 1236 is intended for a single user and MUST NOT be stored by a shared 1237 cache. A private cache MAY store the response and reuse it for later 1238 requests, even if the response would normally be non-cacheable. 1240 If the private response directive specifies one or more field-names, 1241 this requirement is limited to the field-values associated with the 1242 listed response header fields. That is, a shared cache MUST NOT 1243 store the specified field-names(s), whereas it MAY store the 1244 remainder of the response message. 1246 The field-names given are not limited to the set of header fields 1247 defined by this specification. Field names are case-insensitive. 1249 This directive uses the quoted-string form of the argument syntax. A 1250 sender SHOULD NOT generate the token form (even if quoting appears 1251 not to be needed for single-entry lists). 1253 Note: This usage of the word "private" only controls where the 1254 response can be stored; it cannot ensure the privacy of the message 1255 content. Also, private response directives with field-names are 1256 often handled by caches as if an unqualified private directive was 1257 received; i.e., the special handling for the qualified form is not 1258 widely implemented. 1260 5.2.2.7. proxy-revalidate 1262 The "proxy-revalidate" response directive has the same meaning as the 1263 must-revalidate response directive, except that it does not apply to 1264 private caches. 1266 5.2.2.8. max-age 1268 Argument syntax: 1270 delta-seconds (see Section 1.3) 1272 The "max-age" response directive indicates that the response is to be 1273 considered stale after its age is greater than the specified number 1274 of seconds. 1276 This directive uses the token form of the argument syntax: e.g., 1277 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the 1278 quoted-string form. 1280 5.2.2.9. s-maxage 1282 Argument syntax: 1284 delta-seconds (see Section 1.3) 1286 The "s-maxage" response directive indicates that, in shared caches, 1287 the maximum age specified by this directive overrides the maximum age 1288 specified by either the max-age directive or the Expires header 1289 field. The s-maxage directive also implies the semantics of the 1290 proxy-revalidate response directive. 1292 This directive uses the token form of the argument syntax: e.g., 1293 's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the 1294 quoted-string form. 1296 5.2.3. Cache Control Extensions 1298 The Cache-Control header field can be extended through the use of one 1299 or more cache-extension tokens, each with an optional value. A cache 1300 MUST ignore unrecognized cache directives. 1302 Informational extensions (those that do not require a change in cache 1303 behavior) can be added without changing the semantics of other 1304 directives. 1306 Behavioral extensions are designed to work by acting as modifiers to 1307 the existing base of cache directives. Both the new directive and 1308 the old directive are supplied, such that applications that do not 1309 understand the new directive will default to the behavior specified 1310 by the old directive, and those that understand the new directive 1311 will recognize it as modifying the requirements associated with the 1312 old directive. In this way, extensions to the existing cache-control 1313 directives can be made without breaking deployed caches. 1315 For example, consider a hypothetical new response directive called 1316 "community" that acts as a modifier to the private directive: in 1317 addition to private caches, any cache that is shared only by members 1318 of the named community is allowed to cache the response. An origin 1319 server wishing to allow the UCI community to use an otherwise private 1320 response in their shared cache(s) could do so by including 1322 Cache-Control: private, community="UCI" 1324 A cache that recognizes such a community cache-extension could 1325 broaden its behavior in accordance with that extension. A cache that 1326 does not recognize the community cache-extension would ignore it and 1327 adhere to the private directive. 1329 New extension directives ought to consider defining: 1331 o What it means for a directive to be specified multiple times, 1333 o When the directive does not take an argument, what it means when 1334 an argument is present, 1336 o When the directive requires an argument, what it means when it is 1337 missing, 1339 o Whether the directive is specific to requests, responses, or able 1340 to be used in either. 1342 5.2.4. Cache Directive Registry 1344 The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" 1345 defines the namespace for the cache directives. It has been created 1346 and is now maintained at . 1349 A registration MUST include the following fields: 1351 o Cache Directive Name 1353 o Pointer to specification text 1355 Values to be added to this namespace require IETF Review (see 1356 [RFC5226], Section 4.1). 1358 5.3. Expires 1360 The "Expires" header field gives the date/time after which the 1361 response is considered stale. See Section 4.2 for further discussion 1362 of the freshness model. 1364 The presence of an Expires field does not imply that the original 1365 resource will change or cease to exist at, before, or after that 1366 time. 1368 The Expires value is an HTTP-date timestamp, as defined in 1369 Section 10.1.1.1 of [Semantics]. 1371 Expires = HTTP-date 1373 For example 1375 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1377 A cache recipient MUST interpret invalid date formats, especially the 1378 value "0", as representing a time in the past (i.e., "already 1379 expired"). 1381 If a response includes a Cache-Control field with the max-age 1382 directive (Section 5.2.2.8), a recipient MUST ignore the Expires 1383 field. Likewise, if a response includes the s-maxage directive 1384 (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires 1385 field. In both these cases, the value in Expires is only intended 1386 for recipients that have not yet implemented the Cache-Control field. 1388 An origin server without a clock MUST NOT generate an Expires field 1389 unless its value represents a fixed time in the past (always expired) 1390 or its value has been associated with the resource by a system or 1391 user with a reliable clock. 1393 Historically, HTTP required the Expires field-value to be no more 1394 than a year in the future. While longer freshness lifetimes are no 1395 longer prohibited, extremely large values have been demonstrated to 1396 cause problems (e.g., clock overflows due to use of 32-bit integers 1397 for time values), and many caches will evict a response far sooner 1398 than that. 1400 5.4. Pragma 1402 The "Pragma" header field allows backwards compatibility with 1403 HTTP/1.0 caches, so that clients can specify a "no-cache" request 1404 that they will understand (as Cache-Control was not defined until 1405 HTTP/1.1). When the Cache-Control header field is also present and 1406 understood in a request, Pragma is ignored. 1408 In HTTP/1.0, Pragma was defined as an extensible field for 1409 implementation-specified directives for recipients. This 1410 specification deprecates such extensions to improve interoperability. 1412 Pragma = 1#pragma-directive 1413 pragma-directive = "no-cache" / extension-pragma 1414 extension-pragma = token [ "=" ( token / quoted-string ) ] 1416 When the Cache-Control header field is not present in a request, 1417 caches MUST consider the no-cache request pragma-directive as having 1418 the same effect as if "Cache-Control: no-cache" were present (see 1419 Section 5.2.1). 1421 When sending a no-cache request, a client ought to include both the 1422 pragma and cache-control directives, unless Cache-Control: no-cache 1423 is purposefully omitted to target other Cache-Control response 1424 directives at HTTP/1.1 caches. For example: 1426 GET / HTTP/1.1 1427 Host: www.example.com 1428 Cache-Control: max-age=30 1429 Pragma: no-cache 1431 will constrain HTTP/1.1 caches to serve a response no older than 30 1432 seconds, while precluding implementations that do not understand 1433 Cache-Control from serving a cached response. 1435 Note: Because the meaning of "Pragma: no-cache" in responses is 1436 not specified, it does not provide a reliable replacement for 1437 "Cache-Control: no-cache" in them. 1439 5.5. Warning 1441 The "Warning" header field is used to carry additional information 1442 about the status or transformation of a message that might not be 1443 reflected in the status code. This information is typically used to 1444 warn about possible incorrectness introduced by caching operations or 1445 transformations applied to the payload of the message. 1447 Warnings can be used for other purposes, both cache-related and 1448 otherwise. The use of a warning, rather than an error status code, 1449 distinguishes these responses from true failures. 1451 Warning header fields can in general be applied to any message, 1452 however some warn-codes are specific to caches and can only be 1453 applied to response messages. 1455 Warning = 1#warning-value 1457 warning-value = warn-code SP warn-agent SP warn-text 1458 [ SP warn-date ] 1460 warn-code = 3DIGIT 1461 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1462 ; the name or pseudonym of the server adding 1463 ; the Warning header field, for use in debugging 1464 ; a single "-" is recommended when agent unknown 1465 warn-text = quoted-string 1466 warn-date = DQUOTE HTTP-date DQUOTE 1468 Multiple warnings can be generated in a response (either by the 1469 origin server or by a cache), including multiple warnings with the 1470 same warn-code number that only differ in warn-text. 1472 A user agent that receives one or more Warning header fields SHOULD 1473 inform the user of as many of them as possible, in the order that 1474 they appear in the response. Senders that generate multiple Warning 1475 header fields are encouraged to order them with this user agent 1476 behavior in mind. A sender that generates new Warning header fields 1477 MUST append them after any existing Warning header fields. 1479 Warnings are assigned three digit warn-codes. The first digit 1480 indicates whether the Warning is required to be deleted from a stored 1481 response after validation: 1483 o 1xx warn-codes describe the freshness or validation status of the 1484 response, and so they MUST be deleted by a cache after validation. 1485 They can only be generated by a cache when validating a cached 1486 entry, and MUST NOT be generated in any other situation. 1488 o 2xx warn-codes describe some aspect of the representation that is 1489 not rectified by a validation (for example, a lossy compression of 1490 the representation) and they MUST NOT be deleted by a cache after 1491 validation, unless a full response is sent, in which case they 1492 MUST be. 1494 If a sender generates one or more 1xx warn-codes in a message to be 1495 sent to a recipient known to implement only HTTP/1.0, the sender MUST 1496 include in each corresponding warning-value a warn-date that matches 1497 the Date header field in the message. For example: 1499 HTTP/1.1 200 OK 1500 Date: Sat, 25 Aug 2012 23:34:45 GMT 1501 Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT" 1503 Warnings have accompanying warn-text that describes the error, e.g., 1504 for logging. It is advisory only, and its content does not affect 1505 interpretation of the warn-code. 1507 If a recipient that uses, evaluates, or displays Warning header 1508 fields receives a warn-date that is different from the Date value in 1509 the same message, the recipient MUST exclude the warning-value 1510 containing that warn-date before storing, forwarding, or using the 1511 message. This allows recipients to exclude warning-values that were 1512 improperly retained after a cache validation. If all of the warning- 1513 values are excluded, the recipient MUST exclude the Warning header 1514 field as well. 1516 The following warn-codes are defined by this specification, each with 1517 a recommended warn-text in English, and a description of its meaning. 1518 The procedure for defining additional warn codes is described in 1519 Section 5.5.8. 1521 +-----------+----------------------------------+----------------+ 1522 | Warn Code | Short Description | Reference | 1523 +-----------+----------------------------------+----------------+ 1524 | 110 | Response is Stale | Section 5.5.1 | 1525 | 111 | Revalidation Failed | Section 5.5.2 | 1526 | 112 | Disconnected Operation | Section 5.5.3 | 1527 | 113 | Heuristic Expiration | Section 5.5.4 | 1528 | 199 | Miscellaneous Warning | Section 5.5.5 | 1529 | 214 | Transformation Applied | Section 5.5.6 | 1530 | 299 | Miscellaneous Persistent Warning | Section 5.5.7 | 1531 +-----------+----------------------------------+----------------+ 1533 5.5.1. Warning: 110 - "Response is Stale" 1535 A cache SHOULD generate this whenever the sent response is stale. 1537 5.5.2. Warning: 111 - "Revalidation Failed" 1539 A cache SHOULD generate this when sending a stale response because an 1540 attempt to validate the response failed, due to an inability to reach 1541 the server. 1543 5.5.3. Warning: 112 - "Disconnected Operation" 1545 A cache SHOULD generate this if it is intentionally disconnected from 1546 the rest of the network for a period of time. 1548 5.5.4. Warning: 113 - "Heuristic Expiration" 1550 A cache SHOULD generate this if it heuristically chose a freshness 1551 lifetime greater than 24 hours and the response's age is greater than 1552 24 hours. 1554 5.5.5. Warning: 199 - "Miscellaneous Warning" 1556 The warning text can include arbitrary information to be presented to 1557 a human user or logged. A system receiving this warning MUST NOT 1558 take any automated action, besides presenting the warning to the 1559 user. 1561 5.5.6. Warning: 214 - "Transformation Applied" 1563 This Warning code MUST be added by a proxy if it applies any 1564 transformation to the representation, such as changing the content- 1565 coding, media-type, or modifying the representation data, unless this 1566 Warning code already appears in the response. 1568 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" 1570 The warning text can include arbitrary information to be presented to 1571 a human user or logged. A system receiving this warning MUST NOT 1572 take any automated action. 1574 5.5.8. Warn Code Registry 1576 The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines 1577 the namespace for warn codes. It has been created and is now 1578 maintained at . 1580 A registration MUST include the following fields: 1582 o Warn Code (3 digits) 1584 o Short Description 1586 o Pointer to specification text 1588 Values to be added to this namespace require IETF Review (see 1589 [RFC5226], Section 4.1). 1591 6. History Lists 1593 User agents often have history mechanisms, such as "Back" buttons and 1594 history lists, that can be used to redisplay a representation 1595 retrieved earlier in a session. 1597 The freshness model (Section 4.2) does not necessarily apply to 1598 history mechanisms. That is, a history mechanism can display a 1599 previous representation even if it has expired. 1601 This does not prohibit the history mechanism from telling the user 1602 that a view might be stale or from honoring cache directives (e.g., 1603 Cache-Control: no-store). 1605 7. Security Considerations 1607 This section is meant to inform developers, information providers, 1608 and users of known security concerns specific to HTTP caching. More 1609 general security considerations are addressed in HTTP messaging 1610 [Messaging] and semantics [Semantics]. 1612 Caches expose additional potential vulnerabilities, since the 1613 contents of the cache represent an attractive target for malicious 1614 exploitation. Because cache contents persist after an HTTP request 1615 is complete, an attack on the cache can reveal information long after 1616 a user believes that the information has been removed from the 1617 network. Therefore, cache contents need to be protected as sensitive 1618 information. 1620 In particular, various attacks might be amplified by being stored in 1621 a shared cache; such "cache poisoning" attacks use the cache to 1622 distribute a malicious payload to many clients, and are especially 1623 effective when an attacker can use implementation flaws, elevated 1624 privileges, or other techniques to insert such a response into a 1625 cache. One common attack vector for cache poisoning is to exploit 1626 differences in message parsing on proxies and in user agents; see 1627 Section 6.3 of [Messaging] for the relevant requirements. 1629 Likewise, implementation flaws (as well as misunderstanding of cache 1630 operation) might lead to caching of sensitive information (e.g., 1631 authentication credentials) that is thought to be private, exposing 1632 it to unauthorized parties. 1634 Furthermore, the very use of a cache can bring about privacy 1635 concerns. For example, if two users share a cache, and the first one 1636 browses to a site, the second may be able to detect that the other 1637 has been to that site, because the resources from it load more 1638 quickly, thanks to the cache. 1640 Note that the Set-Cookie response header field [RFC6265] does not 1641 inhibit caching; a cacheable response with a Set-Cookie header field 1642 can be (and often is) used to satisfy subsequent requests to caches. 1643 Servers who wish to control caching of these responses are encouraged 1644 to emit appropriate Cache-Control response header fields. 1646 8. IANA Considerations 1648 This section is to be removed before publishing as an RFC. 1650 The change controller for the following registrations is: "IETF 1651 (iesg@ietf.org) - Internet Engineering Task Force". 1653 8.1. Header Field Registration 1655 Please update the "Message Headers" registry of "Permanent Message 1656 Header Field Names" at with the header field names listed in the table of 1658 Section 5. 1660 8.2. Cache Directive Registration 1662 Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive 1663 Registry" at 1664 with the registration procedure of Section 5.2.4 and the cache 1665 directive names summarized in the table of Section 5.2. 1667 8.3. Warn Code Registration 1669 Please update the "Hypertext Transfer Protocol (HTTP) Warn Codes" 1670 registry at with 1671 the registration procedure of Section 5.5.8 and the warn code values 1672 summarized in the table of Section 5.5. 1674 9. References 1676 9.1. Normative References 1678 [Messaging] 1679 Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1680 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-01 1681 (work in progress), May 2018. 1683 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1684 Requirement Levels", BCP 14, RFC 2119, 1685 DOI 10.17487/RFC2119, March 1997, 1686 . 1688 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1689 Resource Identifier (URI): Generic Syntax", STD 66, 1690 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1691 . 1693 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1694 Specifications: ABNF", STD 68, RFC 5234, 1695 DOI 10.17487/RFC5234, January 2008, 1696 . 1698 [Semantics] 1699 Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1700 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-01 1701 (work in progress), May 2018. 1703 [USASCII] American National Standards Institute, "Coded Character 1704 Set -- 7-bit American Standard Code for Information 1705 Interchange", ANSI X3.4, 1986. 1707 9.2. Informative References 1709 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1710 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1711 Transfer Protocol -- HTTP/1.1", RFC 2616, 1712 DOI 10.17487/RFC2616, June 1999, 1713 . 1715 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1716 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1717 DOI 10.17487/RFC5226, May 2008, 1718 . 1720 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1721 Content", RFC 5861, DOI 10.17487/RFC5861, April 2010, 1722 . 1724 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1725 "Network Time Protocol Version 4: Protocol and Algorithms 1726 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1727 . 1729 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1730 DOI 10.17487/RFC6265, April 2011, 1731 . 1733 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1734 Ed., "Hypertext Transfer Protocol (HTTP): Caching", 1735 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1736 . 1738 Appendix A. Collected ABNF 1740 In the collected ABNF below, list rules are expanded as per 1741 Section 11 of [Semantics]. 1743 Age = delta-seconds 1745 Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS 1746 cache-directive ] ) 1748 Expires = HTTP-date 1750 HTTP-date = 1752 OWS = 1754 Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS 1755 pragma-directive ] ) 1757 Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] 1758 ) 1760 cache-directive = token [ "=" ( token / quoted-string ) ] 1762 delta-seconds = 1*DIGIT 1764 extension-pragma = token [ "=" ( token / quoted-string ) ] 1766 field-name = 1768 port = 1769 pragma-directive = "no-cache" / extension-pragma 1770 pseudonym = 1772 quoted-string = 1774 token = 1776 uri-host = 1778 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1779 warn-code = 3DIGIT 1780 warn-date = DQUOTE HTTP-date DQUOTE 1781 warn-text = quoted-string 1782 warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date 1783 ] 1785 Appendix B. Changes from RFC 7234 1787 None yet. 1789 Appendix C. Change Log 1791 This section is to be removed before publishing as an RFC. 1793 C.1. Between RFC7234 and draft 00 1795 The changes were purely editorial: 1797 o Change boilerplate and abstract to indicate the "draft" status, 1798 and update references to ancestor specifications. 1800 o Remove version "1.1" from document title, indicating that this 1801 specification applies to all HTTP versions. 1803 o Adjust historical notes. 1805 o Update links to sibling specifications. 1807 o Replace sections listing changes from RFC 2616 by new empty 1808 sections referring to RFC 723x. 1810 o Remove acknowledgements specific to RFC 723x. 1812 o Move "Acknowledgements" to the very end and make them unnumbered. 1814 C.2. Since draft-ietf-httpbis-cache-00 1816 The changes are purely editorial: 1818 o Moved all extensibility tips, registration procedures, and 1819 registry tables from the IANA considerations to normative 1820 sections, reducing the IANA considerations to just instructions 1821 that will be removed prior to publication as an RFC. 1823 Index 1825 1 1826 110 (warn-code) 33 1827 111 (warn-code) 33 1828 112 (warn-code) 33 1829 113 (warn-code) 34 1830 199 (warn-code) 34 1832 2 1833 214 (warn-code) 34 1834 299 (warn-code) 34 1836 A 1837 Age header field 21 1838 age 11 1840 C 1841 Cache-Control header field 22 1842 cache 4 1843 cache entry 6 1844 cache key 6 1846 D 1847 Disconnected Operation (warn-text) 33 1849 E 1850 Expires header field 29 1851 explicit expiration time 11 1853 F 1854 fresh 11 1855 freshness lifetime 11 1857 G 1858 Grammar 1859 Age 21 1860 ALPHA 5 1861 Cache-Control 22 1862 cache-directive 22 1863 CR 5 1864 CRLF 5 1865 CTL 5 1866 delta-seconds 5 1867 DIGIT 5 1868 DQUOTE 5 1869 Expires 30 1870 extension-pragma 31 1871 HEXDIG 5 1872 HTAB 5 1873 LF 5 1874 OCTET 5 1875 Pragma 31 1876 pragma-directive 31 1877 SP 5 1878 VCHAR 5 1879 warn-agent 32 1880 warn-code 32 1881 warn-date 32 1882 warn-text 32 1883 Warning 32 1884 warning-value 32 1886 H 1887 Heuristic Expiration (warn-text) 34 1888 heuristic expiration time 11 1890 M 1891 Miscellaneous Persistent Warning (warn-text) 34 1892 Miscellaneous Warning (warn-text) 34 1893 max-age (cache directive) 23, 28 1894 max-stale (cache directive) 23 1895 min-fresh (cache directive) 24 1896 must-revalidate (cache directive) 25 1898 N 1899 no-cache (cache directive) 24-25 1900 no-store (cache directive) 24, 26 1901 no-transform (cache directive) 25-26 1903 O 1904 only-if-cached (cache directive) 25 1906 P 1907 Pragma header field 30 1908 private (cache directive) 27 1909 private cache 4 1910 proxy-revalidate (cache directive) 27 1911 public (cache directive) 27 1913 R 1914 Response is Stale (warn-text) 33 1915 Revalidation Failed (warn-text) 33 1917 S 1918 s-maxage (cache directive) 28 1919 shared cache 4 1920 stale 11 1921 strong validator 19 1923 T 1924 Transformation Applied (warn-text) 34 1926 V 1927 validator 16 1929 W 1930 Warning header field 31 1932 Acknowledgments 1934 See Appendix "Acknowledgments" of [Semantics]. 1936 Authors' Addresses 1938 Roy T. Fielding (editor) 1939 Adobe 1940 345 Park Ave 1941 San Jose, CA 95110 1942 USA 1944 EMail: fielding@gbiv.com 1945 URI: https://roy.gbiv.com/ 1947 Mark Nottingham (editor) 1948 Fastly 1950 EMail: mnot@mnot.net 1951 URI: https://www.mnot.net/ 1953 Julian F. Reschke (editor) 1954 greenbytes GmbH 1955 Hafenweg 16 1956 Muenster, NW 48155 1957 Germany 1959 EMail: julian.reschke@greenbytes.de 1960 URI: https://greenbytes.de/tech/webdav/