idnits 2.17.00 (12 Aug 2021) /tmp/idnits31429/draft-ietf-httpbis-cache-02.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 (July 2, 2018) is 1418 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 1687, but no explicit reference was found in the text == Unused Reference: 'RFC7234' is defined on line 1727, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-02 -- Possible downref: Normative reference to a draft: ref. 'Messaging' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-02 -- 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) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 6 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: January 3, 2019 J. Reschke, Ed. 7 greenbytes 8 July 2, 2018 10 HTTP Caching 11 draft-ietf-httpbis-cache-02 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.3. 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 January 3, 2019. 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 C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 39 139 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 140 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 141 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 143 1. Introduction 145 The Hypertext Transfer Protocol (HTTP) is a stateless application- 146 level request/response protocol that uses extensible semantics and 147 self-descriptive messages for flexible interaction with network-based 148 hypertext information systems. HTTP is defined by a series of 149 documents that collectively form the HTTP/1.1 specification: 151 o "HTTP Semantics" [Semantics] 153 o "HTTP Caching" (this document) 155 o "HTTP/1.1 Messaging" [Messaging] 157 HTTP is typically used for distributed information systems, where 158 performance can be improved by the use of response caches. This 159 document defines aspects of HTTP related to caching and reusing 160 response messages. 162 An HTTP cache is a local store of response messages and the subsystem 163 that controls storage, retrieval, and deletion of messages in it. A 164 cache stores cacheable responses in order to reduce the response time 165 and network bandwidth consumption on future, equivalent requests. 166 Any client or server MAY employ a cache, though a cache cannot be 167 used by a server that is acting as a tunnel. 169 A shared cache is a cache that stores responses to be reused by more 170 than one user; shared caches are usually (but not always) deployed as 171 a part of an intermediary. A private cache, in contrast, is 172 dedicated to a single user; often, they are deployed as a component 173 of a user agent. 175 The goal of caching in HTTP/1.1 is to significantly improve 176 performance by reusing a prior response message to satisfy a current 177 request. A stored response is considered "fresh", as defined in 178 Section 4.2, if the response can be reused without "validation" 179 (checking with the origin server to see if the cached response 180 remains valid for this request). A fresh response can therefore 181 reduce both latency and network overhead each time it is reused. 182 When a cached response is not fresh, it might still be reusable if it 183 can be freshened by validation (Section 4.3) or if the origin is 184 unavailable (Section 4.2.4). 186 This document obsoletes RFC 7234, with the changes being summarized 187 in Appendix B. 189 1.1. Requirements Notation 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in [RFC2119]. 195 Conformance criteria and considerations regarding error handling are 196 defined in Section 3 of [Semantics]. 198 1.2. Syntax Notation 200 This specification uses the Augmented Backus-Naur Form (ABNF) 201 notation of [RFC5234] with a list extension, defined in Section 11 of 202 [Semantics], that allows for compact definition of comma-separated 203 lists using a '#' operator (similar to how the '*' operator indicates 204 repetition). Appendix A shows the collected grammar with all list 205 operators expanded to standard ABNF notation. 207 The following core rules are included by reference, as defined in 208 [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF 209 (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), 210 HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line 211 feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any 212 visible [USASCII] character). 214 The rules below are defined in [Semantics]: 216 HTTP-date = 217 OWS = 218 field-name = 219 quoted-string = 220 token = 221 uri-host = 222 port = 223 pseudonym = 225 1.3. Delta Seconds 227 The delta-seconds rule specifies a non-negative integer, representing 228 time in seconds. 230 delta-seconds = 1*DIGIT 232 A recipient parsing a delta-seconds value and converting it to binary 233 form ought to use an arithmetic type of at least 31 bits of non- 234 negative integer range. If a cache receives a delta-seconds value 235 greater than the greatest integer it can represent, or if any of its 236 subsequent calculations overflows, the cache MUST consider the value 237 to be either 2147483648 (2^31) or the greatest positive integer it 238 can conveniently represent. 240 Note: The value 2147483648 is here for historical reasons, 241 effectively represents infinity (over 68 years), and does not need 242 to be stored in binary form; an implementation could produce it as 243 a canned string if any overflow occurs, even if the calculations 244 are performed with an arithmetic type incapable of directly 245 representing that number. What matters here is that an overflow 246 be detected and not treated as a negative value in later 247 calculations. 249 2. Overview of Cache Operation 251 Proper cache operation preserves the semantics of HTTP transfers 252 ([Semantics]) while eliminating the transfer of information already 253 held in the cache. Although caching is an entirely OPTIONAL feature 254 of HTTP, it can be assumed that reusing a cached response is 255 desirable and that such reuse is the default behavior when no 256 requirement or local configuration prevents it. Therefore, HTTP 257 cache requirements are focused on preventing a cache from either 258 storing a non-reusable response or reusing a stored response 259 inappropriately, rather than mandating that caches always store and 260 reuse particular responses. 262 Each cache entry consists of a cache key and one or more HTTP 263 responses corresponding to prior requests that used the same key. 264 The most common form of cache entry is a successful result of a 265 retrieval request: i.e., a 200 (OK) response to a GET request, which 266 contains a representation of the resource identified by the request 267 target (Section 7.3.1 of [Semantics]). However, it is also possible 268 to cache permanent redirects, negative results (e.g., 404 (Not 269 Found)), incomplete results (e.g., 206 (Partial Content)), and 270 responses to methods other than GET if the method's definition allows 271 such caching and defines something suitable for use as a cache key. 273 The primary cache key consists of the request method and target URI. 274 However, since HTTP caches in common use today are typically limited 275 to caching responses to GET, many caches simply decline other methods 276 and use only the URI as the primary cache key. 278 If a request target is subject to content negotiation, its cache 279 entry might consist of multiple stored responses, each differentiated 280 by a secondary key for the values of the original request's selecting 281 header fields (Section 4.1). 283 3. Storing Responses in Caches 285 A cache MUST NOT store a response to any request, unless: 287 o The request method is understood by the cache and defined as being 288 cacheable, and 290 o the response status code is understood by the cache, and 292 o the "no-store" cache directive (see Section 5.2) does not appear 293 in request or response header fields, and 295 o the "private" response directive (see Section 5.2.2.6) does not 296 appear in the response, if the cache is shared, and 298 o the Authorization header field (see Section 8.5.3 of [Semantics]) 299 does not appear in the request, if the cache is shared, unless the 300 response explicitly allows it (see Section 3.2), and 302 o the response either: 304 * contains an Expires header field (see Section 5.3), or 306 * contains a max-age response directive (see Section 5.2.2.8), or 308 * contains a s-maxage response directive (see Section 5.2.2.9) 309 and the cache is shared, or 311 * contains a Cache Control Extension (see Section 5.2.3) that 312 allows it to be cached, or 314 * has a status code that is defined as cacheable by default (see 315 Section 4.2.2), or 317 * contains a public response directive (see Section 5.2.2.5). 319 Note that any of the requirements listed above can be overridden by a 320 cache-control extension; see Section 5.2.3. 322 In this context, a cache has "understood" a request method or a 323 response status code if it recognizes it and implements all specified 324 caching-related behavior. 326 Note that, in normal operation, some caches will not store a response 327 that has neither a cache validator nor an explicit expiration time, 328 as such responses are not usually useful to store. However, caches 329 are not prohibited from storing such responses. 331 3.1. Storing Incomplete Responses 333 A response message is considered complete when all of the octets 334 indicated by the message framing ([Messaging]) are received prior to 335 the connection being closed. If the request method is GET, the 336 response status code is 200 (OK), and the entire response header 337 section has been received, a cache MAY store an incomplete response 338 message body if the cache entry is recorded as incomplete. Likewise, 339 a 206 (Partial Content) response MAY be stored as if it were an 340 incomplete 200 (OK) cache entry. However, a cache MUST NOT store 341 incomplete or partial-content responses if it does not support the 342 Range and Content-Range header fields or if it does not understand 343 the range units used in those fields. 345 A cache MAY complete a stored incomplete response by making a 346 subsequent range request (Section 8.3 of [Semantics]) and combining 347 the successful response with the stored entry, as defined in 348 Section 3.3. A cache MUST NOT use an incomplete response to answer 349 requests unless the response has been made complete or the request is 350 partial and specifies a range that is wholly within the incomplete 351 response. A cache MUST NOT send a partial response to a client 352 without explicitly marking it as such using the 206 (Partial Content) 353 status code. 355 3.2. Storing Responses to Authenticated Requests 357 A shared cache MUST NOT use a cached response to a request with an 358 Authorization header field (Section 8.5.3 of [Semantics]) to satisfy 359 any subsequent request unless a cache directive that allows such 360 responses to be stored is present in the response. 362 In this specification, the following Cache-Control response 363 directives (Section 5.2.2) have such an effect: must-revalidate, 364 public, and s-maxage. 366 Note that cached responses that contain the "must-revalidate" and/or 367 "s-maxage" response directives are not allowed to be served stale 368 (Section 4.2.4) by shared caches. In particular, a response with 369 either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to 370 satisfy a subsequent request without revalidating it on the origin 371 server. 373 3.3. Combining Partial Content 375 A response might transfer only a partial representation if the 376 connection closed prematurely or if the request used one or more 377 Range specifiers (Section 8.3 of [Semantics]). After several such 378 transfers, a cache might have received several ranges of the same 379 representation. A cache MAY combine these ranges into a single 380 stored response, and reuse that response to satisfy later requests, 381 if they all share the same strong validator and the cache complies 382 with the client requirements in Section 9.3.7.3 of [Semantics]. 384 When combining the new response with one or more stored responses, a 385 cache MUST: 387 o delete any Warning header fields in the stored response with warn- 388 code 1xx (see Section 5.5); 390 o retain any Warning header fields in the stored response with warn- 391 code 2xx; and, 393 o use other header fields provided in the new response, aside from 394 Content-Range, to replace all instances of the corresponding 395 header fields in the stored response. 397 4. Constructing Responses from Caches 399 When presented with a request, a cache MUST NOT reuse a stored 400 response, unless: 402 o The presented effective request URI (Section 5.3 of [Semantics]) 403 and that of the stored response match, and 405 o the request method associated with the stored response allows it 406 to be used for the presented request, and 408 o selecting header fields nominated by the stored response (if any) 409 match those presented (see Section 4.1), and 411 o the presented request does not contain the no-cache pragma 412 (Section 5.4), nor the no-cache cache directive (Section 5.2.1), 413 unless the stored response is successfully validated 414 (Section 4.3), and 416 o the stored response does not contain the no-cache cache directive 417 (Section 5.2.2.2), unless it is successfully validated 418 (Section 4.3), and 420 o the stored response is either: 422 * fresh (see Section 4.2), or 424 * allowed to be served stale (see Section 4.2.4), or 426 * successfully validated (see Section 4.3). 428 Note that any of the requirements listed above can be overridden by a 429 cache-control extension; see Section 5.2.3. 431 When a stored response is used to satisfy a request without 432 validation, a cache MUST generate an Age header field (Section 5.1), 433 replacing any present in the response with a value equal to the 434 stored response's current_age; see Section 4.2.3. 436 A cache MUST write through requests with methods that are unsafe 437 (Section 7.2.1 of [Semantics]) to the origin server; i.e., a cache is 438 not allowed to generate a reply to such a request before having 439 forwarded the request and having received a corresponding response. 441 Also, note that unsafe requests might invalidate already-stored 442 responses; see Section 4.4. 444 When more than one suitable response is stored, a cache MUST use the 445 most recent response (as determined by the Date header field). It 446 can also forward the request with "Cache-Control: max-age=0" or 447 "Cache-Control: no-cache" to disambiguate which response to use. 449 A cache that does not have a clock available MUST NOT use stored 450 responses without revalidating them upon every use. 452 4.1. Calculating Secondary Keys with Vary 454 When a cache receives a request that can be satisfied by a stored 455 response that has a Vary header field (Section 10.1.4 of 456 [Semantics]), it MUST NOT use that response unless all of the 457 selecting header fields nominated by the Vary header field match in 458 both the original request (i.e., that associated with the stored 459 response), and the presented request. 461 The selecting header fields from two requests are defined to match if 462 and only if those in the first request can be transformed to those in 463 the second request by applying any of the following: 465 o adding or removing whitespace, where allowed in the header field's 466 syntax 468 o combining multiple header fields with the same field name (see 469 Section 4.2 of [Semantics]) 471 o normalizing both header field values in a way that is known to 472 have identical semantics, according to the header field's 473 specification (e.g., reordering field values when order is not 474 significant; case-normalization, where values are defined to be 475 case-insensitive) 477 If (after any normalization that might take place) a header field is 478 absent from a request, it can only match another request if it is 479 also absent there. 481 A Vary header field-value of "*" always fails to match. 483 The stored response with matching selecting header fields is known as 484 the selected response. 486 If multiple selected responses are available (potentially including 487 responses without a Vary header field), the cache will need to choose 488 one to use. When a selecting header field has a known mechanism for 489 doing so (e.g., qvalues on Accept and similar request header fields), 490 that mechanism MAY be used to select preferred responses; of the 491 remainder, the most recent response (as determined by the Date header 492 field) is used, as per Section 4. 494 If no selected response is available, the cache cannot satisfy the 495 presented request. Typically, it is forwarded to the origin server 496 in a (possibly conditional; see Section 4.3) request. 498 4.2. Freshness 500 A fresh response is one whose age has not yet exceeded its freshness 501 lifetime. Conversely, a stale response is one where it has. 503 A response's freshness lifetime is the length of time between its 504 generation by the origin server and its expiration time. An explicit 505 expiration time is the time at which the origin server intends that a 506 stored response can no longer be used by a cache without further 507 validation, whereas a heuristic expiration time is assigned by a 508 cache when no explicit expiration time is available. 510 A response's age is the time that has passed since it was generated 511 by, or successfully validated with, the origin server. 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 5.3) or the max-age response 520 directive (Section 5.2.2.8). Generally, origin servers will assign 521 future explicit expiration times to responses in the belief that the 522 representation is not likely to change in a semantically significant 523 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 a stale cached response before reusing it for 529 subsequent requests (see Section 4.2.4). 531 Since origin servers do not always provide explicit expiration times, 532 caches are also allowed to use a heuristic to determine an expiration 533 time under certain circumstances (see Section 4.2.2). 535 The calculation to determine if a response is fresh is: 537 response_is_fresh = (freshness_lifetime > current_age) 539 freshness_lifetime is defined in Section 4.2.1; current_age is 540 defined in Section 4.2.3. 542 Clients can send the max-age or min-fresh cache directives in a 543 request to constrain or relax freshness calculations for the 544 corresponding response (Section 5.2.1). 546 When calculating freshness, to avoid common problems in date parsing: 548 o Although all date formats are specified to be case-sensitive, a 549 cache recipient SHOULD match day, week, and time-zone names case- 550 insensitively. 552 o If a cache recipient's internal implementation of time has less 553 resolution than the value of an HTTP-date, the recipient MUST 554 internally represent a parsed Expires date as the nearest time 555 equal to or earlier than the received value. 557 o A cache recipient MUST NOT allow local time zones to influence the 558 calculation or comparison of an age or expiration time. 560 o A cache recipient SHOULD consider a date with a zone abbreviation 561 other than GMT or UTC to be invalid for calculating expiration. 563 Note that freshness applies only to cache operation; it cannot be 564 used to force a user agent to refresh its display or reload a 565 resource. See Section 6 for an explanation of the difference between 566 caches and history mechanisms. 568 4.2.1. Calculating Freshness Lifetime 570 A cache can calculate the freshness lifetime (denoted as 571 freshness_lifetime) of a response by using the first match of the 572 following: 574 o If the cache is shared and the s-maxage response directive 575 (Section 5.2.2.9) is present, use its value, or 577 o If the max-age response directive (Section 5.2.2.8) is present, 578 use its value, or 580 o If the Expires response header field (Section 5.3) is present, use 581 its value minus the value of the Date response header field, or 583 o Otherwise, no explicit expiration time is present in the response. 584 A heuristic freshness lifetime might be applicable; see 585 Section 4.2.2. 587 Note that this calculation is not vulnerable to clock skew, since all 588 of the information comes from the origin server. 590 When there is more than one value present for a given directive 591 (e.g., two Expires header fields, multiple Cache-Control: max-age 592 directives), the directive's value is considered invalid. Caches are 593 encouraged to consider responses that have invalid freshness 594 information to be stale. 596 4.2.2. Calculating Heuristic Freshness 598 Since origin servers do not always provide explicit expiration times, 599 a cache MAY assign a heuristic expiration time when an explicit time 600 is not specified, employing algorithms that use other header field 601 values (such as the Last-Modified time) to estimate a plausible 602 expiration time. This specification does not provide specific 603 algorithms, but does impose worst-case constraints on their results. 605 A cache MUST NOT use heuristics to determine freshness when an 606 explicit expiration time is present in the stored response. Because 607 of the requirements in Section 3, this means that, effectively, 608 heuristics can only be used on responses without explicit freshness 609 whose status codes are defined as cacheable by default (see 610 Section 9.1 of [Semantics]), and those responses without explicit 611 freshness that have been marked as explicitly cacheable (e.g., with a 612 "public" response directive). 614 If the response has a Last-Modified header field (Section 10.2.2 of 615 [Semantics]), caches are encouraged to use a heuristic expiration 616 value that is no more than some fraction of the interval since that 617 time. A typical setting of this fraction might be 10%. 619 When a heuristic is used to calculate freshness lifetime, a cache 620 SHOULD generate a Warning header field with a 113 warn-code (see 621 Section 5.5.4) in the response if its current_age is more than 24 622 hours and such a warning is not already present. 624 Note: Section 13.9 of [RFC2616] prohibited caches from calculating 625 heuristic freshness for URIs with query components (i.e., those 626 containing '?'). In practice, this has not been widely 627 implemented. Therefore, origin servers are encouraged to send 628 explicit directives (e.g., Cache-Control: no-cache) if they wish 629 to preclude caching. 631 4.2.3. Calculating Age 633 The Age header field is used to convey an estimated age of the 634 response message when obtained from a cache. The Age field value is 635 the cache's estimate of the number of seconds since the response was 636 generated or validated by the origin server. In essence, the Age 637 value is the sum of the time that the response has been resident in 638 each of the caches along the path from the origin server, plus the 639 amount of time it has been in transit along network paths. 641 The following data is used for the age calculation: 643 age_value 644 The term "age_value" denotes the value of the Age header field 645 (Section 5.1), in a form appropriate for arithmetic operation; or 646 0, if not available. 648 date_value 649 The term "date_value" denotes the value of the Date header field, 650 in a form appropriate for arithmetic operations. See 651 Section 10.1.1.2 of [Semantics] for the definition of the Date 652 header field, and for requirements regarding responses without it. 654 now 655 The term "now" means "the current value of the clock at the host 656 performing the calculation". A host ought to use NTP ([RFC5905]) 657 or some similar protocol to synchronize its clocks to Coordinated 658 Universal Time. 660 request_time 661 The current value of the clock at the host at the time the request 662 resulting in the stored response was made. 664 response_time 665 The current value of the clock at the host at the time the 666 response was received. 668 A response's age can be calculated in two entirely independent ways: 670 1. the "apparent_age": response_time minus date_value, if the local 671 clock is reasonably well synchronized to the origin server's 672 clock. If the result is negative, the result is replaced by 673 zero. 675 2. the "corrected_age_value", if all of the caches along the 676 response path implement HTTP/1.1. A cache MUST interpret this 677 value relative to the time the request was initiated, not the 678 time that the response was received. 680 apparent_age = max(0, response_time - date_value); 682 response_delay = response_time - request_time; 683 corrected_age_value = age_value + response_delay; 685 These are combined as 687 corrected_initial_age = max(apparent_age, corrected_age_value); 689 unless the cache is confident in the value of the Age header field 690 (e.g., because there are no HTTP/1.0 hops in the Via header field), 691 in which case the corrected_age_value MAY be used as the 692 corrected_initial_age. 694 The current_age of a stored response can then be calculated by adding 695 the amount of time (in seconds) since the stored response was last 696 validated by the origin server to the corrected_initial_age. 698 resident_time = now - response_time; 699 current_age = corrected_initial_age + resident_time; 701 4.2.4. 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 4.2. 707 A cache MUST NOT generate 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 5.2.2). 713 A cache MUST NOT send 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 5.2.1). 718 A cache SHOULD generate a Warning header field with the 110 warn-code 719 (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD 720 generate a 112 warn-code (see Section 5.5.3) in stale responses if 721 the cache is disconnected. 723 A cache SHOULD NOT generate a new Warning header field when 724 forwarding a response that does not have an Age header field, even if 725 the response is already stale. A cache need not validate a response 726 that merely became stale in transit. 728 4.3. Validation 730 When a cache has one or more stored responses for a requested URI, 731 but cannot serve any of them (e.g., because they are not fresh, or 732 one cannot be selected; see Section 4.1), it can use the conditional 733 request mechanism Section 8.2 of [Semantics] in the forwarded request 734 to give the next inbound server an opportunity to select a valid 735 stored response to use, updating the stored metadata in the process, 736 or to replace the stored response(s) with a new response. This 737 process is known as "validating" or "revalidating" the stored 738 response. 740 4.3.1. Sending a Validation Request 742 When sending a conditional request for cache validation, a cache 743 sends one or more precondition header fields containing validator 744 metadata from its stored response(s), which is then compared by 745 recipients to determine whether a stored response is equivalent to a 746 current representation of the resource. 748 One such validator is the timestamp given in a Last-Modified header 749 field (Section 10.2.2 of [Semantics]), which can be used in an If- 750 Modified-Since header field for response validation, or in an If- 751 Unmodified-Since or If-Range header field for representation 752 selection (i.e., the client is referring specifically to a previously 753 obtained representation with that timestamp). 755 Another validator is the entity-tag given in an ETag header field 756 (Section 10.2.3 of [Semantics]). One or more entity-tags, indicating 757 one or more stored responses, can be used in an If-None-Match header 758 field for response validation, or in an If-Match or If-Range header 759 field for representation selection (i.e., the client is referring 760 specifically to one or more previously obtained representations with 761 the listed entity-tags). 763 4.3.2. Handling a Received Validation Request 765 Each client in the request chain may have its own cache, so it is 766 common for a cache at an intermediary to receive conditional requests 767 from other (outbound) caches. Likewise, some user agents make use of 768 conditional requests to limit data transfers to recently modified 769 representations or to complete the transfer of a partially retrieved 770 representation. 772 If a cache receives a request that can be satisfied by reusing one of 773 its stored 200 (OK) or 206 (Partial Content) responses, the cache 774 SHOULD evaluate any applicable conditional header field preconditions 775 received in that request with respect to the corresponding validators 776 contained within the selected response. A cache MUST NOT evaluate 777 conditional header fields that are only applicable to an origin 778 server, found in a request with semantics that cannot be satisfied 779 with a cached response, or applied to a target resource for which it 780 has no stored responses; such preconditions are likely intended for 781 some other (inbound) server. 783 The proper evaluation of conditional requests by a cache depends on 784 the received precondition header fields and their precedence, as 785 defined in Section 8.2.2 of [Semantics]. The If-Match and If- 786 Unmodified-Since conditional header fields are not applicable to a 787 cache. 789 A request containing an If-None-Match header field (Section 8.2.4 of 790 [Semantics]) indicates that the client wants to validate one or more 791 of its own stored responses in comparison to whichever stored 792 response is selected by the cache. If the field-value is "*", or if 793 the field-value is a list of entity-tags and at least one of them 794 matches the entity-tag of the selected stored response, a cache 795 recipient SHOULD generate a 304 (Not Modified) response (using the 796 metadata of the selected stored response) instead of sending that 797 stored response. 799 When a cache decides to revalidate its own stored responses for a 800 request that contains an If-None-Match list of entity-tags, the cache 801 MAY combine the received list with a list of entity-tags from its own 802 stored set of responses (fresh or stale) and send the union of the 803 two lists as a replacement If-None-Match header field value in the 804 forwarded request. If a stored response contains only partial 805 content, the cache MUST NOT include its entity-tag in the union 806 unless the request is for a range that would be fully satisfied by 807 that partial stored response. If the response to the forwarded 808 request is 304 (Not Modified) and has an ETag header field value with 809 an entity-tag that is not in the client's list, the cache MUST 810 generate a 200 (OK) response for the client by reusing its 811 corresponding stored response, as updated by the 304 response 812 metadata (Section 4.3.4). 814 If an If-None-Match header field is not present, a request containing 815 an If-Modified-Since header field (Section 8.2.5 of [Semantics]) 816 indicates that the client wants to validate one or more of its own 817 stored responses by modification date. A cache recipient SHOULD 818 generate a 304 (Not Modified) response (using the metadata of the 819 selected stored response) if one of the following cases is true: 1) 820 the selected stored response has a Last-Modified field-value that is 821 earlier than or equal to the conditional timestamp; 2) no Last- 822 Modified field is present in the selected stored response, but it has 823 a Date field-value that is earlier than or equal to the conditional 824 timestamp; or, 3) neither Last-Modified nor Date is present in the 825 selected stored response, but the cache recorded it as having been 826 received at a time earlier than or equal to the conditional 827 timestamp. 829 A cache that implements partial responses to range requests, as 830 defined in Section 8.3 of [Semantics], also needs to evaluate a 831 received If-Range header field (Section 8.2.7 of [Semantics]) with 832 respect to its selected stored response. 834 4.3.3. Handling a Validation Response 836 Cache handling of a response to a conditional request is dependent 837 upon its status code: 839 o A 304 (Not Modified) response status code indicates that the 840 stored response can be updated and reused; see Section 4.3.4. 842 o A full response (i.e., one with a payload body) indicates that 843 none of the stored responses nominated in the conditional request 844 is suitable. Instead, the cache MUST use the full response to 845 satisfy the request and MAY replace the stored response(s). 847 o However, if a cache receives a 5xx (Server Error) response while 848 attempting to validate a response, it can either forward this 849 response to the requesting client, or act as if the server failed 850 to respond. In the latter case, the cache MAY send a previously 851 stored response (see Section 4.2.4). 853 4.3.4. Freshening Stored Responses upon Validation 855 When a cache receives a 304 (Not Modified) response and already has 856 one or more stored 200 (OK) responses for the same cache key, the 857 cache needs to identify which of the stored responses are updated by 858 this new response and then update the stored response(s) with the new 859 information provided in the 304 response. 861 The stored response to update is identified by using the first match 862 (if any) of the following: 864 o If the new response contains a strong validator (see 865 Section 10.2.1 of [Semantics]), then that strong validator 866 identifies the selected representation for update. All of the 867 stored responses with the same strong validator are selected. If 868 none of the stored responses contain the same strong validator, 869 then the cache MUST NOT use the new response to update any stored 870 responses. 872 o If the new response contains a weak validator and that validator 873 corresponds to one of the cache's stored responses, then the most 874 recent of those matching stored responses is selected for update. 876 o If the new response does not include any form of validator (such 877 as in the case where a client generates an If-Modified-Since 878 request from a source other than the Last-Modified response header 879 field), and there is only one stored response, and that stored 880 response also lacks a validator, then that stored response is 881 selected for update. 883 If a stored response is selected for update, the cache MUST: 885 o delete any Warning header fields in the stored response with warn- 886 code 1xx (see Section 5.5); 888 o retain any Warning header fields in the stored response with warn- 889 code 2xx; and, 891 o use other header fields provided in the 304 (Not Modified) 892 response to replace all instances of the corresponding header 893 fields in the stored response. 895 4.3.5. Freshening Responses via HEAD 897 A response to the HEAD method is identical to what an equivalent 898 request made with a GET would have been, except it lacks a body. 899 This property of HEAD responses can be used to invalidate or update a 900 cached GET response if the more efficient conditional GET request 901 mechanism is not available (due to no validators being present in the 902 stored response) or if transmission of the representation body is not 903 desired even if it has changed. 905 When a cache makes an inbound HEAD request for a given request target 906 and receives a 200 (OK) response, the cache SHOULD update or 907 invalidate each of its stored GET responses that could have been 908 selected for that request (see Section 4.1). 910 For each of the stored responses that could have been selected, if 911 the stored response and HEAD response have matching values for any 912 received validator fields (ETag and Last-Modified) and, if the HEAD 913 response has a Content-Length header field, the value of Content- 914 Length matches that of the stored response, the cache SHOULD update 915 the stored response as described below; otherwise, the cache SHOULD 916 consider the stored response to be stale. 918 If a cache updates a stored response with the metadata provided in a 919 HEAD response, the cache MUST: 921 o delete any Warning header fields in the stored response with warn- 922 code 1xx (see Section 5.5); 924 o retain any Warning header fields in the stored response with warn- 925 code 2xx; and, 927 o use other header fields provided in the HEAD response to replace 928 all instances of the corresponding header fields in the stored 929 response and append new header fields to the stored response's 930 header section unless otherwise restricted by the Cache-Control 931 header field. 933 4.4. Invalidation 935 Because unsafe request methods (Section 7.2.1 of [Semantics]) such as 936 PUT, POST or DELETE have the potential for changing state on the 937 origin server, intervening caches can use them to keep their contents 938 up to date. 940 A cache MUST invalidate the effective Request URI (Section 5.3 of 941 [Semantics]) as well as the URI(s) in the Location and Content- 942 Location response header fields (if present) when a non-error status 943 code is received in response to an unsafe request method. 945 However, a cache MUST NOT invalidate a URI from a Location or 946 Content-Location response header field if the host part of that URI 947 differs from the host part in the effective request URI (Section 5.3 948 of [Semantics]). This helps prevent denial-of-service attacks. 950 A cache MUST invalidate the effective request URI (Section 5.3 of 951 [Semantics]) when it receives a non-error response to a request with 952 a method whose safety is unknown. 954 Here, a "non-error response" is one with a 2xx (Successful) or 3xx 955 (Redirection) status code. "Invalidate" means that the cache will 956 either remove all stored responses related to the effective request 957 URI or will mark these as "invalid" and in need of a mandatory 958 validation before they can be sent in response to a subsequent 959 request. 961 Note that this does not guarantee that all appropriate responses are 962 invalidated. For example, a state-changing request might invalidate 963 responses in the caches it travels through, but relevant responses 964 still might be stored in other caches that it has not. 966 5. Header Field Definitions 968 This section defines the syntax and semantics of HTTP/1.1 header 969 fields related to caching. 971 +-------------------+----------+----------+--------------+ 972 | Header Field Name | Protocol | Status | Reference | 973 +-------------------+----------+----------+--------------+ 974 | Age | http | standard | Section 5.1 | 975 | Cache-Control | http | standard | Section 5.2 | 976 | Expires | http | standard | Section 5.3 | 977 | Pragma | http | standard | Section 5.4 | 978 | Warning | http | standard | Section 5.5 | 979 +-------------------+----------+----------+--------------+ 981 5.1. Age 983 The "Age" header field conveys the sender's estimate of the amount of 984 time since the response was generated or successfully validated at 985 the origin server. Age values are calculated as specified in 986 Section 4.2.3. 988 Age = delta-seconds 990 The Age field-value is a non-negative integer, representing time in 991 seconds (see Section 1.3). 993 The presence of an Age header field implies that the response was not 994 generated or validated by the origin server for this request. 995 However, lack of an Age header field does not imply the origin was 996 contacted, since the response might have been received from an 997 HTTP/1.0 cache that does not implement Age. 999 5.2. Cache-Control 1001 The "Cache-Control" header field is used to specify directives for 1002 caches along the request/response chain. Such cache directives are 1003 unidirectional in that the presence of a directive in a request does 1004 not imply that the same directive is to be given in the response. 1006 A cache MUST obey the requirements of the Cache-Control directives 1007 defined in this section. See Section 5.2.3 for information about how 1008 Cache-Control directives defined elsewhere are handled. 1010 Note: Some HTTP/1.0 caches might not implement Cache-Control. 1012 A proxy, whether or not it implements a cache, MUST pass cache 1013 directives through in forwarded messages, regardless of their 1014 significance to that application, since the directives might be 1015 applicable to all recipients along the request/response chain. It is 1016 not possible to target a directive to a specific cache. 1018 Cache directives are identified by a token, to be compared case- 1019 insensitively, and have an optional argument, that can use both token 1020 and quoted-string syntax. For the directives defined below that 1021 define arguments, recipients ought to accept both forms, even if one 1022 is documented to be preferred. For any directive not defined by this 1023 specification, a recipient MUST accept both forms. 1025 Cache-Control = 1#cache-directive 1027 cache-directive = token [ "=" ( token / quoted-string ) ] 1029 For the cache directives defined below, no argument is defined (nor 1030 allowed) unless stated otherwise. 1032 +------------------------+-----------------------------------+ 1033 | Cache Directive | Reference | 1034 +------------------------+-----------------------------------+ 1035 | max-age | Section 5.2.1.1, Section 5.2.2.8 | 1036 | max-stale | Section 5.2.1.2 | 1037 | min-fresh | Section 5.2.1.3 | 1038 | must-revalidate | Section 5.2.2.1 | 1039 | no-cache | Section 5.2.1.4, Section 5.2.2.2 | 1040 | no-store | Section 5.2.1.5, Section 5.2.2.3 | 1041 | no-transform | Section 5.2.1.6, Section 5.2.2.4 | 1042 | only-if-cached | Section 5.2.1.7 | 1043 | private | Section 5.2.2.6 | 1044 | proxy-revalidate | Section 5.2.2.7 | 1045 | public | Section 5.2.2.5 | 1046 | s-maxage | Section 5.2.2.9 | 1047 | stale-if-error | [RFC5861], Section 4 | 1048 | stale-while-revalidate | [RFC5861], Section 3 | 1049 +------------------------+-----------------------------------+ 1051 5.2.1. Request Cache-Control Directives 1053 5.2.1.1. max-age 1055 Argument syntax: 1057 delta-seconds (see Section 1.3) 1059 The "max-age" request directive indicates that the client is 1060 unwilling to accept a response whose age is greater than the 1061 specified number of seconds. Unless the max-stale request directive 1062 is also present, the client is not willing to accept a stale 1063 response. 1065 This directive uses the token form of the argument syntax: e.g., 1066 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the 1067 quoted-string form. 1069 5.2.1.2. max-stale 1071 Argument syntax: 1073 delta-seconds (see Section 1.3) 1075 The "max-stale" request directive indicates that the client is 1076 willing to accept a response that has exceeded its freshness 1077 lifetime. If max-stale is assigned a value, then the client is 1078 willing to accept a response that has exceeded its freshness lifetime 1079 by no more than the specified number of seconds. If no value is 1080 assigned to max-stale, then the client is willing to accept a stale 1081 response of any age. 1083 This directive uses the token form of the argument syntax: e.g., 1084 'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate 1085 the quoted-string form. 1087 5.2.1.3. min-fresh 1089 Argument syntax: 1091 delta-seconds (see Section 1.3) 1093 The "min-fresh" request directive indicates that the client is 1094 willing to accept a response whose freshness lifetime is no less than 1095 its current age plus the specified time in seconds. That is, the 1096 client wants a response that will still be fresh for at least the 1097 specified number of seconds. 1099 This directive uses the token form of the argument syntax: e.g., 1100 'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate 1101 the quoted-string form. 1103 5.2.1.4. no-cache 1105 The "no-cache" request directive indicates that a cache MUST NOT use 1106 a stored response to satisfy the request without successful 1107 validation on the origin server. 1109 5.2.1.5. no-store 1111 The "no-store" request directive indicates that a cache MUST NOT 1112 store any part of either this request or any response to it. This 1113 directive applies to both private and shared caches. "MUST NOT 1114 store" in this context means that the cache MUST NOT intentionally 1115 store the information in non-volatile storage, and MUST make a best- 1116 effort attempt to remove the information from volatile storage as 1117 promptly as possible after forwarding it. 1119 This directive is NOT a reliable or sufficient mechanism for ensuring 1120 privacy. In particular, malicious or compromised caches might not 1121 recognize or obey this directive, and communications networks might 1122 be vulnerable to eavesdropping. 1124 Note that if a request containing this directive is satisfied from a 1125 cache, the no-store request directive does not apply to the already 1126 stored response. 1128 5.2.1.6. no-transform 1130 The "no-transform" request directive indicates that an intermediary 1131 (whether or not it implements a cache) MUST NOT transform the 1132 payload, as defined in Section 5.6.2 of [Semantics]. 1134 5.2.1.7. only-if-cached 1136 The "only-if-cached" request directive indicates that the client only 1137 wishes to obtain a stored response. If it receives this directive, a 1138 cache SHOULD either respond using a stored response that is 1139 consistent with the other constraints of the request, or respond with 1140 a 504 (Gateway Timeout) status code. If a group of caches is being 1141 operated as a unified system with good internal connectivity, a 1142 member cache MAY forward such a request within that group of caches. 1144 5.2.2. Response Cache-Control Directives 1146 5.2.2.1. must-revalidate 1148 The "must-revalidate" response directive indicates that once it has 1149 become stale, a cache MUST NOT use the response to satisfy subsequent 1150 requests without successful validation on the origin server. 1152 The must-revalidate directive is necessary to support reliable 1153 operation for certain protocol features. In all circumstances a 1154 cache MUST obey the must-revalidate directive; in particular, if a 1155 cache cannot reach the origin server for any reason, it MUST generate 1156 a 504 (Gateway Timeout) response. 1158 The must-revalidate directive ought to be used by servers if and only 1159 if failure to validate a request on the representation could result 1160 in incorrect operation, such as a silently unexecuted financial 1161 transaction. 1163 5.2.2.2. no-cache 1165 Argument syntax: 1167 #field-name 1169 The "no-cache" response directive indicates that the response MUST 1170 NOT be used to satisfy a subsequent request without successful 1171 validation on the origin server. This allows an origin server to 1172 prevent a cache from using it to satisfy a request without contacting 1173 it, even by caches that have been configured to send stale responses. 1175 If the no-cache response directive specifies one or more field-names, 1176 then a cache MAY use the response to satisfy a subsequent request, 1177 subject to any other restrictions on caching. However, any header 1178 fields in the response that have the field-name(s) listed MUST NOT be 1179 sent in the response to a subsequent request without successful 1180 revalidation with the origin server. This allows an origin server to 1181 prevent the re-use of certain header fields in a response, while 1182 still allowing caching of the rest of the response. 1184 The field-names given are not limited to the set of header fields 1185 defined by this specification. Field names are case-insensitive. 1187 This directive uses the quoted-string form of the argument syntax. A 1188 sender SHOULD NOT generate the token form (even if quoting appears 1189 not to be needed for single-entry lists). 1191 Note: Although it has been back-ported to many implementations, some 1192 HTTP/1.0 caches will not recognize or obey this directive. Also, no- 1193 cache response directives with field-names are often handled by 1194 caches as if an unqualified no-cache directive was received; i.e., 1195 the special handling for the qualified form is not widely 1196 implemented. 1198 5.2.2.3. no-store 1200 The "no-store" response directive indicates that a cache MUST NOT 1201 store any part of either the immediate request or response. This 1202 directive applies to both private and shared caches. "MUST NOT 1203 store" in this context means that the cache MUST NOT intentionally 1204 store the information in non-volatile storage, and MUST make a best- 1205 effort attempt to remove the information from volatile storage as 1206 promptly as possible after forwarding it. 1208 This directive is NOT a reliable or sufficient mechanism for ensuring 1209 privacy. In particular, malicious or compromised caches might not 1210 recognize or obey this directive, and communications networks might 1211 be vulnerable to eavesdropping. 1213 5.2.2.4. no-transform 1215 The "no-transform" response directive indicates that an intermediary 1216 (regardless of whether it implements a cache) MUST NOT transform the 1217 payload, as defined in Section 5.6.2 of [Semantics]. 1219 5.2.2.5. public 1221 The "public" response directive indicates that any cache MAY store 1222 the response, even if the response would normally be non-cacheable or 1223 cacheable only within a private cache. (See Section 3.2 for 1224 additional details related to the use of public in response to a 1225 request containing Authorization, and Section 3 for details of how 1226 public affects responses that would normally not be stored, due to 1227 their status codes not being defined as cacheable by default; see 1228 Section 4.2.2.) 1230 5.2.2.6. private 1232 Argument syntax: 1234 #field-name 1236 The "private" response directive indicates that the response message 1237 is intended for a single user and MUST NOT be stored by a shared 1238 cache. A private cache MAY store the response and reuse it for later 1239 requests, even if the response would normally be non-cacheable. 1241 If the private response directive specifies one or more field-names, 1242 this requirement is limited to the field-values associated with the 1243 listed response header fields. That is, a shared cache MUST NOT 1244 store the specified field-names(s), whereas it MAY store the 1245 remainder of the response message. 1247 The field-names given are not limited to the set of header fields 1248 defined by this specification. Field names are case-insensitive. 1250 This directive uses the quoted-string form of the argument syntax. A 1251 sender SHOULD NOT generate the token form (even if quoting appears 1252 not to be needed for single-entry lists). 1254 Note: This usage of the word "private" only controls where the 1255 response can be stored; it cannot ensure the privacy of the message 1256 content. Also, private response directives with field-names are 1257 often handled by caches as if an unqualified private directive was 1258 received; i.e., the special handling for the qualified form is not 1259 widely implemented. 1261 5.2.2.7. proxy-revalidate 1263 The "proxy-revalidate" response directive has the same meaning as the 1264 must-revalidate response directive, except that it does not apply to 1265 private caches. 1267 5.2.2.8. max-age 1269 Argument syntax: 1271 delta-seconds (see Section 1.3) 1273 The "max-age" response directive indicates that the response is to be 1274 considered stale after its age is greater than the specified number 1275 of seconds. 1277 This directive uses the token form of the argument syntax: e.g., 1278 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the 1279 quoted-string form. 1281 5.2.2.9. s-maxage 1283 Argument syntax: 1285 delta-seconds (see Section 1.3) 1287 The "s-maxage" response directive indicates that, in shared caches, 1288 the maximum age specified by this directive overrides the maximum age 1289 specified by either the max-age directive or the Expires header 1290 field. The s-maxage directive also implies the semantics of the 1291 proxy-revalidate response directive. 1293 This directive uses the token form of the argument syntax: e.g., 1294 's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the 1295 quoted-string form. 1297 5.2.3. Cache Control Extensions 1299 The Cache-Control header field can be extended through the use of one 1300 or more cache-extension tokens, each with an optional value. A cache 1301 MUST ignore unrecognized cache directives. 1303 Informational extensions (those that do not require a change in cache 1304 behavior) can be added without changing the semantics of other 1305 directives. 1307 Behavioral extensions are designed to work by acting as modifiers to 1308 the existing base of cache directives. Both the new directive and 1309 the old directive are supplied, such that applications that do not 1310 understand the new directive will default to the behavior specified 1311 by the old directive, and those that understand the new directive 1312 will recognize it as modifying the requirements associated with the 1313 old directive. In this way, extensions to the existing cache-control 1314 directives can be made without breaking deployed caches. 1316 For example, consider a hypothetical new response directive called 1317 "community" that acts as a modifier to the private directive: in 1318 addition to private caches, any cache that is shared only by members 1319 of the named community is allowed to cache the response. An origin 1320 server wishing to allow the UCI community to use an otherwise private 1321 response in their shared cache(s) could do so by including 1323 Cache-Control: private, community="UCI" 1325 A cache that recognizes such a community cache-extension could 1326 broaden its behavior in accordance with that extension. A cache that 1327 does not recognize the community cache-extension would ignore it and 1328 adhere to the private directive. 1330 New extension directives ought to consider defining: 1332 o What it means for a directive to be specified multiple times, 1334 o When the directive does not take an argument, what it means when 1335 an argument is present, 1337 o When the directive requires an argument, what it means when it is 1338 missing, 1340 o Whether the directive is specific to requests, responses, or able 1341 to be used in either. 1343 5.2.4. Cache Directive Registry 1345 The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" 1346 defines the namespace for the cache directives. It has been created 1347 and is now maintained at . 1350 A registration MUST include the following fields: 1352 o Cache Directive Name 1354 o Pointer to specification text 1356 Values to be added to this namespace require IETF Review (see 1357 [RFC8126], Section 4.8). 1359 5.3. Expires 1361 The "Expires" header field gives the date/time after which the 1362 response is considered stale. See Section 4.2 for further discussion 1363 of the freshness model. 1365 The presence of an Expires field does not imply that the original 1366 resource will change or cease to exist at, before, or after that 1367 time. 1369 The Expires value is an HTTP-date timestamp, as defined in 1370 Section 10.1.1.1 of [Semantics]. 1372 Expires = HTTP-date 1374 For example 1376 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1378 A cache recipient MUST interpret invalid date formats, especially the 1379 value "0", as representing a time in the past (i.e., "already 1380 expired"). 1382 If a response includes a Cache-Control field with the max-age 1383 directive (Section 5.2.2.8), a recipient MUST ignore the Expires 1384 field. Likewise, if a response includes the s-maxage directive 1385 (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires 1386 field. In both these cases, the value in Expires is only intended 1387 for recipients that have not yet implemented the Cache-Control field. 1389 An origin server without a clock MUST NOT generate an Expires field 1390 unless its value represents a fixed time in the past (always expired) 1391 or its value has been associated with the resource by a system or 1392 user with a reliable clock. 1394 Historically, HTTP required the Expires field-value to be no more 1395 than a year in the future. While longer freshness lifetimes are no 1396 longer prohibited, extremely large values have been demonstrated to 1397 cause problems (e.g., clock overflows due to use of 32-bit integers 1398 for time values), and many caches will evict a response far sooner 1399 than that. 1401 5.4. Pragma 1403 The "Pragma" header field allows backwards compatibility with 1404 HTTP/1.0 caches, so that clients can specify a "no-cache" request 1405 that they will understand (as Cache-Control was not defined until 1406 HTTP/1.1). When the Cache-Control header field is also present and 1407 understood in a request, Pragma is ignored. 1409 In HTTP/1.0, Pragma was defined as an extensible field for 1410 implementation-specified directives for recipients. This 1411 specification deprecates such extensions to improve interoperability. 1413 Pragma = 1#pragma-directive 1414 pragma-directive = "no-cache" / extension-pragma 1415 extension-pragma = token [ "=" ( token / quoted-string ) ] 1417 When the Cache-Control header field is not present in a request, 1418 caches MUST consider the no-cache request pragma-directive as having 1419 the same effect as if "Cache-Control: no-cache" were present (see 1420 Section 5.2.1). 1422 When sending a no-cache request, a client ought to include both the 1423 pragma and cache-control directives, unless Cache-Control: no-cache 1424 is purposefully omitted to target other Cache-Control request 1425 directives at HTTP/1.1 caches. For example: 1427 GET / HTTP/1.1 1428 Host: www.example.com 1429 Cache-Control: max-age=30 1430 Pragma: no-cache 1432 will constrain HTTP/1.1 caches to serve a response no older than 30 1433 seconds, while precluding implementations that do not understand 1434 Cache-Control from serving a cached response. 1436 Note: Because the meaning of "Pragma: no-cache" in responses is 1437 not specified, it does not provide a reliable replacement for 1438 "Cache-Control: no-cache" in them. 1440 5.5. Warning 1442 The "Warning" header field is used to carry additional information 1443 about the status or transformation of a message that might not be 1444 reflected in the status code. This information is typically used to 1445 warn about possible incorrectness introduced by caching operations or 1446 transformations applied to the payload of the message. 1448 Warnings can be used for other purposes, both cache-related and 1449 otherwise. The use of a warning, rather than an error status code, 1450 distinguishes these responses from true failures. 1452 Warning header fields can in general be applied to any message, 1453 however some warn-codes are specific to caches and can only be 1454 applied to response messages. 1456 Warning = 1#warning-value 1458 warning-value = warn-code SP warn-agent SP warn-text 1459 [ SP warn-date ] 1461 warn-code = 3DIGIT 1462 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1463 ; the name or pseudonym of the server adding 1464 ; the Warning header field, for use in debugging 1465 ; a single "-" is recommended when agent unknown 1466 warn-text = quoted-string 1467 warn-date = DQUOTE HTTP-date DQUOTE 1469 Multiple warnings can be generated in a response (either by the 1470 origin server or by a cache), including multiple warnings with the 1471 same warn-code number that only differ in warn-text. 1473 A user agent that receives one or more Warning header fields SHOULD 1474 inform the user of as many of them as possible, in the order that 1475 they appear in the response. Senders that generate multiple Warning 1476 header fields are encouraged to order them with this user agent 1477 behavior in mind. A sender that generates new Warning header fields 1478 MUST append them after any existing Warning header fields. 1480 Warnings are assigned three digit warn-codes. The first digit 1481 indicates whether the Warning is required to be deleted from a stored 1482 response after validation: 1484 o 1xx warn-codes describe the freshness or validation status of the 1485 response, and so they MUST be deleted by a cache after validation. 1486 They can only be generated by a cache when validating a cached 1487 entry, and MUST NOT be generated in any other situation. 1489 o 2xx warn-codes describe some aspect of the representation that is 1490 not rectified by a validation (for example, a lossy compression of 1491 the representation) and they MUST NOT be deleted by a cache after 1492 validation, unless a full response is sent, in which case they 1493 MUST be. 1495 If a sender generates one or more 1xx warn-codes in a message to be 1496 sent to a recipient known to implement only HTTP/1.0, the sender MUST 1497 include in each corresponding warning-value a warn-date that matches 1498 the Date header field in the message. For example: 1500 HTTP/1.1 200 OK 1501 Date: Sat, 25 Aug 2012 23:34:45 GMT 1502 Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT" 1504 Warnings have accompanying warn-text that describes the error, e.g., 1505 for logging. It is advisory only, and its content does not affect 1506 interpretation of the warn-code. 1508 If a recipient that uses, evaluates, or displays Warning header 1509 fields receives a warn-date that is different from the Date value in 1510 the same message, the recipient MUST exclude the warning-value 1511 containing that warn-date before storing, forwarding, or using the 1512 message. This allows recipients to exclude warning-values that were 1513 improperly retained after a cache validation. If all of the warning- 1514 values are excluded, the recipient MUST exclude the Warning header 1515 field as well. 1517 The following warn-codes are defined by this specification, each with 1518 a recommended warn-text in English, and a description of its meaning. 1519 The procedure for defining additional warn codes is described in 1520 Section 5.5.8. 1522 +-----------+----------------------------------+----------------+ 1523 | Warn Code | Short Description | Reference | 1524 +-----------+----------------------------------+----------------+ 1525 | 110 | Response is Stale | Section 5.5.1 | 1526 | 111 | Revalidation Failed | Section 5.5.2 | 1527 | 112 | Disconnected Operation | Section 5.5.3 | 1528 | 113 | Heuristic Expiration | Section 5.5.4 | 1529 | 199 | Miscellaneous Warning | Section 5.5.5 | 1530 | 214 | Transformation Applied | Section 5.5.6 | 1531 | 299 | Miscellaneous Persistent Warning | Section 5.5.7 | 1532 +-----------+----------------------------------+----------------+ 1534 5.5.1. Warning: 110 - "Response is Stale" 1536 A cache SHOULD generate this whenever the sent response is stale. 1538 5.5.2. Warning: 111 - "Revalidation Failed" 1540 A cache SHOULD generate this when sending a stale response because an 1541 attempt to validate the response failed, due to an inability to reach 1542 the server. 1544 5.5.3. Warning: 112 - "Disconnected Operation" 1546 A cache SHOULD generate this if it is intentionally disconnected from 1547 the rest of the network for a period of time. 1549 5.5.4. Warning: 113 - "Heuristic Expiration" 1551 A cache SHOULD generate this if it heuristically chose a freshness 1552 lifetime greater than 24 hours and the response's age is greater than 1553 24 hours. 1555 5.5.5. Warning: 199 - "Miscellaneous Warning" 1557 The warning text can include arbitrary information to be presented to 1558 a human user or logged. A system receiving this warning MUST NOT 1559 take any automated action, besides presenting the warning to the 1560 user. 1562 5.5.6. Warning: 214 - "Transformation Applied" 1564 This Warning code MUST be added by a proxy if it applies any 1565 transformation to the representation, such as changing the content- 1566 coding, media-type, or modifying the representation data, unless this 1567 Warning code already appears in the response. 1569 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" 1571 The warning text can include arbitrary information to be presented to 1572 a human user or logged. A system receiving this warning MUST NOT 1573 take any automated action. 1575 5.5.8. Warn Code Registry 1577 The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines 1578 the namespace for warn codes. It has been created and is now 1579 maintained at . 1581 A registration MUST include the following fields: 1583 o Warn Code (3 digits) 1585 o Short Description 1587 o Pointer to specification text 1589 Values to be added to this namespace require IETF Review (see 1590 [RFC8126], Section 4.8). 1592 6. History Lists 1594 User agents often have history mechanisms, such as "Back" buttons and 1595 history lists, that can be used to redisplay a representation 1596 retrieved earlier in a session. 1598 The freshness model (Section 4.2) does not necessarily apply to 1599 history mechanisms. That is, a history mechanism can display a 1600 previous representation even if it has expired. 1602 This does not prohibit the history mechanism from telling the user 1603 that a view might be stale or from honoring cache directives (e.g., 1604 Cache-Control: no-store). 1606 7. Security Considerations 1608 This section is meant to inform developers, information providers, 1609 and users of known security concerns specific to HTTP caching. More 1610 general security considerations are addressed in HTTP messaging 1611 [Messaging] and semantics [Semantics]. 1613 Caches expose additional potential vulnerabilities, since the 1614 contents of the cache represent an attractive target for malicious 1615 exploitation. Because cache contents persist after an HTTP request 1616 is complete, an attack on the cache can reveal information long after 1617 a user believes that the information has been removed from the 1618 network. Therefore, cache contents need to be protected as sensitive 1619 information. 1621 In particular, various attacks might be amplified by being stored in 1622 a shared cache; such "cache poisoning" attacks use the cache to 1623 distribute a malicious payload to many clients, and are especially 1624 effective when an attacker can use implementation flaws, elevated 1625 privileges, or other techniques to insert such a response into a 1626 cache. One common attack vector for cache poisoning is to exploit 1627 differences in message parsing on proxies and in user agents; see 1628 Section 6.3 of [Messaging] for the relevant requirements. 1630 Likewise, implementation flaws (as well as misunderstanding of cache 1631 operation) might lead to caching of sensitive information (e.g., 1632 authentication credentials) that is thought to be private, exposing 1633 it to unauthorized parties. 1635 Furthermore, the very use of a cache can bring about privacy 1636 concerns. For example, if two users share a cache, and the first one 1637 browses to a site, the second may be able to detect that the other 1638 has been to that site, because the resources from it load more 1639 quickly, thanks to the cache. 1641 Note that the Set-Cookie response header field [RFC6265] does not 1642 inhibit caching; a cacheable response with a Set-Cookie header field 1643 can be (and often is) used to satisfy subsequent requests to caches. 1644 Servers who wish to control caching of these responses are encouraged 1645 to emit appropriate Cache-Control response header fields. 1647 8. IANA Considerations 1649 The change controller for the following registrations is: "IETF 1650 (iesg@ietf.org) - Internet Engineering Task Force". 1652 8.1. Header Field Registration 1654 Please update the "Message Headers" registry of "Permanent Message 1655 Header Field Names" at with the header field names listed in the table of 1657 Section 5. 1659 8.2. Cache Directive Registration 1661 Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive 1662 Registry" at 1663 with the registration procedure of Section 5.2.4 and the cache 1664 directive names summarized in the table of Section 5.2. 1666 8.3. Warn Code Registration 1668 Please update the "Hypertext Transfer Protocol (HTTP) Warn Codes" 1669 registry at with 1670 the registration procedure of Section 5.5.8 and the warn code values 1671 summarized in the table of Section 5.5. 1673 9. References 1675 9.1. Normative References 1677 [Messaging] 1678 Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1679 Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-02 1680 (work in progress), July 2018. 1682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1683 Requirement Levels", BCP 14, RFC 2119, 1684 DOI 10.17487/RFC2119, March 1997, 1685 . 1687 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1688 Resource Identifier (URI): Generic Syntax", STD 66, 1689 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1690 . 1692 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1693 Specifications: ABNF", STD 68, RFC 5234, 1694 DOI 10.17487/RFC5234, January 2008, 1695 . 1697 [Semantics] 1698 Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1699 Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-02 1700 (work in progress), July 2018. 1702 [USASCII] American National Standards Institute, "Coded Character 1703 Set -- 7-bit American Standard Code for Information 1704 Interchange", ANSI X3.4, 1986. 1706 9.2. Informative References 1708 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1709 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1710 Transfer Protocol -- HTTP/1.1", RFC 2616, 1711 DOI 10.17487/RFC2616, June 1999, 1712 . 1714 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1715 Content", RFC 5861, DOI 10.17487/RFC5861, April 2010, 1716 . 1718 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1719 "Network Time Protocol Version 4: Protocol and Algorithms 1720 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1721 . 1723 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1724 DOI 10.17487/RFC6265, April 2011, 1725 . 1727 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1728 Ed., "Hypertext Transfer Protocol (HTTP): Caching", 1729 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1730 . 1732 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1733 Writing an IANA Considerations Section in RFCs", BCP 26, 1734 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1735 . 1737 Appendix A. Collected ABNF 1739 In the collected ABNF below, list rules are expanded as per 1740 Section 11 of [Semantics]. 1742 Age = delta-seconds 1744 Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS 1745 cache-directive ] ) 1747 Expires = HTTP-date 1749 HTTP-date = 1751 OWS = 1753 Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS 1754 pragma-directive ] ) 1756 Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] 1757 ) 1759 cache-directive = token [ "=" ( token / quoted-string ) ] 1761 delta-seconds = 1*DIGIT 1763 extension-pragma = token [ "=" ( token / quoted-string ) ] 1765 field-name = 1767 port = 1768 pragma-directive = "no-cache" / extension-pragma 1769 pseudonym = 1771 quoted-string = 1773 token = 1775 uri-host = 1777 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1778 warn-code = 3DIGIT 1779 warn-date = DQUOTE HTTP-date DQUOTE 1780 warn-text = quoted-string 1781 warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date 1782 ] 1784 Appendix B. Changes from RFC 7234 1786 None yet. 1788 Appendix C. Change Log 1790 This section is to be removed before publishing as an RFC. 1792 C.1. Between RFC7234 and draft 00 1794 The changes were purely editorial: 1796 o Change boilerplate and abstract to indicate the "draft" status, 1797 and update references to ancestor specifications. 1799 o Remove version "1.1" from document title, indicating that this 1800 specification applies to all HTTP versions. 1802 o Adjust historical notes. 1804 o Update links to sibling specifications. 1806 o Replace sections listing changes from RFC 2616 by new empty 1807 sections referring to RFC 723x. 1809 o Remove acknowledgements specific to RFC 723x. 1811 o Move "Acknowledgements" to the very end and make them unnumbered. 1813 C.2. Since draft-ietf-httpbis-cache-00 1815 The changes are purely editorial: 1817 o Moved all extensibility tips, registration procedures, and 1818 registry tables from the IANA considerations to normative 1819 sections, reducing the IANA considerations to just instructions 1820 that will be removed prior to publication as an RFC. 1822 C.3. Since draft-ietf-httpbis-cache-01 1824 o Cite RFC 8126 instead of RFC 5226 () 1827 o In Section 5.4, misleading statement about the relation between 1828 Pragma and Cache-Control (, ) 1831 Index 1833 1 1834 110 (warn-code) 33 1835 111 (warn-code) 33 1836 112 (warn-code) 33 1837 113 (warn-code) 34 1838 199 (warn-code) 34 1840 2 1841 214 (warn-code) 34 1842 299 (warn-code) 34 1844 A 1845 Age header field 21 1846 age 11 1848 C 1849 Cache-Control header field 22 1850 cache 4 1851 cache entry 6 1852 cache key 6 1854 D 1855 Disconnected Operation (warn-text) 33 1857 E 1858 Expires header field 29 1859 explicit expiration time 11 1861 F 1862 fresh 11 1863 freshness lifetime 11 1865 G 1866 Grammar 1867 Age 21 1868 ALPHA 5 1869 Cache-Control 22 1870 cache-directive 22 1871 CR 5 1872 CRLF 5 1873 CTL 5 1874 delta-seconds 5 1875 DIGIT 5 1876 DQUOTE 5 1877 Expires 30 1878 extension-pragma 31 1879 HEXDIG 5 1880 HTAB 5 1881 LF 5 1882 OCTET 5 1883 Pragma 31 1884 pragma-directive 31 1885 SP 5 1886 VCHAR 5 1887 warn-agent 32 1888 warn-code 32 1889 warn-date 32 1890 warn-text 32 1891 Warning 32 1892 warning-value 32 1894 H 1895 Heuristic Expiration (warn-text) 34 1896 heuristic expiration time 11 1898 M 1899 Miscellaneous Persistent Warning (warn-text) 34 1900 Miscellaneous Warning (warn-text) 34 1901 max-age (cache directive) 23, 28 1902 max-stale (cache directive) 23 1903 min-fresh (cache directive) 24 1904 must-revalidate (cache directive) 25 1906 N 1907 no-cache (cache directive) 24-25 1908 no-store (cache directive) 24, 26 1909 no-transform (cache directive) 25-26 1911 O 1912 only-if-cached (cache directive) 25 1914 P 1915 Pragma header field 30 1916 private (cache directive) 27 1917 private cache 4 1918 proxy-revalidate (cache directive) 27 1919 public (cache directive) 27 1921 R 1922 Response is Stale (warn-text) 33 1923 Revalidation Failed (warn-text) 33 1925 S 1926 s-maxage (cache directive) 28 1927 shared cache 4 1928 stale 11 1929 strong validator 19 1931 T 1932 Transformation Applied (warn-text) 34 1934 V 1935 validator 16 1937 W 1938 Warning header field 31 1940 Acknowledgments 1942 See Appendix "Acknowledgments" of [Semantics]. 1944 Authors' Addresses 1946 Roy T. Fielding (editor) 1947 Adobe 1948 345 Park Ave 1949 San Jose, CA 95110 1950 USA 1952 EMail: fielding@gbiv.com 1953 URI: https://roy.gbiv.com/ 1955 Mark Nottingham (editor) 1956 Fastly 1958 EMail: mnot@mnot.net 1959 URI: https://www.mnot.net/ 1961 Julian F. Reschke (editor) 1962 greenbytes GmbH 1963 Hafenweg 16 1964 Muenster, NW 48155 1965 Germany 1967 EMail: julian.reschke@greenbytes.de 1968 URI: https://greenbytes.de/tech/webdav/