idnits 2.17.1 draft-ietf-httpbis-cache-14.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 == Line 1624 has weird spacing: '...Control stan...' == 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 (January 13, 2021) is 1192 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: 'RFC7234' is defined on line 1722, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-14 -- Possible downref: Normative reference to a draft: ref. 'Messaging' == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-14 -- Possible downref: Normative reference to a draft: ref. 'Semantics' -- 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 7234 (Obsoleted by RFC 9111) Summary: 0 errors (**), 0 flaws (~~), 7 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: July 17, 2021 J. Reschke, Ed. 7 greenbytes 8 January 13, 2021 10 HTTP Caching 11 draft-ietf-httpbis-cache-14 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.15. 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 July 17, 2021. 54 Copyright Notice 56 Copyright (c) 2021 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 (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 84 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 85 1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 5 86 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6 87 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7 88 3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8 89 3.2. Updating Stored Header Fields . . . . . . . . . . . . . . 9 90 3.3. Storing Incomplete Responses . . . . . . . . . . . . . . 10 91 3.4. Combining Partial Content . . . . . . . . . . . . . . . . 10 92 3.5. Storing Responses to Authenticated Requests . . . . . . . 10 93 4. Constructing Responses from Caches . . . . . . . . . . . . . 11 94 4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 12 95 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 13 96 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 15 97 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 15 98 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 16 99 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 17 100 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 18 101 4.3.1. Sending a Validation Request . . . . . . . . . . . . 18 102 4.3.2. Handling a Received Validation Request . . . . . . . 19 103 4.3.3. Handling a Validation Response . . . . . . . . . . . 20 104 4.3.4. Freshening Stored Responses upon Validation . . . . . 21 105 4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 21 106 4.4. Invalidating Stored Responses . . . . . . . . . . . . . . 22 107 5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 23 108 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23 110 5.2.1. Request Cache-Control Directives . . . . . . . . . . 24 111 5.2.2. Response Cache-Control Directives . . . . . . . . . . 26 112 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30 113 5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31 114 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32 116 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33 117 6. Relationship to Applications and Other Caches . . . . . . . . 33 118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 119 7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34 120 7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34 121 7.3. Caching of Sensitive Information . . . . . . . . . . . . 35 122 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 123 8.1. Field Name Registration . . . . . . . . . . . . . . . . . 35 124 8.2. Cache Directive Registration . . . . . . . . . . . . . . 35 125 8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 36 126 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 127 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 128 9.2. Informative References . . . . . . . . . . . . . . . . . 37 129 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 130 Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 38 131 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 39 132 C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 39 133 C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 39 134 C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 40 135 C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 40 136 C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 40 137 C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 41 138 C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 41 139 C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 41 140 C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 42 141 C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 42 142 C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 42 143 C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 42 144 C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 42 145 C.14. Since draft-ietf-httpbis-cache-12 . . . . . . . . . . . . 42 146 C.15. Since draft-ietf-httpbis-cache-13 . . . . . . . . . . . . 44 147 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 44 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 150 1. Introduction 152 The Hypertext Transfer Protocol (HTTP) is a stateless application- 153 level request/response protocol that uses extensible semantics and 154 self-descriptive messages for flexible interaction with network-based 155 hypertext information systems. It is typically used for distributed 156 information systems, where the use of response caches can improve 157 performance. This document defines aspects of HTTP related to 158 caching and reusing response messages. 160 An HTTP _cache_ is a local store of response messages and the 161 subsystem that controls storage, retrieval, and deletion of messages 162 in it. A cache stores cacheable responses to reduce the response 163 time and network bandwidth consumption on future equivalent requests. 164 Any client or server MAY use a cache, though not when acting as a 165 tunnel. 167 A _shared cache_ is a cache that stores responses for reuse by more 168 than one user; shared caches are usually (but not always) deployed as 169 a part of an intermediary. A _private cache_, in contrast, is 170 dedicated to a single user; often, they are deployed as a component 171 of a user agent. 173 HTTP caching's goal is significantly improving performance by reusing 174 a prior response message to satisfy a current request. A cache 175 considers a stored response "fresh", as defined in Section 4.2, if it 176 can be reused without "validation" (checking with the origin server 177 to see if the cached response remains valid for this request). A 178 fresh response can therefore reduce both latency and network overhead 179 each time the cache reuses it. When a cached response is not fresh, 180 it might still be reusable if validation can freshen it (Section 4.3) 181 or if the origin is unavailable (Section 4.2.4). 183 This document obsoletes RFC 7234, with the changes being summarized 184 in Appendix B. 186 1.1. Requirements Notation 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 Section 2 of [Semantics] defines conformance criteria and contains 195 considerations regarding error handling. 197 1.2. Syntax Notation 199 This specification uses the Augmented Backus-Naur Form (ABNF) 200 notation of [RFC5234], extended with the notation for case- 201 sensitivity in strings defined in [RFC7405]. 203 It also uses a list extension, defined in Section 5.6.1 of 204 [Semantics], that allows for compact definition of comma-separated 205 lists using a '#' operator (similar to how the '*' operator indicates 206 repetition). Appendix A shows the collected grammar with all list 207 operators expanded to standard ABNF notation. 209 The following core rule is included by reference, as defined in 210 [RFC5234], Appendix B.1: DIGIT (decimal 0-9). 212 [Semantics] defines the following rules: 214 HTTP-date = 215 OWS = 216 field-name = 217 quoted-string = 218 token = 220 1.3. Delta Seconds 222 The delta-seconds rule specifies a non-negative integer, representing 223 time in seconds. 225 delta-seconds = 1*DIGIT 227 A recipient parsing a delta-seconds value and converting it to binary 228 form ought to use an arithmetic type of at least 31 bits of non- 229 negative integer range. If a cache receives a delta-seconds value 230 greater than the greatest integer it can represent, or if any of its 231 subsequent calculations overflows, the cache MUST consider the value 232 to be 2147483648 (2^(31)) or the greatest positive integer it can 233 conveniently represent. 235 | *Note:* The value 2147483648 is here for historical reasons, 236 | represents infinity (over 68 years), and does not need to be 237 | stored in binary form; an implementation could produce it as a 238 | canned string if any overflow occurs, even if the calculations 239 | are performed with an arithmetic type incapable of directly 240 | representing that number. What matters here is that an 241 | overflow be detected and not treated as a negative value in 242 | later calculations. 244 2. Overview of Cache Operation 246 Proper cache operation preserves the semantics of HTTP transfers 247 ([Semantics]) while reducing the transmission of information already 248 held in the cache. Although caching is an entirely OPTIONAL feature 249 of HTTP, it can be assumed that reusing a cached response is 250 desirable and that such reuse is the default behavior when no 251 requirement or local configuration prevents it. Therefore, HTTP 252 cache requirements are focused on preventing a cache from either 253 storing a non-reusable response or reusing a stored response 254 inappropriately, rather than mandating that caches always store and 255 reuse particular responses. 257 The _cache key_ is comprised of, at a minimum, the request method and 258 target URI used to retrieve the stored response; the method 259 determines under which circumstances that response can be used to 260 satisfy a subsequent request. However, many HTTP caches in common 261 use today only cache GET responses, and therefore only use the URI as 262 the cache key, forwarding other methods. 264 If a request target is subject to content negotiation, the cache 265 might store multiple responses for it. Caches differentiate these 266 responses by incorporating values of the original request's selecting 267 header fields into the cache key as well, using information in the 268 Vary response header field, as per Section 4.1. 270 Caches might incorporate additional material into the cache key. For 271 example, user agent caches might include the referring site's 272 identity, thereby "double keying" the cache to avoid some privacy 273 risks (see Section 7.2). 275 Most commonly, caches store the successful result of a retrieval 276 request: i.e., a 200 (OK) response to a GET request, which contains a 277 representation of the target resource (Section 9.3.1 of [Semantics]). 278 However, it is also possible to store redirects, negative results 279 (e.g., 404 (Not Found)), incomplete results (e.g., 206 (Partial 280 Content)), and responses to methods other than GET if the method's 281 definition allows such caching and defines something suitable for use 282 as a cache key. 284 A cache is _disconnected_ when it cannot contact the origin server or 285 otherwise find a forward path for a request. A disconnected cache 286 can serve stale responses in some circumstances (Section 4.2.4). 288 3. Storing Responses in Caches 290 A cache MUST NOT store a response to a request unless: 292 o the request method is understood by the cache; 294 o the response status code is final (see Section 15 of [Semantics]); 296 o if the response status code is 206 or 304, or the "must- 297 understand" cache directive (see Section 5.2.2.2) is present: the 298 cache understands the response status code; 300 o the "no-store" cache directive is not present in the response (see 301 Section 5.2.2.4); 303 o if the cache is shared: the "private" response directive is either 304 not present or allows a shared cache to store a modified response; 305 see Section 5.2.2.7); 307 o if the cache is shared: the Authorization header field is not 308 present in the request (see Section 11.6.2 of [Semantics]) or a 309 response directive is present that explicitly allows shared 310 caching (see Section 3.5); and, 312 o the response contains at least one of: 314 * a public response directive (see Section 5.2.2.6); 316 * a private response directive, if the cache is not shared (see 317 Section 5.2.2.7); 319 * an Expires header field (see Section 5.3); 321 * a max-age response directive (see Section 5.2.2.9); 323 * if the cache is shared: an s-maxage response directive (see 324 Section 5.2.2.10); 326 * a Cache Control Extension that allows it to be cached (see 327 Section 5.2.3); or, 329 * a status code that is defined as heuristically cacheable (see 330 Section 4.2.2). 332 Note that a cache-control extension can override any of the 333 requirements listed; see Section 5.2.3. 335 In this context, a cache has "understood" a request method or a 336 response status code if it recognizes it and implements all specified 337 caching-related behavior. 339 Note that, in normal operation, some caches will not store a response 340 that has neither a cache validator nor an explicit expiration time, 341 as such responses are not usually useful to store. However, caches 342 are not prohibited from storing such responses. 344 3.1. Storing Header and Trailer Fields 346 Caches MUST include all received response header fields - including 347 unrecognised ones - when storing a response; this assures that new 348 HTTP header fields can be successfully deployed. However, the 349 following exceptions are made: 351 o The Connection header field and fields whose names are listed in 352 it are required by Section 7.6.1 of [Semantics] to be removed 353 before forwarding the message. This MAY be implemented by doing 354 so before storage. 356 o Likewise, some fields' semantics require them to be removed before 357 forwarding the message, and this MAY be implemented by doing so 358 before storage; see Section 7.6.1 of [Semantics] for some 359 examples. 361 o The no-cache (Section 5.2.2.3) and private (Section 5.2.2.7) cache 362 directives can have arguments that prevent storage of header 363 fields by all caches and shared caches, respectively. 365 o Header fields that are specific to a client's proxy configuration 366 MUST NOT be stored, unless the cache incorporates the identity of 367 the proxy into the cache key. Effectively, this is limited to 368 Proxy-Authenticate (Section 11.7.1 of [Semantics]), Proxy- 369 Authentication-Info (Section 11.7.3 of [Semantics]), and Proxy- 370 Authorization (Section 11.7.2 of [Semantics]). 372 Caches MAY either store trailer fields separate from header fields, 373 or discard them. Caches MUST NOT combine trailer fields with header 374 fields. 376 3.2. Updating Stored Header Fields 378 Caches are required to update a stored response's header fields from 379 another (typically newer) response in several situations; for 380 example, see Section 3.4, Section 4.3.4 and Section 4.3.5. 382 When doing so, the cache MUST add each header field in the provided 383 response to the stored response, replacing field values that are 384 already present, with the following exceptions: 386 o Header fields excepted from storage in Section 3.1, 388 o Header fields that the cache's stored response depends upon, as 389 described below, 391 o Header fields that are automatically processed and removed by the 392 recipient, as described below, and 394 o The Content-Length header field. 396 In some cases, caches (especially in user agents) store the results 397 of processing the received response, rather than the response itself, 398 and updating header fields that affect that processing can result in 399 inconsistent behavior and security issues. Caches in this situation 400 MAY omit these header fields from updating stored responses on an 401 exceptional basis, but SHOULD limit such omission to those fields 402 necessary to assure integrity of the stored response. 404 For example, a browser might decode the content coding of a response 405 while it is being received, creating a disconnect between the data it 406 has stored and the response's original metadata. Updating that 407 stored metadata with a different Content-Encoding header field would 408 be problematic. Likewise, a browser might store a post-parse HTML 409 tree, rather than the content received in the response; updating the 410 Content-Type header field would not be workable in this case, because 411 any assumptions about the format made in parsing would now be 412 invalid. 414 Furthermore, some fields are automatically processed and removed by 415 the HTTP implementation; for example, the Content-Range header field. 416 Implementations MAY automatically omit such header fields from 417 updates, even when the processing does not actually occur. 419 Note that the Content-* prefix is not a signal that a header field is 420 omitted from update; it is a convention for MIME header fields, not 421 HTTP. 423 3.3. Storing Incomplete Responses 425 If the request method is GET, the response status code is 200 (OK), 426 and the entire response header section has been received, a cache MAY 427 store a response body that is not complete (Section 3.4 of 428 [Semantics]) if the stored response is recorded as being incomplete. 429 Likewise, a 206 (Partial Content) response MAY be stored as if it 430 were an incomplete 200 (OK) response. However, a cache MUST NOT 431 store incomplete or partial-content responses if it does not support 432 the Range and Content-Range header fields or if it does not 433 understand the range units used in those fields. 435 A cache MAY complete a stored incomplete response by making a 436 subsequent range request (Section 14.2 of [Semantics]) and combining 437 the successful response with the stored response, as defined in 438 Section 3.4. A cache MUST NOT use an incomplete response to answer 439 requests unless the response has been made complete, or the request 440 is partial and specifies a range wholly within the incomplete 441 response. A cache MUST NOT send a partial response to a client 442 without explicitly marking it using the 206 (Partial Content) status 443 code. 445 3.4. Combining Partial Content 447 A response might transfer only a partial representation if the 448 connection closed prematurely or if the request used one or more 449 Range specifiers (Section 14.2 of [Semantics]). After several such 450 transfers, a cache might have received several ranges of the same 451 representation. A cache MAY combine these ranges into a single 452 stored response, and reuse that response to satisfy later requests, 453 if they all share the same strong validator and the cache complies 454 with the client requirements in Section 15.3.7.3 of [Semantics]. 456 When combining the new response with one or more stored responses, a 457 cache MUST update the stored response header fields using the header 458 fields provided in the new response, as per Section 3.2. 460 3.5. Storing Responses to Authenticated Requests 462 A shared cache MUST NOT use a cached response to a request with an 463 Authorization header field (Section 11.6.2 of [Semantics]) to satisfy 464 any subsequent request unless the response contains a Cache-Control 465 field with a response directive (Section 5.2.2) that allows it to be 466 stored by a shared cache and the cache conforms to the requirements 467 of that directive for that response. 469 In this specification, the following response directives have such an 470 effect: must-revalidate (Section 5.2.2.1), public (Section 5.2.2.6), 471 and s-maxage (Section 5.2.2.10). 473 4. Constructing Responses from Caches 475 When presented with a request, a cache MUST NOT reuse a stored 476 response, unless: 478 o The presented target URI (Section 7.1 of [Semantics]) and that of 479 the stored response match, and 481 o the request method associated with the stored response allows it 482 to be used for the presented request, and 484 o selecting header fields nominated by the stored response (if any) 485 match those presented (see Section 4.1), and 487 o the stored response does not contain the no-cache cache directive 488 (Section 5.2.2.3), unless it is successfully validated 489 (Section 4.3), and 491 o the stored response is either: 493 * fresh (see Section 4.2), or 495 * allowed to be served stale (see Section 4.2.4), or 497 * successfully validated (see Section 4.3). 499 Note that a cache-control extension can override any of the 500 requirements listed; see Section 5.2.3. 502 When a stored response is used to satisfy a request without 503 validation, a cache MUST generate an Age header field (Section 5.1), 504 replacing any present in the response with a value equal to the 505 stored response's current_age; see Section 4.2.3. 507 A cache MUST write through requests with methods that are unsafe 508 (Section 9.2.1 of [Semantics]) to the origin server; i.e., a cache is 509 not allowed to generate a reply to such a request before having 510 forwarded the request and having received a corresponding response. 512 Also, note that unsafe requests might invalidate already-stored 513 responses; see Section 4.4. 515 A response that is stored or storable can be used to satisfy multiple 516 requests, provided that it is allowed to reuse that response for the 517 requests in question. This enables caches to _collapse requests_ - 518 or combine multiple incoming requests into a single forward one upon 519 a cache miss - thereby reducing load on the origin server and 520 network. However, note that if the response returned is not able to 521 be used for some or all of the collapsed requests, additional latency 522 might be introduced, because they will need to be forwarded to be 523 satisfied. 525 When more than one suitable response is stored, a cache MUST use the 526 most recent one (as determined by the Date header field). It can 527 also forward the request with "Cache-Control: max-age=0" or "Cache- 528 Control: no-cache" to disambiguate which response to use. 530 A cache that does not have a clock available MUST NOT use stored 531 responses without revalidating them upon every use. 533 4.1. Calculating Cache Keys with Vary 535 When a cache receives a request that can be satisfied by a stored 536 response that has a Vary header field (Section 12.5.5 of 537 [Semantics]), it MUST NOT use that response unless all the selecting 538 header fields nominated by the Vary header field match in both the 539 original request (i.e., that associated with the stored response), 540 and the presented request. 542 The selecting header fields from two requests are defined to match if 543 and only if those in the first request can be transformed to those in 544 the second request by applying any of: 546 o adding or removing whitespace, where allowed in the header field's 547 syntax 549 o combining multiple header field lines with the same field name 550 (see Section 5.2 of [Semantics]) 552 o normalizing both header field values in a way that is known to 553 have identical semantics, according to the header field's 554 specification (e.g., reordering field values when order is not 555 significant; case-normalization, where values are defined to be 556 case-insensitive) 558 If (after any normalization that might take place) a header field is 559 absent from a request, it can only match another request if it is 560 also absent there. 562 A Vary header field value containing a member "*" always fails to 563 match. 565 The stored response with matching selecting header fields is known as 566 the _selected response_. 568 If multiple selected responses are available (potentially including 569 responses without a Vary header field), the cache will need to choose 570 one to use. When a selecting header field has a known mechanism for 571 doing so (e.g., qvalues on Accept and similar request header fields), 572 that mechanism MAY be used to select a preferred response. If such a 573 mechanism is not available, or leads to equally preferred responses, 574 the most recent response (as determined by the Date header field) is 575 used, as per Section 4. 577 Some resources mistakenly omit the Vary header field from their 578 default response (i.e., the one sent when no more preferable response 579 is available), with the effect of selecting it for requests to that 580 resource even when more preferable responses are available. When a 581 cache has multiple responses for a target URI and one or more omits 582 the Vary header field, it SHOULD use the most recent (see 583 Section 4.2.3) valid Vary field value available to select an 584 appropriate response for the request. 586 If no selected response is available, the cache cannot satisfy the 587 presented request. Typically, it is forwarded to the origin server 588 in a (possibly conditional; see Section 4.3) request. 590 4.2. Freshness 592 A _fresh_ response is one whose age has not yet exceeded its 593 freshness lifetime. Conversely, a _stale_ response is one where it 594 has. 596 A response's _freshness lifetime_ is the length of time between its 597 generation by the origin server and its expiration time. An 598 _explicit expiration time_ is the time at which the origin server 599 intends that a stored response can no longer be used by a cache 600 without further validation, whereas a _heuristic expiration time_ is 601 assigned by a cache when no explicit expiration time is available. 603 A response's _age_ is the time that has passed since it was generated 604 by, or successfully validated with, the origin server. 606 When a response is fresh, it can be used to satisfy subsequent 607 requests without contacting the origin server, thereby improving 608 efficiency. 610 The primary mechanism for determining freshness is for an origin 611 server to provide an explicit expiration time in the future, using 612 either the Expires header field (Section 5.3) or the max-age response 613 directive (Section 5.2.2.9). Generally, origin servers will assign 614 future explicit expiration times to responses in the belief that the 615 representation is not likely to change in a semantically significant 616 way before the expiration time is reached. 618 If an origin server wishes to force a cache to validate every 619 request, it can assign an explicit expiration time in the past to 620 indicate that the response is already stale. Compliant caches will 621 normally validate a stale cached response before reusing it for 622 subsequent requests (see Section 4.2.4). 624 Since origin servers do not always provide explicit expiration times, 625 caches are also allowed to use a heuristic to determine an expiration 626 time under certain circumstances (see Section 4.2.2). 628 The calculation to determine if a response is fresh is: 630 response_is_fresh = (freshness_lifetime > current_age) 632 freshness_lifetime is defined in Section 4.2.1; current_age is 633 defined in Section 4.2.3. 635 Clients can send the max-age or min-fresh request directives 636 (Section 5.2.1) to constrain or relax freshness calculations for the 637 corresponding response. However, caches are not required to honor 638 them. 640 When calculating freshness, to avoid common problems in date parsing: 642 o Although all date formats are specified to be case-sensitive, a 643 cache recipient SHOULD match the field value case-insensitively. 645 o If a cache recipient's internal implementation of time has less 646 resolution than the value of an HTTP-date, the recipient MUST 647 internally represent a parsed Expires date as the nearest time 648 equal to or earlier than the received value. 650 o A cache recipient MUST NOT allow local time zones to influence the 651 calculation or comparison of an age or expiration time. 653 o A cache recipient SHOULD consider a date with a zone abbreviation 654 other than "GMT" to be invalid for calculating expiration. 656 Note that freshness applies only to cache operation; it cannot be 657 used to force a user agent to refresh its display or reload a 658 resource. See Section 6 for an explanation of the difference between 659 caches and history mechanisms. 661 4.2.1. Calculating Freshness Lifetime 663 A cache can calculate the freshness lifetime (denoted as 664 freshness_lifetime) of a response by using the first match of: 666 o If the cache is shared and the s-maxage response directive 667 (Section 5.2.2.10) is present, use its value, or 669 o If the max-age response directive (Section 5.2.2.9) is present, 670 use its value, or 672 o If the Expires response header field (Section 5.3) is present, use 673 its value minus the value of the Date response header field (using 674 the time the message was received if it is not present, as per 675 Section 10.2.2 of [Semantics]), or 677 o Otherwise, no explicit expiration time is present in the response. 678 A heuristic freshness lifetime might be applicable; see 679 Section 4.2.2. 681 Note that this calculation is not vulnerable to clock skew, since all 682 of the information comes from the origin server. 684 When there is more than one value present for a given directive 685 (e.g., two Expires header field lines or multiple Cache-Control: max- 686 age directives), either the first occurrence should be used, or the 687 response should be considered stale. If directives conflict (e.g., 688 both max-age and no-cache are present), the most restrictive 689 directive should be honored. Caches are encouraged to consider 690 responses that have invalid freshness information (e.g., a max-age 691 directive with non-integer content) to be stale. 693 4.2.2. Calculating Heuristic Freshness 695 Since origin servers do not always provide explicit expiration times, 696 a cache MAY assign a heuristic expiration time when an explicit time 697 is not specified, employing algorithms that use other field values 698 (such as the Last-Modified time) to estimate a plausible expiration 699 time. This specification does not provide specific algorithms, but 700 does impose worst-case constraints on their results. 702 A cache MUST NOT use heuristics to determine freshness when an 703 explicit expiration time is present in the stored response. Because 704 of the requirements in Section 3, this means that heuristics can only 705 be used on responses without explicit freshness whose status codes 706 are defined as _heuristically cacheable_ (e.g., see Section 15.1 of 707 [Semantics]), and those responses without explicit freshness that 708 have been marked as explicitly cacheable (e.g., with a "public" 709 response directive). 711 Note that in previous specifications heuristically cacheable response 712 status codes were called "cacheable by default." 714 If the response has a Last-Modified header field (Section 8.8.2 of 715 [Semantics]), caches are encouraged to use a heuristic expiration 716 value that is no more than some fraction of the interval since that 717 time. A typical setting of this fraction might be 10%. 719 | *Note:* Section 13.9 of [RFC2616] prohibited caches from 720 | calculating heuristic freshness for URIs with query components 721 | (i.e., those containing '?'). In practice, this has not been 722 | widely implemented. Therefore, origin servers are encouraged 723 | to send explicit directives (e.g., Cache-Control: no-cache) if 724 | they wish to prevent caching. 726 4.2.3. Calculating Age 728 The Age header field is used to convey an estimated age of the 729 response message when obtained from a cache. The Age field value is 730 the cache's estimate of the number of seconds since the origin server 731 generated or validated the response. The Age value is therefore the 732 sum of the time that the response has been resident in each of the 733 caches along the path from the origin server, plus the time it has 734 been in transit along network paths. 736 Age calculation uses the following data: 738 _age_value_ The term "age_value" denotes the value of the Age header 739 field (Section 5.1), in a form appropriate for arithmetic 740 operation; or 0, if not available. 742 _date_value_ The term "date_value" denotes the value of the Date 743 header field, in a form appropriate for arithmetic operations. 744 See Section 10.2.2 of [Semantics] for the definition of the Date 745 header field, and for requirements regarding responses without it. 747 _now_ The term "now" means "the current value of the clock at the 748 host performing the calculation". A host ought to use NTP 749 ([RFC5905]) or some similar protocol to synchronize its clocks to 750 Coordinated Universal Time. 752 _request_time_ The current value of the clock at the host at the 753 time the request resulting in the stored response was made. 755 _response_time_ The current value of the clock at the host at the 756 time the response was received. 758 A response's age can be calculated in two entirely independent ways: 760 1. the "apparent_age": response_time minus date_value, if the local 761 clock is reasonably well synchronized to the origin server's 762 clock. If the result is negative, the result is replaced by 763 zero. 765 2. the "corrected_age_value", if all of the caches along the 766 response path implement HTTP/1.1 or greater. A cache MUST 767 interpret this value relative to the time the request was 768 initiated, not the time that the response was received. 770 apparent_age = max(0, response_time - date_value); 772 response_delay = response_time - request_time; 773 corrected_age_value = age_value + response_delay; 775 The corrected_age_value MAY be used as the corrected_initial_age. In 776 circumstances where very old cache implementations that might not 777 correctly insert Age are present, corrected_initial_age can be 778 calculated more conservatively as 780 corrected_initial_age = max(apparent_age, corrected_age_value); 782 The current_age of a stored response can then be calculated by adding 783 the time (in seconds) since the stored response was last validated by 784 the origin server to the corrected_initial_age. 786 resident_time = now - response_time; 787 current_age = corrected_initial_age + resident_time; 789 4.2.4. Serving Stale Responses 791 A "stale" response is one that either has explicit expiry information 792 or is allowed to have heuristic expiry calculated, but is not fresh 793 according to the calculations in Section 4.2. 795 A cache MUST NOT generate a stale response if it is prohibited by an 796 explicit in-protocol directive (e.g., by a "no-cache" cache 797 directive, a "must-revalidate" cache-response-directive, or an 798 applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 799 see Section 5.2.2). 801 A cache MUST NOT generate a stale response unless it is disconnected 802 or doing so is explicitly permitted by the client or origin server 803 (e.g., by the max-stale request directive in Section 5.2.1, by 804 extension directives such as those defined in [RFC5861], or by 805 configuration in accordance with an out-of-band contract). 807 4.3. Validation 809 When a cache has one or more stored responses for a requested URI, 810 but cannot serve any of them (e.g., because they are not fresh, or 811 one cannot be selected; see Section 4.1), it can use the conditional 812 request mechanism (Section 13.1 of [Semantics]) in the forwarded 813 request to give the next inbound server an opportunity to select a 814 valid stored response to use, updating the stored metadata in the 815 process, or to replace the stored response(s) with a new response. 816 This process is known as _validating_ or _revalidating_ the stored 817 response. 819 4.3.1. Sending a Validation Request 821 When generating a conditional request for validation, a cache starts 822 with either a request it is attempting to satisfy, or - if it is 823 initiating the request independently - it synthesises a request using 824 a stored response by copying the method, target URI, and request 825 header fields identified by the Vary header field (Section 4.1). 827 It then updates that request with one or more precondition header 828 fields. These contain validator metadata sourced from stored 829 response(s) that have the same cache key. 831 The precondition header fields are then compared by recipients to 832 determine whether any stored response is equivalent to a current 833 representation of the resource. 835 One such validator is the timestamp given in a Last-Modified header 836 field (Section 8.8.2 of [Semantics]), which can be used in an If- 837 Modified-Since header field for response validation, or in an If- 838 Unmodified-Since or If-Range header field for representation 839 selection (i.e., the client is referring specifically to a previously 840 obtained representation with that timestamp). 842 Another validator is the entity-tag given in an ETag field 843 (Section 8.8.3 of [Semantics]). One or more entity-tags, indicating 844 one or more stored responses, can be used in an If-None-Match header 845 field for response validation, or in an If-Match or If-Range header 846 field for representation selection (i.e., the client is referring 847 specifically to one or more previously obtained representations with 848 the listed entity-tags). 850 4.3.2. Handling a Received Validation Request 852 Each client in the request chain may have its own cache, so it is 853 common for a cache at an intermediary to receive conditional requests 854 from other (outbound) caches. Likewise, some user agents make use of 855 conditional requests to limit data transfers to recently modified 856 representations or to complete the transfer of a partially retrieved 857 representation. 859 If a cache receives a request that can be satisfied by reusing one of 860 its stored 200 (OK) or 206 (Partial Content) responses, the cache 861 SHOULD evaluate any applicable conditional header field preconditions 862 received in that request with respect to the corresponding validators 863 contained within the selected response. A cache MUST NOT evaluate 864 conditional header fields that only apply to an origin server, occur 865 in a request with semantics that cannot be satisfied with a cached 866 response, or occur in a request with a target resource for which it 867 has no stored responses; such preconditions are likely intended for 868 some other (inbound) server. 870 The proper evaluation of conditional requests by a cache depends on 871 the received precondition header fields and their precedence. In 872 summary, the If-Match and If-Unmodified-Since conditional header 873 fields are not applicable to a cache, and If-None-Match takes 874 precedence over If-Modified-Since. See Section 13.2.2 of [Semantics] 875 for a complete specification of precondition precedence. 877 A request containing an If-None-Match header field (Section 13.1.2 of 878 [Semantics]) indicates that the client wants to validate one or more 879 of its own stored responses in comparison to whichever stored 880 response is selected by the cache. 882 When a cache decides to revalidate its own stored responses for a 883 request that contains an If-None-Match list of entity-tags, the cache 884 MAY combine the received list with a list of entity-tags from its own 885 stored set of responses (fresh or stale) and send the union of the 886 two lists as a replacement If-None-Match header field value in the 887 forwarded request. If a stored response contains only partial 888 content, the cache MUST NOT include its entity-tag in the union 889 unless the request is for a range that would be fully satisfied by 890 that partial stored response. If the response to the forwarded 891 request is 304 (Not Modified) and has an ETag field value with an 892 entity-tag that is not in the client's list, the cache MUST generate 893 a 200 (OK) response for the client by reusing its corresponding 894 stored response, as updated by the 304 response metadata 895 (Section 4.3.4). 897 If an If-None-Match header field is not present, a request containing 898 an If-Modified-Since header field (Section 13.1.3 of [Semantics]) 899 indicates that the client wants to validate one or more of its own 900 stored responses by modification date. 902 If a request contains an If-Modified-Since header field and the Last- 903 Modified header field is not present in a selected stored response, a 904 cache SHOULD use the stored response's Date field value (or, if no 905 Date field is present, the time that the stored response was 906 received) to evaluate the conditional. 908 A cache that implements partial responses to range requests, as 909 defined in Section 14.2 of [Semantics], also needs to evaluate a 910 received If-Range header field (Section 13.1.5 of [Semantics]) 911 regarding its selected stored response. 913 4.3.3. Handling a Validation Response 915 Cache handling of a response to a conditional request depends upon 916 its status code: 918 o A 304 (Not Modified) response status code indicates that the 919 stored response can be updated and reused; see Section 4.3.4. 921 o A full response (i.e., one containing content) indicates that none 922 of the stored responses nominated in the conditional request is 923 suitable. Instead, the cache MUST use the full response to 924 satisfy the request. The cache MAY store such a full response, 925 subject to its constraints (see Section 3). 927 o However, if a cache receives a 5xx (Server Error) response while 928 attempting to validate a response, it can either forward this 929 response to the requesting client, or act as if the server failed 930 to respond. In the latter case, the cache can send a previously 931 stored response, subject to its constraints on doing so (see 932 Section 4.2.4), or retry the validation request. 934 4.3.4. Freshening Stored Responses upon Validation 936 When a cache receives a 304 (Not Modified) response and already has 937 one or more stored 200 (OK) responses for the applicable cache key, 938 the cache needs to identify which (if any) are to be updated by the 939 new information provided, and then do so. 941 The stored response(s) to update are identified by using the first 942 match (if any) of: 944 o If the new response contains one or more _strong validators_ (see 945 Section 8.8.1 of [Semantics]), then each of those strong 946 validators identify the selected representation for update. All 947 the stored responses with one of those same strong validators are 948 identified for update. If none of the stored responses contain at 949 least one of the same strong validators, then the cache MUST NOT 950 use the new response to update any stored responses. 952 o If the new response contains no strong validators but does contain 953 one or more _weak validators_, and those validators correspond to 954 one of the cache's stored responses, then the most recent of those 955 matching stored responses is identified for update. 957 o If the new response does not include any form of validator (such 958 as where a client generates an If-Modified-Since request from a 959 source other than the Last-Modified response header field), and 960 there is only one stored response, and that stored response also 961 lacks a validator, then that stored response is identified for 962 update. 964 For each stored response identified, the cache MUST update its header 965 fields with the header fields provided in the 304 (Not Modified) 966 response, as per Section 3.2. 968 4.3.5. Freshening Responses with HEAD 970 A response to the HEAD method is identical to what an equivalent 971 request made with a GET would have been, without sending the content. 972 This property of HEAD responses can be used to invalidate or update a 973 cached GET response if the more efficient conditional GET request 974 mechanism is not available (due to no validators being present in the 975 stored response) or if transmission of the content is not desired 976 even if it has changed. 978 When a cache makes an inbound HEAD request for a target URI and 979 receives a 200 (OK) response, the cache SHOULD update or invalidate 980 each of its stored GET responses that could have been selected for 981 that request (see Section 4.1). 983 For each of the stored responses that could have been selected, if 984 the stored response and HEAD response have matching values for any 985 received validator fields (ETag and Last-Modified) and, if the HEAD 986 response has a Content-Length header field, the value of Content- 987 Length matches that of the stored response, the cache SHOULD update 988 the stored response as described below; otherwise, the cache SHOULD 989 consider the stored response to be stale. 991 If a cache updates a stored response with the metadata provided in a 992 HEAD response, the cache MUST use the header fields provided in the 993 HEAD response to update the stored response (see Section 3.2). 995 4.4. Invalidating Stored Responses 997 Because unsafe request methods (Section 9.2.1 of [Semantics]) such as 998 PUT, POST or DELETE have the potential for changing state on the 999 origin server, intervening caches are required to invalidate stored 1000 responses to keep their contents up to date. 1002 A cache MUST invalidate the target URI (Section 7.1 of [Semantics]) 1003 when a non-error status code is received in response to an unsafe 1004 request method (including methods whose safety is unknown). 1006 A cache MAY invalidate other URIs when a non-error status code is 1007 received in response to an unsafe request method (including methods 1008 whose safety is unknown). In particular, the URI(s) in the Location 1009 and Content-Location response header fields (if present) are 1010 candidates for invalidation; other URIs might be discovered through 1011 mechanisms not specified in this document. However, a cache MUST NOT 1012 trigger an invalidation under these conditions if the origin 1013 (Section 4.3.1 of [Semantics]) of the URI to be invalidated differs 1014 from that of the target URI (Section 7.1 of [Semantics]). This helps 1015 prevent denial-of-service attacks. 1017 _Invalidate_ means that the cache will either remove all stored 1018 responses whose target URI matches the given URI, or will mark them 1019 as "invalid" and in need of a mandatory validation before they can be 1020 sent in response to a subsequent request. 1022 A "non-error response" is one with a 2xx (Successful) or 3xx 1023 (Redirection) status code. 1025 Note that this does not guarantee that all appropriate responses are 1026 invalidated globally; a state-changing request would only invalidate 1027 responses in the caches it travels through. 1029 5. Field Definitions 1031 This section defines the syntax and semantics of HTTP fields related 1032 to caching. 1034 5.1. Age 1036 The "Age" response header field conveys the sender's estimate of the 1037 time since the response was generated or successfully validated at 1038 the origin server. Age values are calculated as specified in 1039 Section 4.2.3. 1041 Age = delta-seconds 1043 The Age field value is a non-negative integer, representing time in 1044 seconds (see Section 1.3). 1046 Although it is defined as a singleton header field, a cache 1047 encountering a message with multiple Age field lines SHOULD use the 1048 first field line, discarding subsequent ones. 1050 If the field value (after discarding additional lines, as per above) 1051 is invalid (e.g., it contains a list or something other than a non- 1052 negative integer), a cache SHOULD consider the response to be stale. 1054 The presence of an Age header field implies that the response was not 1055 generated or validated by the origin server for this request. 1056 However, lack of an Age header field does not imply the origin was 1057 contacted. 1059 5.2. Cache-Control 1061 The "Cache-Control" header field is used to list directives for 1062 caches along the request/response chain. Such cache directives are 1063 unidirectional in that the presence of a directive in a request does 1064 not imply that the same directive is present in the response, or to 1065 be repeated in it. 1067 See Section 5.2.3 for information about how Cache-Control directives 1068 defined elsewhere are handled. 1070 A proxy, whether or not it implements a cache, MUST pass cache 1071 directives through in forwarded messages, regardless of their 1072 significance to that application, since the directives might apply to 1073 all recipients along the request/response chain. It is not possible 1074 to target a directive to a specific cache. 1076 Cache directives are identified by a token, to be compared case- 1077 insensitively, and have an optional argument that can use both token 1078 and quoted-string syntax. For the directives defined below that 1079 define arguments, recipients ought to accept both forms, even if a 1080 specific form is required for generation. 1082 Cache-Control = #cache-directive 1084 cache-directive = token [ "=" ( token / quoted-string ) ] 1086 For the cache directives defined below, no argument is defined (nor 1087 allowed) unless stated otherwise. 1089 5.2.1. Request Cache-Control Directives 1091 This section defines cache request directives. They are advisory; 1092 caches MAY implement them, but are not required to. 1094 5.2.1.1. max-age 1096 Argument syntax: 1098 delta-seconds (see Section 1.3) 1100 The "max-age" request directive indicates that the client prefers a 1101 response whose age is less than or equal to the specified number of 1102 seconds. Unless the max-stale request directive is also present, the 1103 client does not wish to receive a stale response. 1105 This directive uses the token form of the argument syntax: e.g., 1106 'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the 1107 quoted-string form. 1109 5.2.1.2. max-stale 1111 Argument syntax: 1113 delta-seconds (see Section 1.3) 1115 The "max-stale" request directive indicates that the client will 1116 accept a response that has exceeded its freshness lifetime. If a 1117 value is present, then the client is willing to accept a response 1118 that has exceeded its freshness lifetime by no more than the 1119 specified number of seconds. If no value is assigned to max-stale, 1120 then the client will accept a stale response of any age. 1122 This directive uses the token form of the argument syntax: e.g., 1123 'max-stale=10' not 'max-stale="10"'. A sender MUST NOT generate the 1124 quoted-string form. 1126 5.2.1.3. min-fresh 1128 Argument syntax: 1130 delta-seconds (see Section 1.3) 1132 The "min-fresh" request directive indicates that the client prefers a 1133 response whose freshness lifetime is no less than its current age 1134 plus the specified time in seconds. That is, the client wants a 1135 response that will still be fresh for at least the specified number 1136 of seconds. 1138 This directive uses the token form of the argument syntax: e.g., 1139 'min-fresh=20' not 'min-fresh="20"'. A sender MUST NOT generate the 1140 quoted-string form. 1142 5.2.1.4. no-cache 1144 The "no-cache" request directive indicates that the client prefers 1145 stored response not be used to satisfy the request without successful 1146 validation on the origin server. 1148 5.2.1.5. no-store 1150 The "no-store" request directive indicates that a cache MUST NOT 1151 store any part of either this request or any response to it. This 1152 directive applies to both private and shared caches. "MUST NOT 1153 store" in this context means that the cache MUST NOT intentionally 1154 store the information in non-volatile storage, and MUST make a best- 1155 effort attempt to remove the information from volatile storage as 1156 promptly as possible after forwarding it. 1158 This directive is _not_ a reliable or sufficient mechanism for 1159 ensuring privacy. In particular, malicious or compromised caches 1160 might not recognize or obey this directive, and communications 1161 networks might be vulnerable to eavesdropping. 1163 Note that if a request containing this directive is satisfied from a 1164 cache, the no-store request directive does not apply to the already 1165 stored response. 1167 5.2.1.6. no-transform 1169 The "no-transform" request directive indicates that the client is 1170 asking for intermediaries to avoid transforming the content, as 1171 defined in Section 7.7 of [Semantics]. 1173 5.2.1.7. only-if-cached 1175 The "only-if-cached" request directive indicates that the client only 1176 wishes to obtain a stored response. Caches that honor this request 1177 directive SHOULD, upon receiving it, either respond using a stored 1178 response consistent with the other constraints of the request, or 1179 respond with a 504 (Gateway Timeout) status code. 1181 5.2.2. Response Cache-Control Directives 1183 This section defines cache response directives. A cache MUST obey 1184 the Cache-Control directives defined in this section. 1186 5.2.2.1. must-revalidate 1188 The "must-revalidate" response directive indicates that once the 1189 response has become stale, a cache MUST NOT reuse that response to 1190 satisfy another request until it has been successfully validated by 1191 the origin, as defined by Section 4.3. 1193 The must-revalidate directive is necessary to support reliable 1194 operation for certain protocol features. In all circumstances a 1195 cache MUST NOT ignore the must-revalidate directive; in particular, 1196 if a cache is disconnected, the cache MUST generate an error response 1197 rather than reuse the stale response. The generated status code 1198 SHOULD be 504 (Gateway Timeout) unless another error status code is 1199 more applicable. 1201 The must-revalidate directive ought to be used by servers if and only 1202 if failure to validate a request could cause incorrect operation, 1203 such as a silently unexecuted financial transaction. 1205 The must-revalidate directive also permits a shared cache to reuse a 1206 response to a request containing an Authorization header field 1207 (Section 11.6.2 of [Semantics]), subject to the above requirement on 1208 revalidation (Section 3.5). 1210 5.2.2.2. must-understand 1212 The "must-understand" response directive limits caching of the 1213 response to a cache that understands and conforms to the requirements 1214 for that response's status code. 1216 Responses containing "must-understand" SHOULD also contain the "no- 1217 store" directive; caches that implement "must-understand" SHOULD 1218 ignore the "no-store" directive in responses that contain both 1219 directives and a status code that the cache understands and conforms 1220 to any related caching requirements. 1222 5.2.2.3. no-cache 1224 Argument syntax: 1226 #field-name 1228 The "no-cache" response directive, in its unqualified form (without 1229 an argument), indicates that the response MUST NOT be used to satisfy 1230 any other request without forwarding it for validation and receiving 1231 a successful response; see Section 4.3. 1233 This allows an origin server to prevent a cache from using the 1234 response to satisfy a request without contacting it, even by caches 1235 that have been configured to send stale responses. 1237 The qualified form of no-cache response directive, with an argument 1238 that lists one or more field names, indicates that a cache MAY use 1239 the response to satisfy a subsequent request, subject to any other 1240 restrictions on caching, if the listed header fields are excluded 1241 from the subsequent response or the subsequent response has been 1242 successfully revalidated with the origin server (updating or removing 1243 those fields). This allows an origin server to prevent the re-use of 1244 certain header fields in a response, while still allowing caching of 1245 the rest of the response. 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:* The qualified form of the directive is often handled by 1255 | caches as if an unqualified no-cache directive was received; 1256 | i.e., the special handling for the qualified form is not widely 1257 | implemented. 1259 5.2.2.4. no-store 1261 The "no-store" response directive indicates that a cache MUST NOT 1262 store any part of either the immediate request or response, and MUST 1263 NOT use the response to satisfy any other request. 1265 This directive applies to both private and shared caches. "MUST NOT 1266 store" in this context means that the cache MUST NOT intentionally 1267 store the information in non-volatile storage, and MUST make a best- 1268 effort attempt to remove the information from volatile storage as 1269 promptly as possible after forwarding it. 1271 This directive is _not_ a reliable or sufficient mechanism for 1272 ensuring privacy. In particular, malicious or compromised caches 1273 might not recognize or obey this directive, and communications 1274 networks might be vulnerable to eavesdropping. 1276 Note that the "must-understand" cache directive overrides "no-store" 1277 in certain circumstances; see Section 5.2.2.2. 1279 5.2.2.5. no-transform 1281 The "no-transform" response directive indicates that an intermediary 1282 (regardless of whether it implements a cache) MUST NOT transform the 1283 content, as defined in Section 7.7 of [Semantics]. 1285 5.2.2.6. public 1287 The "public" response directive indicates that a cache MAY store the 1288 response even if it would otherwise be prohibited, subject to the 1289 constraints defined in Section 3. In other words, public explicitly 1290 marks the response as cacheable. For example, public permits a 1291 shared cache to reuse a response to a request containing an 1292 Authorization header field (Section 3.5). 1294 Note that it is unnecessary to add the public directive to a response 1295 that is already cacheable according to Section 3. 1297 If a response with the public directive has no explicit freshness 1298 information, it is heuristically cacheable (Section 4.2.2). 1300 5.2.2.7. private 1302 Argument syntax: 1304 #field-name 1306 The unqualified "private" response directive indicates that a shared 1307 cache MUST NOT store the response (i.e., the response is intended for 1308 a single user). It also indicates that a private cache MAY store the 1309 response, subject the constraints defined in Section 3, even if the 1310 response would not otherwise be heuristically cacheable by a private 1311 cache. 1313 If a qualified private response directive is present, with an 1314 argument that lists one or more field names, then only the listed 1315 header fields are limited to a single user: a shared cache MUST NOT 1316 store the listed header fields if they are present in the original 1317 response, but MAY store the remainder of the response message without 1318 those header fields, subject the constraints defined in Section 3. 1320 The field names given are not limited to the set of header fields 1321 defined by this specification. Field names are case-insensitive. 1323 This directive uses the quoted-string form of the argument syntax. A 1324 sender SHOULD NOT generate the token form (even if quoting appears 1325 not to be needed for single-entry lists). 1327 | *Note:* This usage of the word "private" only controls where 1328 | the response can be stored; it cannot ensure the privacy of the 1329 | message content. Also, the qualified form of the directive is 1330 | often handled by caches as if an unqualified private directive 1331 | was received; i.e., the special handling for the qualified form 1332 | is not widely implemented. 1334 5.2.2.8. proxy-revalidate 1336 The "proxy-revalidate" response directive indicates that once the 1337 response has become stale, a shared cache MUST NOT reuse that 1338 response to satisfy another request until it has been successfully 1339 validated by the origin, as defined by Section 4.3. This is 1340 analogous to must-revalidate (Section 5.2.2.1), except that proxy- 1341 revalidate does not apply to private caches. 1343 Note that "proxy-revalidate" on its own does not imply that a 1344 response is cacheable. For example, it might be combined with the 1345 public directive (Section 5.2.2.6), allowing the response to be 1346 cached while requiring only a shared cache to revalidate when stale. 1348 5.2.2.9. max-age 1350 Argument syntax: 1352 delta-seconds (see Section 1.3) 1354 The "max-age" response directive indicates that the response is to be 1355 considered stale after its age is greater than the specified number 1356 of seconds. 1358 This directive uses the token form of the argument syntax: e.g., 1359 'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the 1360 quoted-string form. 1362 5.2.2.10. s-maxage 1364 Argument syntax: 1366 delta-seconds (see Section 1.3) 1368 The "s-maxage" response directive indicates that, for a shared cache, 1369 the maximum age specified by this directive overrides the maximum age 1370 specified by either the max-age directive or the Expires header 1371 field. 1373 The s-maxage directive incorporates the proxy-revalidate 1374 (Section 5.2.2.8) response directive's semantics for a shared cache. 1375 A shared cache MUST NOT reuse a stale response with s-maxage to 1376 satisfy another request until it has been successfully validated by 1377 the origin, as defined by Section 4.3. This directive also permits a 1378 shared cache to reuse a response to a request containing an 1379 Authorization header field, subject to the above requirements on 1380 maximum age and revalidation (Section 3.5). 1382 This directive uses the token form of the argument syntax: e.g., 1383 's-maxage=10' not 's-maxage="10"'. A sender MUST NOT generate the 1384 quoted-string form. 1386 5.2.3. Cache Control Extensions 1388 The Cache-Control header field can be extended through the use of one 1389 or more cache-extension tokens, each with an optional value. A cache 1390 MUST ignore unrecognized cache directives. 1392 Informational extensions (those that do not require a change in cache 1393 behavior) can be added without changing the semantics of other 1394 directives. 1396 Behavioral extensions are designed to work by acting as modifiers to 1397 the existing base of cache directives. Both the new directive and 1398 the old directive are supplied, such that applications that do not 1399 understand the new directive will default to the behavior specified 1400 by the old directive, and those that understand the new directive 1401 will recognize it as modifying the requirements associated with the 1402 old directive. In this way, extensions to the existing cache-control 1403 directives can be made without breaking deployed caches. 1405 For example, consider a hypothetical new response directive called 1406 "community" that acts as a modifier to the private directive: in 1407 addition to private caches, any cache that is shared only by members 1408 of the named community is allowed to cache the response. An origin 1409 server wishing to allow the UCI community to use an otherwise private 1410 response in their shared cache(s) could do so by including 1412 Cache-Control: private, community="UCI" 1414 A cache that recognizes such a community cache-extension could 1415 broaden its behavior in accordance with that extension. A cache that 1416 does not recognize the community cache-extension would ignore it and 1417 adhere to the private directive. 1419 New extension directives ought to consider defining: 1421 o What it means for a directive to be specified multiple times, 1423 o When the directive does not take an argument, what it means when 1424 an argument is present, 1426 o When the directive requires an argument, what it means when it is 1427 missing, 1429 o Whether the directive is specific to requests, responses, or able 1430 to be used in either. 1432 5.2.4. Cache Directive Registry 1434 The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" 1435 defines the namespace for the cache directives. It has been created 1436 and is now maintained at . 1439 A registration MUST include the following fields: 1441 o Cache Directive Name 1443 o Pointer to specification text 1445 Values to be added to this namespace require IETF Review (see 1446 [RFC8126], Section 4.8). 1448 5.3. Expires 1450 The "Expires" response header field gives the date/time after which 1451 the response is considered stale. See Section 4.2 for further 1452 discussion of the freshness model. 1454 The presence of an Expires header field does not imply that the 1455 original resource will change or cease to exist at, before, or after 1456 that time. 1458 The Expires field value is an HTTP-date timestamp, as defined in 1459 Section 5.6.7 of [Semantics]. 1461 Expires = HTTP-date 1463 For example 1465 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1467 A cache recipient MUST interpret invalid date formats, especially the 1468 value "0", as representing a time in the past (i.e., "already 1469 expired"). 1471 If a response includes a Cache-Control header field with the max-age 1472 directive (Section 5.2.2.9), a recipient MUST ignore the Expires 1473 header field. Likewise, if a response includes the s-maxage 1474 directive (Section 5.2.2.10), a shared cache recipient MUST ignore 1475 the Expires header field. In both these cases, the value in Expires 1476 is only intended for recipients that have not yet implemented the 1477 Cache-Control header field. 1479 An origin server without a clock MUST NOT generate an Expires header 1480 field unless its value represents a fixed time in the past (always 1481 expired) or its value has been associated with the resource by a 1482 system or user with a reliable clock. 1484 Historically, HTTP required the Expires field value to be no more 1485 than a year in the future. While longer freshness lifetimes are no 1486 longer prohibited, extremely large values have been demonstrated to 1487 cause problems (e.g., clock overflows due to use of 32-bit integers 1488 for time values), and many caches will evict a response far sooner 1489 than that. 1491 5.4. Pragma 1493 The "Pragma" request header field was defined for HTTP/1.0 caches, so 1494 that clients could specify a "no-cache" request (as Cache-Control was 1495 not defined until HTTP/1.1). 1497 However, support for Cache-Control is now widespread. As a result, 1498 this specification deprecates Pragma. 1500 | *Note:* Because the meaning of "Pragma: no-cache" in responses 1501 | was never specified, it does not provide a reliable replacement 1502 | for "Cache-Control: no-cache" in them. 1504 5.5. Warning 1506 The "Warning" header field was used to carry additional information 1507 about the status or transformation of a message that might not be 1508 reflected in the status code. This specification obsoletes it, as it 1509 is not widely generated or surfaced to users. The information it 1510 carried can be gleaned from examining other header fields, such as 1511 Age. 1513 6. Relationship to Applications and Other Caches 1515 Applications using HTTP often specify additional forms of caching. 1516 For example, Web browsers often have history mechanisms such as 1517 "Back" buttons that can be used to redisplay a representation 1518 retrieved earlier in a session. 1520 Likewise, some Web browsers implement caching of images and other 1521 assets within a page view; they may or may not honor HTTP caching 1522 semantics. 1524 The requirements in this specification do not necessarily apply to 1525 how applications use data after it is retrieved from a HTTP cache. 1526 For example, a history mechanism can display a previous 1527 representation even if it has expired, and an application can use 1528 cached data in other ways beyond its freshness lifetime. 1530 This specification does not prohibit the application from taking HTTP 1531 caching into account; for example, a history mechanism might tell the 1532 user that a view is stale, or it might honor cache directives (e.g., 1533 Cache-Control: no-store). 1535 However, when an application caches data and does not make this 1536 apparent to or easily controllable by the user, it is strongly 1537 encouraged to define its operation with respect to HTTP cache 1538 directives, so as not to surprise authors who expect caching 1539 semantics to be honoured. For example, while it might be reasonable 1540 to define an application cache "above" HTTP that allows a response 1541 containing Cache-Control: no-store to be reused for requests that are 1542 directly related to the request that fetched it (such as those 1543 created during the same page load), it would likely be surprising and 1544 confusing to users and authors if it were allowed to be reused for 1545 requests unrelated in any way to the one from which it was obtained. 1547 7. Security Considerations 1549 This section is meant to inform developers, information providers, 1550 and users of known security concerns specific to HTTP caching. More 1551 general security considerations are addressed in "HTTP/1.1" 1552 (Section 11 of [Messaging]) and "HTTP Semantics" (Section 17 of 1553 [Semantics]). 1555 Caches expose additional potential vulnerabilities, since the 1556 contents of the cache represent an attractive target for malicious 1557 exploitation. Because cache contents persist after an HTTP request 1558 is complete, an attack on the cache can reveal information long after 1559 a user believes that the information has been removed from the 1560 network. Therefore, cache contents need to be protected as sensitive 1561 information. 1563 7.1. Cache Poisoning 1565 Various attacks might be amplified by being stored in a shared cache. 1566 Such "cache poisoning" attacks use the cache to distribute malicious 1567 content to many clients, and are especially effective when an 1568 attacker can use implementation flaws, elevated privileges, or other 1569 techniques to insert such a response into a cache. 1571 One common attack vector for cache poisoning is to exploit 1572 differences in message parsing on proxies and in user agents; see 1573 Section 6.3 of [Messaging] for the relevant requirements regarding 1574 HTTP/1.1. 1576 7.2. Timing Attacks 1578 Because one of the primary uses of a cache is to optimise 1579 performance, its use can "leak" information about what resources have 1580 been previously requested. 1582 For example, if a user visits a site and their browser caches some of 1583 its responses, and then navigates to a second site, that site can 1584 attempt to load responses it knows exists on the first site. If they 1585 load quickly, it can be assumed that the user has visited that site, 1586 or even a specific page on it. 1588 Such "timing attacks" can be mitigated by adding more information to 1589 the cache key, such as the identity of the referring site (to prevent 1590 the attack described above). This is sometimes called "double 1591 keying." 1593 7.3. Caching of Sensitive Information 1595 Implementation and deployment flaws (as well as misunderstanding of 1596 cache operation) might lead to caching of sensitive information 1597 (e.g., authentication credentials) that is thought to be private, 1598 exposing it to unauthorized parties. 1600 Note that the Set-Cookie response header field [RFC6265] does not 1601 inhibit caching; a cacheable response with a Set-Cookie header field 1602 can be (and often is) used to satisfy subsequent requests to caches. 1603 Servers who wish to control caching of these responses are encouraged 1604 to emit appropriate Cache-Control response header fields. 1606 8. IANA Considerations 1608 The change controller for the following registrations is: "IETF 1609 (iesg@ietf.org) - Internet Engineering Task Force". 1611 8.1. Field Name Registration 1613 First, introduce the new "Hypertext Transfer Protocol (HTTP) Field 1614 Name Registry" at as 1615 described in Section 18.4 of [Semantics]. 1617 Then, please update the registry with the field names listed in the 1618 table below: 1620 --------------- ----------- ------ ---------- 1621 Field Name Status Ref. Comments 1622 --------------- ----------- ------ ---------- 1623 Age standard 5.1 1624 Cache-Control standard 5.2 1625 Expires standard 5.3 1626 Pragma standard 5.4 1627 Warning obsoleted 5.5 1628 --------------- ----------- ------ ---------- 1630 Table 1 1632 8.2. Cache Directive Registration 1634 Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive 1635 Registry" at 1636 with the registration procedure of Section 5.2.4 and the cache 1637 directive names summarized in the table below. 1639 ------------------ ---------------------------------- 1640 Cache Directive Reference 1641 ------------------ ---------------------------------- 1642 max-age Section 5.2.1.1, Section 5.2.2.9 1643 max-stale Section 5.2.1.2 1644 min-fresh Section 5.2.1.3 1645 must-revalidate Section 5.2.2.1 1646 must-understand Section 5.2.2.2 1647 no-cache Section 5.2.1.4, Section 5.2.2.3 1648 no-store Section 5.2.1.5, Section 5.2.2.4 1649 no-transform Section 5.2.1.6, Section 5.2.2.5 1650 only-if-cached Section 5.2.1.7 1651 private Section 5.2.2.7 1652 proxy-revalidate Section 5.2.2.8 1653 public Section 5.2.2.6 1654 s-maxage Section 5.2.2.10 1655 ------------------ ---------------------------------- 1657 Table 2 1659 8.3. Warn Code Registry 1661 Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn 1662 Codes" registry at 1663 to the effect that Warning is obsoleted. 1665 9. References 1667 9.1. Normative References 1669 [Messaging] 1670 Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1671 Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- 1672 ietf-httpbis-messaging-14, January 13, 2021, 1673 . 1676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1677 Requirement Levels", BCP 14, RFC 2119, 1678 DOI 10.17487/RFC2119, March 1997, 1679 . 1681 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1682 Specifications: ABNF", STD 68, RFC 5234, 1683 DOI 10.17487/RFC5234, January 2008, 1684 . 1686 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 1687 RFC 7405, DOI 10.17487/RFC7405, December 2014, 1688 . 1690 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1691 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1692 May 2017, . 1694 [Semantics] 1695 Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1696 Ed., "HTTP Semantics", Work in Progress, Internet-Draft, 1697 draft-ietf-httpbis-semantics-14, January 13, 2021, 1698 . 1701 9.2. Informative References 1703 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1704 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1705 Transfer Protocol -- HTTP/1.1", RFC 2616, 1706 DOI 10.17487/RFC2616, June 1999, 1707 . 1709 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1710 Content", RFC 5861, DOI 10.17487/RFC5861, April 2010, 1711 . 1713 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1714 "Network Time Protocol Version 4: Protocol and Algorithms 1715 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1716 . 1718 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1719 DOI 10.17487/RFC6265, April 2011, 1720 . 1722 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke, 1723 Ed., "Hypertext Transfer Protocol (HTTP): Caching", 1724 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1725 . 1727 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1728 Writing an IANA Considerations Section in RFCs", BCP 26, 1729 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1730 . 1732 Appendix A. Collected ABNF 1734 In the collected ABNF below, list rules are expanded as per 1735 Section 5.6.1.1 of [Semantics]. 1737 Age = delta-seconds 1739 Cache-Control = [ cache-directive *( OWS "," OWS cache-directive ) ] 1741 Expires = HTTP-date 1743 HTTP-date = 1745 OWS = 1747 cache-directive = token [ "=" ( token / quoted-string ) ] 1749 delta-seconds = 1*DIGIT 1751 field-name = 1753 quoted-string = 1755 token = 1757 Appendix B. Changes from RFC 7234 1759 Handling of duplicate and conflicting cache directives has been 1760 clarified. (Section 4.2.1) 1762 Cache invalidation of the URIs in the Location and Content-Location 1763 header fields is no longer required, but still allowed. 1764 (Section 4.4) 1766 Cache invalidation of the URIs in the Location and Content-Location 1767 header fields is disallowed when the origin is different; previously, 1768 it was the host. (Section 4.4) 1770 Handling invalid and multiple Age header field values has been 1771 clarified. (Section 5.1) 1773 Some cache directives defined by this specification now have stronger 1774 prohibitions against generating the quoted form of their values, 1775 since this has been found to create interoperability problems. 1776 Consumers of extension cache directives are no longer required to 1777 accept both token and quoted-string forms, but they still need to 1778 parse them properly for unknown extensions. (Section 5.2) 1779 The "public" and "private" cache directives were clarified, so that 1780 they do not make responses reusable under any condition. 1781 (Section 5.2.2) 1783 The "must-understand" cache directive was introduced; caches are no 1784 longer required to understand the semantics of new response status 1785 codes unless it is present. (Section 5.2.2.2) 1787 The Warning response header was obsoleted. Much of the information 1788 supported by Warning could be gleaned by examining the response, and 1789 the remaining warn-codes - although potentially useful - were 1790 entirely advisory. In practice, Warning was not added by caches or 1791 intermediaries. (Section 5.5) 1793 Appendix C. Change Log 1795 This section is to be removed before publishing as an RFC. 1797 C.1. Between RFC7234 and draft 00 1799 The changes were purely editorial: 1801 o Change boilerplate and abstract to indicate the "draft" status, 1802 and update references to ancestor specifications. 1804 o Remove version "1.1" from document title, indicating that this 1805 specification applies to all HTTP versions. 1807 o Adjust historical notes. 1809 o Update links to sibling specifications. 1811 o Replace sections listing changes from RFC 2616 by new empty 1812 sections referring to RFC 723x. 1814 o Remove acknowledgements specific to RFC 723x. 1816 o Move "Acknowledgements" to the very end and make them unnumbered. 1818 C.2. Since draft-ietf-httpbis-cache-00 1820 The changes are purely editorial: 1822 o Moved all extensibility tips, registration procedures, and 1823 registry tables from the IANA considerations to normative 1824 sections, reducing the IANA considerations to just instructions 1825 that will be removed prior to publication as an RFC. 1827 C.3. Since draft-ietf-httpbis-cache-01 1829 o Cite RFC 8126 instead of RFC 5226 () 1832 o In Section 5.4, misleading statement about the relation between 1833 Pragma and Cache-Control (, ) 1836 C.4. Since draft-ietf-httpbis-cache-02 1838 o In Section 3, explain that only final responses are cacheable 1839 () 1841 o In Section 5.2.2, clarify what responses various directives apply 1842 to () 1844 o In Section 4.3.1, clarify the source of validators in conditional 1845 requests () 1847 o Revise Section 6 to apply to more than just History Lists 1848 () 1850 o In Section 5.5, deprecated "Warning" header field 1851 () 1853 o In Section 3.5, remove a spurious note 1854 () 1856 C.5. Since draft-ietf-httpbis-cache-03 1858 o In Section 2, define what a disconnected cache is 1859 () 1861 o In Section 4, clarify language around how to select a response 1862 when more than one matches () 1865 o in Section 4.2.4, mention stale-while-revalidate and stale-if- 1866 error () 1868 o Remove requirements around cache request directives 1869 () 1871 o Deprecate Pragma () 1874 o In Section 3.5 and Section 5.2.2, note effect of some directives 1875 on authenticated requests () 1878 C.6. Since draft-ietf-httpbis-cache-04 1880 o In Section 5.2, remove the registrations for stale-if-error and 1881 stale-while-revalidate which happened in RFC 7234 1882 () 1884 C.7. Since draft-ietf-httpbis-cache-05 1886 o In Section 3.3, clarify how weakly framed content is considered 1887 for purposes of completeness () 1890 o Throughout, describe Vary and cache key operations more clearly 1891 () 1893 o In Section 3, remove concept of "cacheable methods" in favor of 1894 prose (, 1895 ) 1897 o Refactored Section 7, and added a section on timing attacks 1898 () 1900 o Changed "cacheable by default" to "heuristically cacheable" 1901 throughout () 1903 C.8. Since draft-ietf-httpbis-cache-06 1905 o In Section 3 and Section 5.2.2.2, change response cacheability to 1906 only require understanding the response status code if the must- 1907 understand cache directive is present () 1910 o Change requirements for handling different forms of cache 1911 directives in Section 5.2 () 1914 o Fix typo in Section 5.2.2.10 () 1917 o In Section 5.2.2.6 and Section 5.2.2.7, clarify "private" and 1918 "public" so that they do not override all other cache directives 1919 () 1921 o In Section 3, distinguish between private with and without 1922 qualifying headers () 1925 o In Section 4.1, clarify that any "*" as a member of Vary will 1926 disable caching () 1928 o In Section 1.1, reference RFC 8174 as well 1929 () 1931 C.9. Since draft-ietf-httpbis-cache-07 1933 o Throughout, replace "effective request URI", "request-target" and 1934 similar with "target URI" () 1937 o In Section 5.2.2.6 and Section 5.2.2.7, make it clear that these 1938 directives do not ignore other requirements for caching 1939 () 1941 o In Section 3.3, move definition of "complete" into semantics 1942 () 1944 C.10. Since draft-ietf-httpbis-cache-08 1946 o Appendix A now uses the sender variant of the "#" list expansion 1947 () 1949 C.11. Since draft-ietf-httpbis-cache-09 1951 o In Section 5.1, discuss handling of invalid and multiple Age 1952 header field values () 1955 o Switch to xml2rfc v3 mode for draft generation 1956 () 1958 C.12. Since draft-ietf-httpbis-cache-10 1960 o In Section 5.2 (Cache-Control), adjust ABNF to allow empty lists 1961 () 1963 C.13. Since draft-ietf-httpbis-cache-11 1965 o None. 1967 C.14. Since draft-ietf-httpbis-cache-12 1968 o In Section 4.2.4, remove 'no-store', as it won't be in cache in 1969 the first place () 1971 o In Section 3.1, make it clear that only response headers need be 1972 stored () 1974 o Rewrote "Updating Stored Header Fields" Section 3.2 1975 () 1977 o In Section 4.2.1 clarify how to handle invalid and conflicting 1978 directives () 1980 o In Section 4.3.3, mention retry of failed validation requests 1981 () 1983 o In Section 4.3.3, clarify requirement on storing a full response 1984 to a conditional request () 1987 o In Section 5.1, clarify error handling 1988 () 1990 o In Section 4.2, remove spurious "UTC" () 1993 o In Section 4.2, correct the date-related rule names to consider 1994 case-insensitive () 1997 o In Section 6, strengthen recommendation for application caches to 1998 pay attention to cache directives () 2001 o In Section 4, mention collapsed requests 2002 () 2004 o In Section 4.4, relax requirements on Content-Location and 2005 Location invalidation () 2008 o In Section 4.3.4, refine the exceptions to update on a 304 2009 () 2011 o Moved table of Cache-Control directives into Section 8.2 2012 () 2014 o In Section 1.2, remove unused core ABNF rules 2015 () 2017 o Changed to using "payload data" when defining requirements about 2018 the data being conveyed within a message, instead of the terms 2019 "payload body" or "response body" or "representation body", since 2020 they often get confused with the HTTP/1.1 message body (which 2021 includes transfer coding) () 2024 C.15. Since draft-ietf-httpbis-cache-13 2026 o In Section 5.2.2.1, clarify requirements around generating an 2027 error response () 2029 o Changed to using "content" instead of "payload" or "payload data" 2030 to avoid confusion with the payload of version-specific messaging 2031 frames () 2033 o In Section 4.3.4, clarify how multiple validators are handled 2034 () 2036 o In Section 4.2.3, Section 5.2, and Section 5.2.2.3, remove notes 2037 about very old HTTP/1.0 behaviours () 2040 o In Section 5.2.2.2, modify operation to be more backwards- 2041 compatible with existing implementations 2042 () 2044 Acknowledgments 2046 See Appendix "Acknowledgments" of [Semantics]. 2048 Authors' Addresses 2050 Roy T. Fielding (editor) 2051 Adobe 2052 345 Park Ave 2053 San Jose, CA 95110 2054 United States of America 2056 Email: fielding@gbiv.com 2057 URI: https://roy.gbiv.com/ 2059 Mark Nottingham (editor) 2060 Fastly 2061 Prahran VIC 2062 Australia 2063 Email: mnot@mnot.net 2064 URI: https://www.mnot.net/ 2066 Julian Reschke (editor) 2067 greenbytes GmbH 2068 Hafenweg 16 2069 48155 Münster 2070 Germany 2072 Email: julian.reschke@greenbytes.de 2073 URI: https://greenbytes.de/tech/webdav/