idnits 2.17.1 draft-fielding-httpbis-http-cache-00.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 (March 5, 2018) is 2242 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 1723, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network 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: September 6, 2018 J. Reschke, Ed. 7 greenbytes 8 March 5, 2018 10 Hypertext Transfer Protocol (HTTP): Caching 11 draft-fielding-httpbis-http-cache-00 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 _This is a temporary document for the purpose of planning the 28 revisions of RFCs 7230 to 7235. This is not yet an official work 29 item of the HTTP Working Group._ 31 Discussion of this draft takes place on the HTTP working group 32 mailing list (ietf-http-wg@w3.org), which is archived at 33 . 35 Errata for RFC 7234 have been collected at , and an additional issues list 37 lives at . 39 The changes in this draft are summarized in Appendix D.1. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 6, 2018. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 This document may contain material from IETF Documents or IETF 74 Contributions published or made publicly available before November 75 10, 2008. The person(s) controlling the copyright in some of this 76 material may not have granted the IETF Trust the right to allow 77 modifications of such material outside the IETF Standards Process. 78 Without obtaining an adequate license from the person(s) controlling 79 the copyright in such materials, this document may not be modified 80 outside the IETF Standards Process, and derivative works of it may 81 not be created outside the IETF Standards Process, except to format 82 it for publication as an RFC or to translate it into languages other 83 than English. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 88 1.1. Conformance and Error Handling . . . . . . . . . . . . . 4 89 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 90 1.2.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 5 91 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 5 92 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 6 93 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . 7 94 3.2. Storing Responses to Authenticated Requests . . . . . . . 7 95 3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8 97 4. Constructing Responses from Caches . . . . . . . . . . . . . 8 98 4.1. Calculating Secondary Keys with Vary . . . . . . . . . . 10 99 4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11 100 4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 12 101 4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 13 102 4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 103 4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 104 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 15 105 4.3.1. Sending a Validation Request . . . . . . . . . . . . 16 106 4.3.2. Handling a Received Validation Request . . . . . . . 16 107 4.3.3. Handling a Validation Response . . . . . . . . . . . 18 108 4.3.4. Freshening Stored Responses upon Validation . . . . . 18 109 4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 19 110 4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 20 111 5. Header Field Definitions . . . . . . . . . . . . . . . . . . 20 112 5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 113 5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 114 5.2.1. Request Cache-Control Directives . . . . . . . . . . 22 115 5.2.2. Response Cache-Control Directives . . . . . . . . . . 24 116 5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 27 117 5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 118 5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 28 119 5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 120 5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . 31 121 5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . 31 122 5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31 123 5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31 124 5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . 31 125 5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 32 126 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 32 127 6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32 128 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 129 7.1. Cache Directive Registry . . . . . . . . . . . . . . . . 32 130 7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32 131 7.1.2. Considerations for New Cache Control Directives . . . 33 132 7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 33 133 7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . 33 134 7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 34 135 7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 34 136 7.3. Header Field Registration . . . . . . . . . . . . . . . . 34 137 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 138 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 139 9.1. Normative References . . . . . . . . . . . . . . . . . . 36 140 9.2. Informative References . . . . . . . . . . . . . . . . . 36 141 Appendix A. Changes from RFC 7234 . . . . . . . . . . . . . . . 38 142 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . 38 143 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38 144 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 39 145 D.1. Since RFC 7234 . . . . . . . . . . . . . . . . . . . . . 40 146 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 147 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42 148 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 150 1. Introduction 152 HTTP is typically used for distributed information systems, where 153 performance can be improved by the use of response caches. This 154 document defines aspects of HTTP/1.1 related to caching and reusing 155 response messages. 157 An HTTP cache is a local store of response messages and the subsystem 158 that controls storage, retrieval, and deletion of messages in it. A 159 cache stores cacheable responses in order to reduce the response time 160 and network bandwidth consumption on future, equivalent requests. 161 Any client or server MAY employ a cache, though a cache cannot be 162 used by a server that is acting as a tunnel. 164 A shared cache is a cache that stores responses to be reused by more 165 than one user; shared caches are usually (but not always) deployed as 166 a part of an intermediary. A private cache, in contrast, is 167 dedicated to a single user; often, they are deployed as a component 168 of a user agent. 170 The goal of caching in HTTP/1.1 is to significantly improve 171 performance by reusing a prior response message to satisfy a current 172 request. A stored response is considered "fresh", as defined in 173 Section 4.2, if the response can be reused without "validation" 174 (checking with the origin server to see if the cached response 175 remains valid for this request). A fresh response can therefore 176 reduce both latency and network overhead each time it is reused. 177 When a cached response is not fresh, it might still be reusable if it 178 can be freshened by validation (Section 4.3) or if the origin is 179 unavailable (Section 4.2.4). 181 This specification obsoletes RFC 7234, with the changes being 182 summarized in Appendix A. 184 1.1. Conformance and Error Handling 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 Conformance criteria and considerations regarding error handling are 191 defined in Section 2.5 of [MESSGNG]. 193 1.2. Syntax Notation 195 This specification uses the Augmented Backus-Naur Form (ABNF) 196 notation of [RFC5234] with a list extension, defined in Section 7 of 197 [MESSGNG], that allows for compact definition of comma-separated 198 lists using a '#' operator (similar to how the '*' operator indicates 199 repetition). Appendix B describes rules imported from other 200 documents. Appendix C shows the collected grammar with all list 201 operators expanded to standard ABNF notation. 203 1.2.1. Delta Seconds 205 The delta-seconds rule specifies a non-negative integer, representing 206 time in seconds. 208 delta-seconds = 1*DIGIT 210 A recipient parsing a delta-seconds value and converting it to binary 211 form ought to use an arithmetic type of at least 31 bits of non- 212 negative integer range. If a cache receives a delta-seconds value 213 greater than the greatest integer it can represent, or if any of its 214 subsequent calculations overflows, the cache MUST consider the value 215 to be either 2147483648 (2^31) or the greatest positive integer it 216 can conveniently represent. 218 Note: The value 2147483648 is here for historical reasons, 219 effectively represents infinity (over 68 years), and does not need 220 to be stored in binary form; an implementation could produce it as 221 a canned string if any overflow occurs, even if the calculations 222 are performed with an arithmetic type incapable of directly 223 representing that number. What matters here is that an overflow 224 be detected and not treated as a negative value in later 225 calculations. 227 2. Overview of Cache Operation 229 Proper cache operation preserves the semantics of HTTP transfers 230 ([SEMNTCS]) while eliminating the transfer of information already 231 held in the cache. Although caching is an entirely OPTIONAL feature 232 of HTTP, it can be assumed that reusing a cached response is 233 desirable and that such reuse is the default behavior when no 234 requirement or local configuration prevents it. Therefore, HTTP 235 cache requirements are focused on preventing a cache from either 236 storing a non-reusable response or reusing a stored response 237 inappropriately, rather than mandating that caches always store and 238 reuse particular responses. 240 Each cache entry consists of a cache key and one or more HTTP 241 responses corresponding to prior requests that used the same key. 242 The most common form of cache entry is a successful result of a 243 retrieval request: i.e., a 200 (OK) response to a GET request, which 244 contains a representation of the resource identified by the request 245 target (Section 4.3.1 of [SEMNTCS]). However, it is also possible to 246 cache permanent redirects, negative results (e.g., 404 (Not Found)), 247 incomplete results (e.g., 206 (Partial Content)), and responses to 248 methods other than GET if the method's definition allows such caching 249 and defines something suitable for use as a cache key. 251 The primary cache key consists of the request method and target URI. 252 However, since HTTP caches in common use today are typically limited 253 to caching responses to GET, many caches simply decline other methods 254 and use only the URI as the primary cache key. 256 If a request target is subject to content negotiation, its cache 257 entry might consist of multiple stored responses, each differentiated 258 by a secondary key for the values of the original request's selecting 259 header fields (Section 4.1). 261 3. Storing Responses in Caches 263 A cache MUST NOT store a response to any request, unless: 265 o The request method is understood by the cache and defined as being 266 cacheable, and 268 o the response status code is understood by the cache, and 270 o the "no-store" cache directive (see Section 5.2) does not appear 271 in request or response header fields, and 273 o the "private" response directive (see Section 5.2.2.6) does not 274 appear in the response, if the cache is shared, and 276 o the Authorization header field (see Section 4.2 of [AUTHFRM]) does 277 not appear in the request, if the cache is shared, unless the 278 response explicitly allows it (see Section 3.2), and 280 o the response either: 282 * contains an Expires header field (see Section 5.3), or 284 * contains a max-age response directive (see Section 5.2.2.8), or 286 * contains a s-maxage response directive (see Section 5.2.2.9) 287 and the cache is shared, or 289 * contains a Cache Control Extension (see Section 5.2.3) that 290 allows it to be cached, or 292 * has a status code that is defined as cacheable by default (see 293 Section 4.2.2), or 295 * contains a public response directive (see Section 5.2.2.5). 297 Note that any of the requirements listed above can be overridden by a 298 cache-control extension; see Section 5.2.3. 300 In this context, a cache has "understood" a request method or a 301 response status code if it recognizes it and implements all specified 302 caching-related behavior. 304 Note that, in normal operation, some caches will not store a response 305 that has neither a cache validator nor an explicit expiration time, 306 as such responses are not usually useful to store. However, caches 307 are not prohibited from storing such responses. 309 3.1. Storing Incomplete Responses 311 A response message is considered complete when all of the octets 312 indicated by the message framing ([MESSGNG]) are received prior to 313 the connection being closed. If the request method is GET, the 314 response status code is 200 (OK), and the entire response header 315 section has been received, a cache MAY store an incomplete response 316 message body if the cache entry is recorded as incomplete. Likewise, 317 a 206 (Partial Content) response MAY be stored as if it were an 318 incomplete 200 (OK) cache entry. However, a cache MUST NOT store 319 incomplete or partial-content responses if it does not support the 320 Range and Content-Range header fields or if it does not understand 321 the range units used in those fields. 323 A cache MAY complete a stored incomplete response by making a 324 subsequent range request ([RANGERQ]) and combining the successful 325 response with the stored entry, as defined in Section 3.3. A cache 326 MUST NOT use an incomplete response to answer requests unless the 327 response has been made complete or the request is partial and 328 specifies a range that is wholly within the incomplete response. A 329 cache MUST NOT send a partial response to a client without explicitly 330 marking it as such using the 206 (Partial Content) status code. 332 3.2. Storing Responses to Authenticated Requests 334 A shared cache MUST NOT use a cached response to a request with an 335 Authorization header field (Section 4.2 of [AUTHFRM]) to satisfy any 336 subsequent request unless a cache directive that allows such 337 responses to be stored is present in the response. 339 In this specification, the following Cache-Control response 340 directives (Section 5.2.2) have such an effect: must-revalidate, 341 public, and s-maxage. 343 Note that cached responses that contain the "must-revalidate" and/or 344 "s-maxage" response directives are not allowed to be served stale 345 (Section 4.2.4) by shared caches. In particular, a response with 346 either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to 347 satisfy a subsequent request without revalidating it on the origin 348 server. 350 3.3. Combining Partial Content 352 A response might transfer only a partial representation if the 353 connection closed prematurely or if the request used one or more 354 Range specifiers ([RANGERQ]). After several such transfers, a cache 355 might have received several ranges of the same representation. A 356 cache MAY combine these ranges into a single stored response, and 357 reuse that response to satisfy later requests, if they all share the 358 same strong validator and the cache complies with the client 359 requirements in Section 4.3 of [RANGERQ]. 361 When combining the new response with one or more stored responses, a 362 cache MUST: 364 o delete any Warning header fields in the stored response with warn- 365 code 1xx (see Section 5.5); 367 o retain any Warning header fields in the stored response with warn- 368 code 2xx; and, 370 o use other header fields provided in the new response, aside from 371 Content-Range, to replace all instances of the corresponding 372 header fields in the stored response. 374 4. Constructing Responses from Caches 376 When presented with a request, a cache MUST NOT reuse a stored 377 response, unless: 379 o The presented effective request URI (Section 5.5 of [MESSGNG]) and 380 that of the stored response match, and 382 o the request method associated with the stored response allows it 383 to be used for the presented request, and 385 o selecting header fields nominated by the stored response (if any) 386 match those presented (see Section 4.1), and 388 o the presented request does not contain the no-cache pragma 389 (Section 5.4), nor the no-cache cache directive (Section 5.2.1), 390 unless the stored response is successfully validated 391 (Section 4.3), and 393 o the stored response does not contain the no-cache cache directive 394 (Section 5.2.2.2), unless it is successfully validated 395 (Section 4.3), and 397 o the stored response is either: 399 * fresh (see Section 4.2), or 401 * allowed to be served stale (see Section 4.2.4), or 403 * successfully validated (see Section 4.3). 405 Note that any of the requirements listed above can be overridden by a 406 cache-control extension; see Section 5.2.3. 408 When a stored response is used to satisfy a request without 409 validation, a cache MUST generate an Age header field (Section 5.1), 410 replacing any present in the response with a value equal to the 411 stored response's current_age; see Section 4.2.3. 413 A cache MUST write through requests with methods that are unsafe 414 (Section 4.2.1 of [SEMNTCS]) to the origin server; i.e., a cache is 415 not allowed to generate a reply to such a request before having 416 forwarded the request and having received a corresponding response. 418 Also, note that unsafe requests might invalidate already-stored 419 responses; see Section 4.4. 421 When more than one suitable response is stored, a cache MUST use the 422 most recent response (as determined by the Date header field). It 423 can also forward the request with "Cache-Control: max-age=0" or 424 "Cache-Control: no-cache" to disambiguate which response to use. 426 A cache that does not have a clock available MUST NOT use stored 427 responses without revalidating them upon every use. 429 4.1. Calculating Secondary Keys with Vary 431 When a cache receives a request that can be satisfied by a stored 432 response that has a Vary header field (Section 7.1.4 of [SEMNTCS]), 433 it MUST NOT use that response unless all of the selecting header 434 fields nominated by the Vary header field match in both the original 435 request (i.e., that associated with the stored response), and the 436 presented request. 438 The selecting header fields from two requests are defined to match if 439 and only if those in the first request can be transformed to those in 440 the second request by applying any of the following: 442 o adding or removing whitespace, where allowed in the header field's 443 syntax 445 o combining multiple header fields with the same field name (see 446 Section 3.2 of [MESSGNG]) 448 o normalizing both header field values in a way that is known to 449 have identical semantics, according to the header field's 450 specification (e.g., reordering field values when order is not 451 significant; case-normalization, where values are defined to be 452 case-insensitive) 454 If (after any normalization that might take place) a header field is 455 absent from a request, it can only match another request if it is 456 also absent there. 458 A Vary header field-value of "*" always fails to match. 460 The stored response with matching selecting header fields is known as 461 the selected response. 463 If multiple selected responses are available (potentially including 464 responses without a Vary header field), the cache will need to choose 465 one to use. When a selecting header field has a known mechanism for 466 doing so (e.g., qvalues on Accept and similar request header fields), 467 that mechanism MAY be used to select preferred responses; of the 468 remainder, the most recent response (as determined by the Date header 469 field) is used, as per Section 4. 471 If no selected response is available, the cache cannot satisfy the 472 presented request. Typically, it is forwarded to the origin server 473 in a (possibly conditional; see Section 4.3) request. 475 4.2. Freshness 477 A fresh response is one whose age has not yet exceeded its freshness 478 lifetime. Conversely, a stale response is one where it has. 480 A response's freshness lifetime is the length of time between its 481 generation by the origin server and its expiration time. An explicit 482 expiration time is the time at which the origin server intends that a 483 stored response can no longer be used by a cache without further 484 validation, whereas a heuristic expiration time is assigned by a 485 cache when no explicit expiration time is available. 487 A response's age is the time that has passed since it was generated 488 by, or successfully validated with, the origin server. 490 When a response is "fresh" in the cache, it can be used to satisfy 491 subsequent requests without contacting the origin server, thereby 492 improving efficiency. 494 The primary mechanism for determining freshness is for an origin 495 server to provide an explicit expiration time in the future, using 496 either the Expires header field (Section 5.3) or the max-age response 497 directive (Section 5.2.2.8). Generally, origin servers will assign 498 future explicit expiration times to responses in the belief that the 499 representation is not likely to change in a semantically significant 500 way before the expiration time is reached. 502 If an origin server wishes to force a cache to validate every 503 request, it can assign an explicit expiration time in the past to 504 indicate that the response is already stale. Compliant caches will 505 normally validate a stale cached response before reusing it for 506 subsequent requests (see Section 4.2.4). 508 Since origin servers do not always provide explicit expiration times, 509 caches are also allowed to use a heuristic to determine an expiration 510 time under certain circumstances (see Section 4.2.2). 512 The calculation to determine if a response is fresh is: 514 response_is_fresh = (freshness_lifetime > current_age) 516 freshness_lifetime is defined in Section 4.2.1; current_age is 517 defined in Section 4.2.3. 519 Clients can send the max-age or min-fresh cache directives in a 520 request to constrain or relax freshness calculations for the 521 corresponding response (Section 5.2.1). 523 When calculating freshness, to avoid common problems in date parsing: 525 o Although all date formats are specified to be case-sensitive, a 526 cache recipient SHOULD match day, week, and time-zone names case- 527 insensitively. 529 o If a cache recipient's internal implementation of time has less 530 resolution than the value of an HTTP-date, the recipient MUST 531 internally represent a parsed Expires date as the nearest time 532 equal to or earlier than the received value. 534 o A cache recipient MUST NOT allow local time zones to influence the 535 calculation or comparison of an age or expiration time. 537 o A cache recipient SHOULD consider a date with a zone abbreviation 538 other than GMT or UTC to be invalid for calculating expiration. 540 Note that freshness applies only to cache operation; it cannot be 541 used to force a user agent to refresh its display or reload a 542 resource. See Section 6 for an explanation of the difference between 543 caches and history mechanisms. 545 4.2.1. Calculating Freshness Lifetime 547 A cache can calculate the freshness lifetime (denoted as 548 freshness_lifetime) of a response by using the first match of the 549 following: 551 o If the cache is shared and the s-maxage response directive 552 (Section 5.2.2.9) is present, use its value, or 554 o If the max-age response directive (Section 5.2.2.8) is present, 555 use its value, or 557 o If the Expires response header field (Section 5.3) is present, use 558 its value minus the value of the Date response header field, or 560 o Otherwise, no explicit expiration time is present in the response. 561 A heuristic freshness lifetime might be applicable; see 562 Section 4.2.2. 564 Note that this calculation is not vulnerable to clock skew, since all 565 of the information comes from the origin server. 567 When there is more than one value present for a given directive 568 (e.g., two Expires header fields, multiple Cache-Control: max-age 569 directives), the directive's value is considered invalid. Caches are 570 encouraged to consider responses that have invalid freshness 571 information to be stale. 573 4.2.2. Calculating Heuristic Freshness 575 Since origin servers do not always provide explicit expiration times, 576 a cache MAY assign a heuristic expiration time when an explicit time 577 is not specified, employing algorithms that use other header field 578 values (such as the Last-Modified time) to estimate a plausible 579 expiration time. This specification does not provide specific 580 algorithms, but does impose worst-case constraints on their results. 582 A cache MUST NOT use heuristics to determine freshness when an 583 explicit expiration time is present in the stored response. Because 584 of the requirements in Section 3, this means that, effectively, 585 heuristics can only be used on responses without explicit freshness 586 whose status codes are defined as cacheable by default (see 587 Section 6.1 of [SEMNTCS]), and those responses without explicit 588 freshness that have been marked as explicitly cacheable (e.g., with a 589 "public" response directive). 591 If the response has a Last-Modified header field (Section 2.2 of 592 [CONDTNL]), caches are encouraged to use a heuristic expiration value 593 that is no more than some fraction of the interval since that time. 594 A typical setting of this fraction might be 10%. 596 When a heuristic is used to calculate freshness lifetime, a cache 597 SHOULD generate a Warning header field with a 113 warn-code (see 598 Section 5.5.4) in the response if its current_age is more than 24 599 hours and such a warning is not already present. 601 Note: Section 13.9 of [RFC2616] prohibited caches from calculating 602 heuristic freshness for URIs with query components (i.e., those 603 containing '?'). In practice, this has not been widely 604 implemented. Therefore, origin servers are encouraged to send 605 explicit directives (e.g., Cache-Control: no-cache) if they wish 606 to preclude caching. 608 4.2.3. Calculating Age 610 The Age header field is used to convey an estimated age of the 611 response message when obtained from a cache. The Age field value is 612 the cache's estimate of the number of seconds since the response was 613 generated or validated by the origin server. In essence, the Age 614 value is the sum of the time that the response has been resident in 615 each of the caches along the path from the origin server, plus the 616 amount of time it has been in transit along network paths. 618 The following data is used for the age calculation: 620 age_value 622 The term "age_value" denotes the value of the Age header field 623 (Section 5.1), in a form appropriate for arithmetic operation; or 624 0, if not available. 626 date_value 628 The term "date_value" denotes the value of the Date header field, 629 in a form appropriate for arithmetic operations. See 630 Section 7.1.1.2 of [SEMNTCS] for the definition of the Date header 631 field, and for requirements regarding responses without it. 633 now 635 The term "now" means "the current value of the clock at the host 636 performing the calculation". A host ought to use NTP ([RFC5905]) 637 or some similar protocol to synchronize its clocks to Coordinated 638 Universal Time. 640 request_time 642 The current value of the clock at the host at the time the request 643 resulting in the stored response was made. 645 response_time 647 The current value of the clock at the host at the time the 648 response was received. 650 A response's age can be calculated in two entirely independent ways: 652 1. the "apparent_age": response_time minus date_value, if the local 653 clock is reasonably well synchronized to the origin server's 654 clock. If the result is negative, the result is replaced by 655 zero. 657 2. the "corrected_age_value", if all of the caches along the 658 response path implement HTTP/1.1. A cache MUST interpret this 659 value relative to the time the request was initiated, not the 660 time that the response was received. 662 apparent_age = max(0, response_time - date_value); 664 response_delay = response_time - request_time; 665 corrected_age_value = age_value + response_delay; 667 These are combined as 669 corrected_initial_age = max(apparent_age, corrected_age_value); 671 unless the cache is confident in the value of the Age header field 672 (e.g., because there are no HTTP/1.0 hops in the Via header field), 673 in which case the corrected_age_value MAY be used as the 674 corrected_initial_age. 676 The current_age of a stored response can then be calculated by adding 677 the amount of time (in seconds) since the stored response was last 678 validated by the origin server to the corrected_initial_age. 680 resident_time = now - response_time; 681 current_age = corrected_initial_age + resident_time; 683 4.2.4. Serving Stale Responses 685 A "stale" response is one that either has explicit expiry information 686 or is allowed to have heuristic expiry calculated, but is not fresh 687 according to the calculations in Section 4.2. 689 A cache MUST NOT generate a stale response if it is prohibited by an 690 explicit in-protocol directive (e.g., by a "no-store" or "no-cache" 691 cache directive, a "must-revalidate" cache-response-directive, or an 692 applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 693 see Section 5.2.2). 695 A cache MUST NOT send stale responses unless it is disconnected 696 (i.e., it cannot contact the origin server or otherwise find a 697 forward path) or doing so is explicitly allowed (e.g., by the max- 698 stale request directive; see Section 5.2.1). 700 A cache SHOULD generate a Warning header field with the 110 warn-code 701 (see Section 5.5.1) in stale responses. Likewise, a cache SHOULD 702 generate a 112 warn-code (see Section 5.5.3) in stale responses if 703 the cache is disconnected. 705 A cache SHOULD NOT generate a new Warning header field when 706 forwarding a response that does not have an Age header field, even if 707 the response is already stale. A cache need not validate a response 708 that merely became stale in transit. 710 4.3. Validation 712 When a cache has one or more stored responses for a requested URI, 713 but cannot serve any of them (e.g., because they are not fresh, or 714 one cannot be selected; see Section 4.1), it can use the conditional 715 request mechanism [CONDTNL] in the forwarded request to give the next 716 inbound server an opportunity to select a valid stored response to 717 use, updating the stored metadata in the process, or to replace the 718 stored response(s) with a new response. This process is known as 719 "validating" or "revalidating" the stored response. 721 4.3.1. Sending a Validation Request 723 When sending a conditional request for cache validation, a cache 724 sends one or more precondition header fields containing validator 725 metadata from its stored response(s), which is then compared by 726 recipients to determine whether a stored response is equivalent to a 727 current representation of the resource. 729 One such validator is the timestamp given in a Last-Modified header 730 field (Section 2.2 of [CONDTNL]), which can be used in an If- 731 Modified-Since header field for response validation, or in an If- 732 Unmodified-Since or If-Range header field for representation 733 selection (i.e., the client is referring specifically to a previously 734 obtained representation with that timestamp). 736 Another validator is the entity-tag given in an ETag header field 737 (Section 2.3 of [CONDTNL]). One or more entity-tags, indicating one 738 or more stored responses, can be used in an If-None-Match header 739 field for response validation, or in an If-Match or If-Range header 740 field for representation selection (i.e., the client is referring 741 specifically to one or more previously obtained representations with 742 the listed entity-tags). 744 4.3.2. Handling a Received Validation Request 746 Each client in the request chain may have its own cache, so it is 747 common for a cache at an intermediary to receive conditional requests 748 from other (outbound) caches. Likewise, some user agents make use of 749 conditional requests to limit data transfers to recently modified 750 representations or to complete the transfer of a partially retrieved 751 representation. 753 If a cache receives a request that can be satisfied by reusing one of 754 its stored 200 (OK) or 206 (Partial Content) responses, the cache 755 SHOULD evaluate any applicable conditional header field preconditions 756 received in that request with respect to the corresponding validators 757 contained within the selected response. A cache MUST NOT evaluate 758 conditional header fields that are only applicable to an origin 759 server, found in a request with semantics that cannot be satisfied 760 with a cached response, or applied to a target resource for which it 761 has no stored responses; such preconditions are likely intended for 762 some other (inbound) server. 764 The proper evaluation of conditional requests by a cache depends on 765 the received precondition header fields and their precedence, as 766 defined in Section 6 of [CONDTNL]. The If-Match and If-Unmodified- 767 Since conditional header fields are not applicable to a cache. 769 A request containing an If-None-Match header field (Section 3.2 of 770 [CONDTNL]) indicates that the client wants to validate one or more of 771 its own stored responses in comparison to whichever stored response 772 is selected by the cache. If the field-value is "*", or if the 773 field-value is a list of entity-tags and at least one of them matches 774 the entity-tag of the selected stored response, a cache recipient 775 SHOULD generate a 304 (Not Modified) response (using the metadata of 776 the selected stored response) instead of sending that stored 777 response. 779 When a cache decides to revalidate its own stored responses for a 780 request that contains an If-None-Match list of entity-tags, the cache 781 MAY combine the received list with a list of entity-tags from its own 782 stored set of responses (fresh or stale) and send the union of the 783 two lists as a replacement If-None-Match header field value in the 784 forwarded request. If a stored response contains only partial 785 content, the cache MUST NOT include its entity-tag in the union 786 unless the request is for a range that would be fully satisfied by 787 that partial stored response. If the response to the forwarded 788 request is 304 (Not Modified) and has an ETag header field value with 789 an entity-tag that is not in the client's list, the cache MUST 790 generate a 200 (OK) response for the client by reusing its 791 corresponding stored response, as updated by the 304 response 792 metadata (Section 4.3.4). 794 If an If-None-Match header field is not present, a request containing 795 an If-Modified-Since header field (Section 3.3 of [CONDTNL]) 796 indicates that the client wants to validate one or more of its own 797 stored responses by modification date. A cache recipient SHOULD 798 generate a 304 (Not Modified) response (using the metadata of the 799 selected stored response) if one of the following cases is true: 1) 800 the selected stored response has a Last-Modified field-value that is 801 earlier than or equal to the conditional timestamp; 2) no Last- 802 Modified field is present in the selected stored response, but it has 803 a Date field-value that is earlier than or equal to the conditional 804 timestamp; or, 3) neither Last-Modified nor Date is present in the 805 selected stored response, but the cache recorded it as having been 806 received at a time earlier than or equal to the conditional 807 timestamp. 809 A cache that implements partial responses to range requests, as 810 defined in [RANGERQ], also needs to evaluate a received If-Range 811 header field (Section 3.2 of [RANGERQ]) with respect to its selected 812 stored response. 814 4.3.3. Handling a Validation Response 816 Cache handling of a response to a conditional request is dependent 817 upon its status code: 819 o A 304 (Not Modified) response status code indicates that the 820 stored response can be updated and reused; see Section 4.3.4. 822 o A full response (i.e., one with a payload body) indicates that 823 none of the stored responses nominated in the conditional request 824 is suitable. Instead, the cache MUST use the full response to 825 satisfy the request and MAY replace the stored response(s). 827 o However, if a cache receives a 5xx (Server Error) response while 828 attempting to validate a response, it can either forward this 829 response to the requesting client, or act as if the server failed 830 to respond. In the latter case, the cache MAY send a previously 831 stored response (see Section 4.2.4). 833 4.3.4. Freshening Stored Responses upon Validation 835 When a cache receives a 304 (Not Modified) response and already has 836 one or more stored 200 (OK) responses for the same cache key, the 837 cache needs to identify which of the stored responses are updated by 838 this new response and then update the stored response(s) with the new 839 information provided in the 304 response. 841 The stored response to update is identified by using the first match 842 (if any) of the following: 844 o If the new response contains a strong validator (see Section 2.1 845 of [CONDTNL]), then that strong validator identifies the selected 846 representation for update. All of the stored responses with the 847 same strong validator are selected. If none of the stored 848 responses contain the same strong validator, then the cache MUST 849 NOT use the new response to update any stored responses. 851 o If the new response contains a weak validator and that validator 852 corresponds to one of the cache's stored responses, then the most 853 recent of those matching stored responses is selected for update. 855 o If the new response does not include any form of validator (such 856 as in the case where a client generates an If-Modified-Since 857 request from a source other than the Last-Modified response header 858 field), and there is only one stored response, and that stored 859 response also lacks a validator, then that stored response is 860 selected for update. 862 If a stored response is selected for update, the cache MUST: 864 o delete any Warning header fields in the stored response with warn- 865 code 1xx (see Section 5.5); 867 o retain any Warning header fields in the stored response with warn- 868 code 2xx; and, 870 o use other header fields provided in the 304 (Not Modified) 871 response to replace all instances of the corresponding header 872 fields in the stored response. 874 4.3.5. Freshening Responses via HEAD 876 A response to the HEAD method is identical to what an equivalent 877 request made with a GET would have been, except it lacks a body. 878 This property of HEAD responses can be used to invalidate or update a 879 cached GET response if the more efficient conditional GET request 880 mechanism is not available (due to no validators being present in the 881 stored response) or if transmission of the representation body is not 882 desired even if it has changed. 884 When a cache makes an inbound HEAD request for a given request target 885 and receives a 200 (OK) response, the cache SHOULD update or 886 invalidate each of its stored GET responses that could have been 887 selected for that request (see Section 4.1). 889 For each of the stored responses that could have been selected, if 890 the stored response and HEAD response have matching values for any 891 received validator fields (ETag and Last-Modified) and, if the HEAD 892 response has a Content-Length header field, the value of Content- 893 Length matches that of the stored response, the cache SHOULD update 894 the stored response as described below; otherwise, the cache SHOULD 895 consider the stored response to be stale. 897 If a cache updates a stored response with the metadata provided in a 898 HEAD response, the cache MUST: 900 o delete any Warning header fields in the stored response with warn- 901 code 1xx (see Section 5.5); 903 o retain any Warning header fields in the stored response with warn- 904 code 2xx; and, 906 o use other header fields provided in the HEAD response to replace 907 all instances of the corresponding header fields in the stored 908 response and append new header fields to the stored response's 909 header section unless otherwise restricted by the Cache-Control 910 header field. 912 4.4. Invalidation 914 Because unsafe request methods (Section 4.2.1 of [SEMNTCS]) such as 915 PUT, POST or DELETE have the potential for changing state on the 916 origin server, intervening caches can use them to keep their contents 917 up to date. 919 A cache MUST invalidate the effective Request URI (Section 5.5 of 920 [MESSGNG]) as well as the URI(s) in the Location and Content-Location 921 response header fields (if present) when a non-error status code is 922 received in response to an unsafe request method. 924 However, a cache MUST NOT invalidate a URI from a Location or 925 Content-Location response header field if the host part of that URI 926 differs from the host part in the effective request URI (Section 5.5 927 of [MESSGNG]). This helps prevent denial-of-service attacks. 929 A cache MUST invalidate the effective request URI (Section 5.5 of 930 [MESSGNG]) when it receives a non-error response to a request with a 931 method whose safety is unknown. 933 Here, a "non-error response" is one with a 2xx (Successful) or 3xx 934 (Redirection) status code. "Invalidate" means that the cache will 935 either remove all stored responses related to the effective request 936 URI or will mark these as "invalid" and in need of a mandatory 937 validation before they can be sent in response to a subsequent 938 request. 940 Note that this does not guarantee that all appropriate responses are 941 invalidated. For example, a state-changing request might invalidate 942 responses in the caches it travels through, but relevant responses 943 still might be stored in other caches that it has not. 945 5. Header Field Definitions 947 This section defines the syntax and semantics of HTTP/1.1 header 948 fields related to caching. 950 5.1. Age 952 The "Age" header field conveys the sender's estimate of the amount of 953 time since the response was generated or successfully validated at 954 the origin server. Age values are calculated as specified in 955 Section 4.2.3. 957 Age = delta-seconds 959 The Age field-value is a non-negative integer, representing time in 960 seconds (see Section 1.2.1). 962 The presence of an Age header field implies that the response was not 963 generated or validated by the origin server for this request. 964 However, lack of an Age header field does not imply the origin was 965 contacted, since the response might have been received from an 966 HTTP/1.0 cache that does not implement Age. 968 5.2. Cache-Control 970 The "Cache-Control" header field is used to specify directives for 971 caches along the request/response chain. Such cache directives are 972 unidirectional in that the presence of a directive in a request does 973 not imply that the same directive is to be given in the response. 975 A cache MUST obey the requirements of the Cache-Control directives 976 defined in this section. See Section 5.2.3 for information about how 977 Cache-Control directives defined elsewhere are handled. 979 Note: Some HTTP/1.0 caches might not implement Cache-Control. 981 A proxy, whether or not it implements a cache, MUST pass cache 982 directives through in forwarded messages, regardless of their 983 significance to that application, since the directives might be 984 applicable to all recipients along the request/response chain. It is 985 not possible to target a directive to a specific cache. 987 Cache directives are identified by a token, to be compared case- 988 insensitively, and have an optional argument, that can use both token 989 and quoted-string syntax. For the directives defined below that 990 define arguments, recipients ought to accept both forms, even if one 991 is documented to be preferred. For any directive not defined by this 992 specification, a recipient MUST accept both forms. 994 Cache-Control = 1#cache-directive 996 cache-directive = token [ "=" ( token / quoted-string ) ] 998 For the cache directives defined below, no argument is defined (nor 999 allowed) unless stated otherwise. 1001 5.2.1. Request Cache-Control Directives 1003 5.2.1.1. max-age 1005 Argument syntax: 1007 delta-seconds (see Section 1.2.1) 1009 The "max-age" request directive indicates that the client is 1010 unwilling to accept a response whose age is greater than the 1011 specified number of seconds. Unless the max-stale request directive 1012 is also present, the client is not willing to accept a stale 1013 response. 1015 This directive uses the token form of the argument syntax: e.g., 1016 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the 1017 quoted-string form. 1019 5.2.1.2. max-stale 1021 Argument syntax: 1023 delta-seconds (see Section 1.2.1) 1025 The "max-stale" request directive indicates that the client is 1026 willing to accept a response that has exceeded its freshness 1027 lifetime. If max-stale is assigned a value, then the client is 1028 willing to accept a response that has exceeded its freshness lifetime 1029 by no more than the specified number of seconds. If no value is 1030 assigned to max-stale, then the client is willing to accept a stale 1031 response of any age. 1033 This directive uses the token form of the argument syntax: e.g., 1034 'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate 1035 the quoted-string form. 1037 5.2.1.3. min-fresh 1039 Argument syntax: 1041 delta-seconds (see Section 1.2.1) 1043 The "min-fresh" request directive indicates that the client is 1044 willing to accept a response whose freshness lifetime is no less than 1045 its current age plus the specified time in seconds. That is, the 1046 client wants a response that will still be fresh for at least the 1047 specified number of seconds. 1049 This directive uses the token form of the argument syntax: e.g., 1050 'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate 1051 the quoted-string form. 1053 5.2.1.4. no-cache 1055 The "no-cache" request directive indicates that a cache MUST NOT use 1056 a stored response to satisfy the request without successful 1057 validation on the origin server. 1059 5.2.1.5. no-store 1061 The "no-store" request directive indicates that a cache MUST NOT 1062 store any part of either this request or any response to it. This 1063 directive applies to both private and shared caches. "MUST NOT 1064 store" in this context means that the cache MUST NOT intentionally 1065 store the information in non-volatile storage, and MUST make a best- 1066 effort attempt to remove the information from volatile storage as 1067 promptly as possible after forwarding it. 1069 This directive is NOT a reliable or sufficient mechanism for ensuring 1070 privacy. In particular, malicious or compromised caches might not 1071 recognize or obey this directive, and communications networks might 1072 be vulnerable to eavesdropping. 1074 Note that if a request containing this directive is satisfied from a 1075 cache, the no-store request directive does not apply to the already 1076 stored response. 1078 5.2.1.6. no-transform 1080 The "no-transform" request directive indicates that an intermediary 1081 (whether or not it implements a cache) MUST NOT transform the 1082 payload, as defined in Section 5.7.2 of [MESSGNG]. 1084 5.2.1.7. only-if-cached 1086 The "only-if-cached" request directive indicates that the client only 1087 wishes to obtain a stored response. If it receives this directive, a 1088 cache SHOULD either respond using a stored response that is 1089 consistent with the other constraints of the request, or respond with 1090 a 504 (Gateway Timeout) status code. If a group of caches is being 1091 operated as a unified system with good internal connectivity, a 1092 member cache MAY forward such a request within that group of caches. 1094 5.2.2. Response Cache-Control Directives 1096 5.2.2.1. must-revalidate 1098 The "must-revalidate" response directive indicates that once it has 1099 become stale, a cache MUST NOT use the response to satisfy subsequent 1100 requests without successful validation on the origin server. 1102 The must-revalidate directive is necessary to support reliable 1103 operation for certain protocol features. In all circumstances a 1104 cache MUST obey the must-revalidate directive; in particular, if a 1105 cache cannot reach the origin server for any reason, it MUST generate 1106 a 504 (Gateway Timeout) response. 1108 The must-revalidate directive ought to be used by servers if and only 1109 if failure to validate a request on the representation could result 1110 in incorrect operation, such as a silently unexecuted financial 1111 transaction. 1113 5.2.2.2. no-cache 1115 Argument syntax: 1117 #field-name 1119 The "no-cache" response directive indicates that the response MUST 1120 NOT be used to satisfy a subsequent request without successful 1121 validation on the origin server. This allows an origin server to 1122 prevent a cache from using it to satisfy a request without contacting 1123 it, even by caches that have been configured to send stale responses. 1125 If the no-cache response directive specifies one or more field-names, 1126 then a cache MAY use the response to satisfy a subsequent request, 1127 subject to any other restrictions on caching. However, any header 1128 fields in the response that have the field-name(s) listed MUST NOT be 1129 sent in the response to a subsequent request without successful 1130 revalidation with the origin server. This allows an origin server to 1131 prevent the re-use of certain header fields in a response, while 1132 still allowing caching of the rest of the response. 1134 The field-names given are not limited to the set of header fields 1135 defined by this specification. Field names are case-insensitive. 1137 This directive uses the quoted-string form of the argument syntax. A 1138 sender SHOULD NOT generate the token form (even if quoting appears 1139 not to be needed for single-entry lists). 1141 Note: Although it has been back-ported to many implementations, some 1142 HTTP/1.0 caches will not recognize or obey this directive. Also, no- 1143 cache response directives with field-names are often handled by 1144 caches as if an unqualified no-cache directive was received; i.e., 1145 the special handling for the qualified form is not widely 1146 implemented. 1148 5.2.2.3. no-store 1150 The "no-store" response directive indicates that a cache MUST NOT 1151 store any part of either the immediate request or response. 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 ensuring 1159 privacy. In particular, malicious or compromised caches might not 1160 recognize or obey this directive, and communications networks might 1161 be vulnerable to eavesdropping. 1163 5.2.2.4. no-transform 1165 The "no-transform" response directive indicates that an intermediary 1166 (regardless of whether it implements a cache) MUST NOT transform the 1167 payload, as defined in Section 5.7.2 of [MESSGNG]. 1169 5.2.2.5. public 1171 The "public" response directive indicates that any cache MAY store 1172 the response, even if the response would normally be non-cacheable or 1173 cacheable only within a private cache. (See Section 3.2 for 1174 additional details related to the use of public in response to a 1175 request containing Authorization, and Section 3 for details of how 1176 public affects responses that would normally not be stored, due to 1177 their status codes not being defined as cacheable by default; see 1178 Section 4.2.2.) 1180 5.2.2.6. private 1182 Argument syntax: 1184 #field-name 1186 The "private" response directive indicates that the response message 1187 is intended for a single user and MUST NOT be stored by a shared 1188 cache. A private cache MAY store the response and reuse it for later 1189 requests, even if the response would normally be non-cacheable. 1191 If the private response directive specifies one or more field-names, 1192 this requirement is limited to the field-values associated with the 1193 listed response header fields. That is, a shared cache MUST NOT 1194 store the specified field-names(s), whereas it MAY store the 1195 remainder of the response message. 1197 The field-names given are not limited to the set of header fields 1198 defined by this specification. Field names are case-insensitive. 1200 This directive uses the quoted-string form of the argument syntax. A 1201 sender SHOULD NOT generate the token form (even if quoting appears 1202 not to be needed for single-entry lists). 1204 Note: This usage of the word "private" only controls where the 1205 response can be stored; it cannot ensure the privacy of the message 1206 content. Also, private response directives with field-names are 1207 often handled by caches as if an unqualified private directive was 1208 received; i.e., the special handling for the qualified form is not 1209 widely implemented. 1211 5.2.2.7. proxy-revalidate 1213 The "proxy-revalidate" response directive has the same meaning as the 1214 must-revalidate response directive, except that it does not apply to 1215 private caches. 1217 5.2.2.8. max-age 1219 Argument syntax: 1221 delta-seconds (see Section 1.2.1) 1223 The "max-age" response directive indicates that the response is to be 1224 considered stale after its age is greater than the specified number 1225 of seconds. 1227 This directive uses the token form of the argument syntax: e.g., 1228 'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the 1229 quoted-string form. 1231 5.2.2.9. s-maxage 1233 Argument syntax: 1235 delta-seconds (see Section 1.2.1) 1237 The "s-maxage" response directive indicates that, in shared caches, 1238 the maximum age specified by this directive overrides the maximum age 1239 specified by either the max-age directive or the Expires header 1240 field. The s-maxage directive also implies the semantics of the 1241 proxy-revalidate response directive. 1243 This directive uses the token form of the argument syntax: e.g., 1244 's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the 1245 quoted-string form. 1247 5.2.3. Cache Control Extensions 1249 The Cache-Control header field can be extended through the use of one 1250 or more cache-extension tokens, each with an optional value. A cache 1251 MUST ignore unrecognized cache directives. 1253 Informational extensions (those that do not require a change in cache 1254 behavior) can be added without changing the semantics of other 1255 directives. 1257 Behavioral extensions are designed to work by acting as modifiers to 1258 the existing base of cache directives. Both the new directive and 1259 the old directive are supplied, such that applications that do not 1260 understand the new directive will default to the behavior specified 1261 by the old directive, and those that understand the new directive 1262 will recognize it as modifying the requirements associated with the 1263 old directive. In this way, extensions to the existing cache-control 1264 directives can be made without breaking deployed caches. 1266 For example, consider a hypothetical new response directive called 1267 "community" that acts as a modifier to the private directive: in 1268 addition to private caches, any cache that is shared only by members 1269 of the named community is allowed to cache the response. An origin 1270 server wishing to allow the UCI community to use an otherwise private 1271 response in their shared cache(s) could do so by including 1273 Cache-Control: private, community="UCI" 1275 A cache that recognizes such a community cache-extension could 1276 broaden its behavior in accordance with that extension. A cache that 1277 does not recognize the community cache-extension would ignore it and 1278 adhere to the private directive. 1280 5.3. Expires 1282 The "Expires" header field gives the date/time after which the 1283 response is considered stale. See Section 4.2 for further discussion 1284 of the freshness model. 1286 The presence of an Expires field does not imply that the original 1287 resource will change or cease to exist at, before, or after that 1288 time. 1290 The Expires value is an HTTP-date timestamp, as defined in 1291 Section 7.1.1.1 of [SEMNTCS]. 1293 Expires = HTTP-date 1295 For example 1297 Expires: Thu, 01 Dec 1994 16:00:00 GMT 1299 A cache recipient MUST interpret invalid date formats, especially the 1300 value "0", as representing a time in the past (i.e., "already 1301 expired"). 1303 If a response includes a Cache-Control field with the max-age 1304 directive (Section 5.2.2.8), a recipient MUST ignore the Expires 1305 field. Likewise, if a response includes the s-maxage directive 1306 (Section 5.2.2.9), a shared cache recipient MUST ignore the Expires 1307 field. In both these cases, the value in Expires is only intended 1308 for recipients that have not yet implemented the Cache-Control field. 1310 An origin server without a clock MUST NOT generate an Expires field 1311 unless its value represents a fixed time in the past (always expired) 1312 or its value has been associated with the resource by a system or 1313 user with a reliable clock. 1315 Historically, HTTP required the Expires field-value to be no more 1316 than a year in the future. While longer freshness lifetimes are no 1317 longer prohibited, extremely large values have been demonstrated to 1318 cause problems (e.g., clock overflows due to use of 32-bit integers 1319 for time values), and many caches will evict a response far sooner 1320 than that. 1322 5.4. Pragma 1324 The "Pragma" header field allows backwards compatibility with 1325 HTTP/1.0 caches, so that clients can specify a "no-cache" request 1326 that they will understand (as Cache-Control was not defined until 1327 HTTP/1.1). When the Cache-Control header field is also present and 1328 understood in a request, Pragma is ignored. 1330 In HTTP/1.0, Pragma was defined as an extensible field for 1331 implementation-specified directives for recipients. This 1332 specification deprecates such extensions to improve interoperability. 1334 Pragma = 1#pragma-directive 1335 pragma-directive = "no-cache" / extension-pragma 1336 extension-pragma = token [ "=" ( token / quoted-string ) ] 1338 When the Cache-Control header field is not present in a request, 1339 caches MUST consider the no-cache request pragma-directive as having 1340 the same effect as if "Cache-Control: no-cache" were present (see 1341 Section 5.2.1). 1343 When sending a no-cache request, a client ought to include both the 1344 pragma and cache-control directives, unless Cache-Control: no-cache 1345 is purposefully omitted to target other Cache-Control response 1346 directives at HTTP/1.1 caches. For example: 1348 GET / HTTP/1.1 1349 Host: www.example.com 1350 Cache-Control: max-age=30 1351 Pragma: no-cache 1353 will constrain HTTP/1.1 caches to serve a response no older than 30 1354 seconds, while precluding implementations that do not understand 1355 Cache-Control from serving a cached response. 1357 Note: Because the meaning of "Pragma: no-cache" in responses is 1358 not specified, it does not provide a reliable replacement for 1359 "Cache-Control: no-cache" in them. 1361 5.5. Warning 1363 The "Warning" header field is used to carry additional information 1364 about the status or transformation of a message that might not be 1365 reflected in the status code. This information is typically used to 1366 warn about possible incorrectness introduced by caching operations or 1367 transformations applied to the payload of the message. 1369 Warnings can be used for other purposes, both cache-related and 1370 otherwise. The use of a warning, rather than an error status code, 1371 distinguishes these responses from true failures. 1373 Warning header fields can in general be applied to any message, 1374 however some warn-codes are specific to caches and can only be 1375 applied to response messages. 1377 Warning = 1#warning-value 1379 warning-value = warn-code SP warn-agent SP warn-text 1380 [ SP warn-date ] 1382 warn-code = 3DIGIT 1383 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1384 ; the name or pseudonym of the server adding 1385 ; the Warning header field, for use in debugging 1386 ; a single "-" is recommended when agent unknown 1387 warn-text = quoted-string 1388 warn-date = DQUOTE HTTP-date DQUOTE 1390 Multiple warnings can be generated in a response (either by the 1391 origin server or by a cache), including multiple warnings with the 1392 same warn-code number that only differ in warn-text. 1394 A user agent that receives one or more Warning header fields SHOULD 1395 inform the user of as many of them as possible, in the order that 1396 they appear in the response. Senders that generate multiple Warning 1397 header fields are encouraged to order them with this user agent 1398 behavior in mind. A sender that generates new Warning header fields 1399 MUST append them after any existing Warning header fields. 1401 Warnings are assigned three digit warn-codes. The first digit 1402 indicates whether the Warning is required to be deleted from a stored 1403 response after validation: 1405 o 1xx warn-codes describe the freshness or validation status of the 1406 response, and so they MUST be deleted by a cache after validation. 1407 They can only be generated by a cache when validating a cached 1408 entry, and MUST NOT be generated in any other situation. 1410 o 2xx warn-codes describe some aspect of the representation that is 1411 not rectified by a validation (for example, a lossy compression of 1412 the representation) and they MUST NOT be deleted by a cache after 1413 validation, unless a full response is sent, in which case they 1414 MUST be. 1416 If a sender generates one or more 1xx warn-codes in a message to be 1417 sent to a recipient known to implement only HTTP/1.0, the sender MUST 1418 include in each corresponding warning-value a warn-date that matches 1419 the Date header field in the message. For example: 1421 HTTP/1.1 200 OK 1422 Date: Sat, 25 Aug 2012 23:34:45 GMT 1423 Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT" 1425 Warnings have accompanying warn-text that describes the error, e.g., 1426 for logging. It is advisory only, and its content does not affect 1427 interpretation of the warn-code. 1429 If a recipient that uses, evaluates, or displays Warning header 1430 fields receives a warn-date that is different from the Date value in 1431 the same message, the recipient MUST exclude the warning-value 1432 containing that warn-date before storing, forwarding, or using the 1433 message. This allows recipients to exclude warning-values that were 1434 improperly retained after a cache validation. If all of the warning- 1435 values are excluded, the recipient MUST exclude the Warning header 1436 field as well. 1438 The following warn-codes are defined by this specification, each with 1439 a recommended warn-text in English, and a description of its meaning. 1440 The procedure for defining additional warn codes is described in 1441 Section 7.2.1. 1443 5.5.1. Warning: 110 - "Response is Stale" 1445 A cache SHOULD generate this whenever the sent response is stale. 1447 5.5.2. Warning: 111 - "Revalidation Failed" 1449 A cache SHOULD generate this when sending a stale response because an 1450 attempt to validate the response failed, due to an inability to reach 1451 the server. 1453 5.5.3. Warning: 112 - "Disconnected Operation" 1455 A cache SHOULD generate this if it is intentionally disconnected from 1456 the rest of the network for a period of time. 1458 5.5.4. Warning: 113 - "Heuristic Expiration" 1460 A cache SHOULD generate this if it heuristically chose a freshness 1461 lifetime greater than 24 hours and the response's age is greater than 1462 24 hours. 1464 5.5.5. Warning: 199 - "Miscellaneous Warning" 1466 The warning text can include arbitrary information to be presented to 1467 a human user or logged. A system receiving this warning MUST NOT 1468 take any automated action, besides presenting the warning to the 1469 user. 1471 5.5.6. Warning: 214 - "Transformation Applied" 1473 This Warning code MUST be added by a proxy if it applies any 1474 transformation to the representation, such as changing the content- 1475 coding, media-type, or modifying the representation data, unless this 1476 Warning code already appears in the response. 1478 5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" 1480 The warning text can include arbitrary information to be presented to 1481 a human user or logged. A system receiving this warning MUST NOT 1482 take any automated action. 1484 6. History Lists 1486 User agents often have history mechanisms, such as "Back" buttons and 1487 history lists, that can be used to redisplay a representation 1488 retrieved earlier in a session. 1490 The freshness model (Section 4.2) does not necessarily apply to 1491 history mechanisms. That is, a history mechanism can display a 1492 previous representation even if it has expired. 1494 This does not prohibit the history mechanism from telling the user 1495 that a view might be stale or from honoring cache directives (e.g., 1496 Cache-Control: no-store). 1498 7. IANA Considerations 1500 7.1. Cache Directive Registry 1502 The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry" 1503 defines the namespace for the cache directives. It has been created 1504 and is now maintained at . 1507 7.1.1. Procedure 1509 A registration MUST include the following fields: 1511 o Cache Directive Name 1513 o Pointer to specification text 1515 Values to be added to this namespace require IETF Review (see 1516 [RFC5226], Section 4.1). 1518 7.1.2. Considerations for New Cache Control Directives 1520 New extension directives ought to consider defining: 1522 o What it means for a directive to be specified multiple times, 1524 o When the directive does not take an argument, what it means when 1525 an argument is present, 1527 o When the directive requires an argument, what it means when it is 1528 missing, 1530 o Whether the directive is specific to requests, responses, or able 1531 to be used in either. 1533 See also Section 5.2.3. 1535 7.1.3. Registrations 1537 The registry has been populated with the registrations below: 1539 +------------------------+-----------------------------------+ 1540 | Cache Directive | Reference | 1541 +------------------------+-----------------------------------+ 1542 | max-age | Section 5.2.1.1, Section 5.2.2.8 | 1543 | max-stale | Section 5.2.1.2 | 1544 | min-fresh | Section 5.2.1.3 | 1545 | must-revalidate | Section 5.2.2.1 | 1546 | no-cache | Section 5.2.1.4, Section 5.2.2.2 | 1547 | no-store | Section 5.2.1.5, Section 5.2.2.3 | 1548 | no-transform | Section 5.2.1.6, Section 5.2.2.4 | 1549 | only-if-cached | Section 5.2.1.7 | 1550 | private | Section 5.2.2.6 | 1551 | proxy-revalidate | Section 5.2.2.7 | 1552 | public | Section 5.2.2.5 | 1553 | s-maxage | Section 5.2.2.9 | 1554 | stale-if-error | [RFC5861], Section 4 | 1555 | stale-while-revalidate | [RFC5861], Section 3 | 1556 +------------------------+-----------------------------------+ 1558 7.2. Warn Code Registry 1560 The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines 1561 the namespace for warn codes. It has been created and is now 1562 maintained at . 1564 7.2.1. Procedure 1566 A registration MUST include the following fields: 1568 o Warn Code (3 digits) 1570 o Short Description 1572 o Pointer to specification text 1574 Values to be added to this namespace require IETF Review (see 1575 [RFC5226], Section 4.1). 1577 7.2.2. Registrations 1579 The registry has been populated with the registrations below: 1581 +-----------+----------------------------------+----------------+ 1582 | Warn Code | Short Description | Reference | 1583 +-----------+----------------------------------+----------------+ 1584 | 110 | Response is Stale | Section 5.5.1 | 1585 | 111 | Revalidation Failed | Section 5.5.2 | 1586 | 112 | Disconnected Operation | Section 5.5.3 | 1587 | 113 | Heuristic Expiration | Section 5.5.4 | 1588 | 199 | Miscellaneous Warning | Section 5.5.5 | 1589 | 214 | Transformation Applied | Section 5.5.6 | 1590 | 299 | Miscellaneous Persistent Warning | Section 5.5.7 | 1591 +-----------+----------------------------------+----------------+ 1593 7.3. Header Field Registration 1595 HTTP header fields are registered within the "Message Headers" 1596 registry maintained at . 1599 This document defines the following HTTP header fields, so the 1600 "Permanent Message Header Field Names" registry has been updated 1601 accordingly (see [BCP90]). 1603 +-------------------+----------+----------+--------------+ 1604 | Header Field Name | Protocol | Status | Reference | 1605 +-------------------+----------+----------+--------------+ 1606 | Age | http | standard | Section 5.1 | 1607 | Cache-Control | http | standard | Section 5.2 | 1608 | Expires | http | standard | Section 5.3 | 1609 | Pragma | http | standard | Section 5.4 | 1610 | Warning | http | standard | Section 5.5 | 1611 +-------------------+----------+----------+--------------+ 1612 The change controller is: "IETF (iesg@ietf.org) - Internet 1613 Engineering Task Force". 1615 8. Security Considerations 1617 This section is meant to inform developers, information providers, 1618 and users of known security concerns specific to HTTP caching. More 1619 general security considerations are addressed in HTTP messaging 1620 [MESSGNG] and semantics [SEMNTCS]. 1622 Caches expose additional potential vulnerabilities, since the 1623 contents of the cache represent an attractive target for malicious 1624 exploitation. Because cache contents persist after an HTTP request 1625 is complete, an attack on the cache can reveal information long after 1626 a user believes that the information has been removed from the 1627 network. Therefore, cache contents need to be protected as sensitive 1628 information. 1630 In particular, various attacks might be amplified by being stored in 1631 a shared cache; such "cache poisoning" attacks use the cache to 1632 distribute a malicious payload to many clients, and are especially 1633 effective when an attacker can use implementation flaws, elevated 1634 privileges, or other techniques to insert such a response into a 1635 cache. One common attack vector for cache poisoning is to exploit 1636 differences in message parsing on proxies and in user agents; see 1637 Section 3.3.3 of [MESSGNG] for the relevant requirements. 1639 Likewise, implementation flaws (as well as misunderstanding of cache 1640 operation) might lead to caching of sensitive information (e.g., 1641 authentication credentials) that is thought to be private, exposing 1642 it to unauthorized parties. 1644 Furthermore, the very use of a cache can bring about privacy 1645 concerns. For example, if two users share a cache, and the first one 1646 browses to a site, the second may be able to detect that the other 1647 has been to that site, because the resources from it load more 1648 quickly, thanks to the cache. 1650 Note that the Set-Cookie response header field [RFC6265] does not 1651 inhibit caching; a cacheable response with a Set-Cookie header field 1652 can be (and often is) used to satisfy subsequent requests to caches. 1653 Servers who wish to control caching of these responses are encouraged 1654 to emit appropriate Cache-Control response header fields. 1656 9. References 1658 9.1. Normative References 1660 [AUTHFRM] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1661 Protocol (HTTP): Authentication", draft-fielding-httpbis- 1662 http-auth-00 (work in progress), March 2018. 1664 [CONDTNL] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1665 Protocol (HTTP): Conditional Requests", draft-fielding- 1666 httpbis-http-conditional-00 (work in progress), March 1667 2018. 1669 [MESSGNG] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1670 Protocol (HTTP/1.1): Message Syntax and Routing", draft- 1671 fielding-httpbis-http-messaging-00 (work in progress), 1672 March 2018. 1674 [RANGERQ] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 1675 "Hypertext Transfer Protocol (HTTP): Range Requests", 1676 draft-fielding-httpbis-http-range-00 (work in progress), 1677 March 2018. 1679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1680 Requirement Levels", BCP 14, RFC 2119, 1681 DOI 10.17487/RFC2119, March 1997, 1682 . 1684 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1685 Specifications: ABNF", STD 68, RFC 5234, 1686 DOI 10.17487/RFC5234, January 2008, 1687 . 1689 [SEMNTCS] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1690 Protocol (HTTP): Semantics and Content", draft-fielding- 1691 httpbis-http-semantics-00 (work in progress), March 2018. 1693 9.2. Informative References 1695 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 1696 Procedures for Message Header Fields", BCP 90, RFC 3864, 1697 September 2004, . 1699 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1700 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1701 Transfer Protocol -- HTTP/1.1", RFC 2616, 1702 DOI 10.17487/RFC2616, June 1999, 1703 . 1705 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1706 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1707 DOI 10.17487/RFC5226, May 2008, 1708 . 1710 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 1711 Content", RFC 5861, DOI 10.17487/RFC5861, April 2010, 1712 . 1714 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 1715 "Network Time Protocol Version 4: Protocol and Algorithms 1716 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 1717 . 1719 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 1720 DOI 10.17487/RFC6265, April 2011, 1721 . 1723 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1724 Ed., "Hypertext Transfer Protocol (HTTP): Caching", 1725 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1726 . 1728 Appendix A. Changes from RFC 7234 1730 None yet. 1732 Appendix B. Imported ABNF 1734 The following core rules are included by reference, as defined in 1735 Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), 1736 CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double 1737 quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 1738 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 1739 character). 1741 The rules below are defined in [MESSGNG]: 1743 OWS = 1744 field-name = 1745 quoted-string = 1746 token = 1748 port = 1749 pseudonym = 1750 uri-host = 1752 The rules below are defined in other parts: 1754 HTTP-date = 1756 Appendix C. Collected ABNF 1758 In the collected ABNF below, list rules are expanded as per 1759 Section 1.2 of [MESSGNG]. 1761 Age = delta-seconds 1763 Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS 1764 cache-directive ] ) 1766 Expires = HTTP-date 1768 HTTP-date = 1770 OWS = 1772 Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS 1773 pragma-directive ] ) 1775 Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] 1776 ) 1778 cache-directive = token [ "=" ( token / quoted-string ) ] 1780 delta-seconds = 1*DIGIT 1782 extension-pragma = token [ "=" ( token / quoted-string ) ] 1784 field-name = 1786 port = 1787 pragma-directive = "no-cache" / extension-pragma 1788 pseudonym = 1790 quoted-string = 1792 token = 1794 uri-host = 1796 warn-agent = ( uri-host [ ":" port ] ) / pseudonym 1797 warn-code = 3DIGIT 1798 warn-date = DQUOTE HTTP-date DQUOTE 1799 warn-text = quoted-string 1800 warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date 1801 ] 1803 Appendix D. Change Log 1805 This section is to be removed before publishing as an RFC. 1807 D.1. Since RFC 7234 1809 The changes in this draft are purely editorial: 1811 o Change boilerplate and abstract to indicate the "draft" status, 1812 and update references to ancestor specifications. 1814 o Remove version "1.1" from document title, indicating that this 1815 specification applies to all HTTP versions. 1817 o Adjust historical notes. 1819 o Update links to sibling specifications. 1821 o Replace sections listing changes from RFC 2616 by new empty 1822 sections referring to RFC 723x. 1824 o Remove acknowledgements specific to RFC 723x. 1826 o Move "Acknowledgements" to the very end and make them unnumbered. 1828 Index 1830 1 1831 110 (warn-code) 31 1832 111 (warn-code) 31 1833 112 (warn-code) 31 1834 113 (warn-code) 31 1835 199 (warn-code) 31 1837 2 1838 214 (warn-code) 32 1839 299 (warn-code) 32 1841 A 1842 Age header field 21 1843 age 11 1845 C 1846 Cache-Control header field 21 1847 cache 4 1848 cache entry 5 1849 cache key 5-6 1851 D 1852 Disconnected Operation (warn-text) 31 1854 E 1855 Expires header field 27 1856 explicit expiration time 11 1858 F 1859 fresh 11 1860 freshness lifetime 11 1862 G 1863 Grammar 1864 Age 21 1865 Cache-Control 21 1866 cache-directive 21 1867 delta-seconds 5 1868 Expires 28 1869 extension-pragma 29 1870 Pragma 29 1871 pragma-directive 29 1872 warn-agent 30 1873 warn-code 30 1874 warn-date 30 1875 warn-text 30 1876 Warning 30 1877 warning-value 30 1879 H 1880 Heuristic Expiration (warn-text) 31 1881 heuristic expiration time 11 1883 M 1884 Miscellaneous Persistent Warning (warn-text) 32 1885 Miscellaneous Warning (warn-text) 31 1886 max-age (cache directive) 22, 26 1887 max-stale (cache directive) 22 1888 min-fresh (cache directive) 22 1889 must-revalidate (cache directive) 24 1891 N 1892 no-cache (cache directive) 23-24 1893 no-store (cache directive) 23, 25 1894 no-transform (cache directive) 23, 25 1896 O 1897 only-if-cached (cache directive) 23 1899 P 1900 Pragma header field 28 1901 private (cache directive) 25 1902 private cache 4 1903 proxy-revalidate (cache directive) 26 1904 public (cache directive) 25 1906 R 1907 Response is Stale (warn-text) 31 1908 Revalidation Failed (warn-text) 31 1910 S 1911 s-maxage (cache directive) 26 1912 shared cache 4 1913 stale 11 1914 strong validator 18 1916 T 1917 Transformation Applied (warn-text) 32 1919 V 1920 validator 16 1922 W 1923 Warning header field 29 1925 Acknowledgments 1927 See Appendix "Acknowledgments" of [MESSGNG]. 1929 Authors' Addresses 1931 Roy T. Fielding (editor) 1932 Adobe Systems Incorporated 1933 345 Park Ave 1934 San Jose, CA 95110 1935 USA 1937 EMail: fielding@gbiv.com 1938 URI: http://roy.gbiv.com/ 1940 Mark Nottingham (editor) 1941 Fastly 1943 EMail: mnot@mnot.net 1944 URI: http://www.mnot.net/ 1945 Julian F. Reschke (editor) 1946 greenbytes GmbH 1947 Hafenweg 16 1948 Muenster, NW 48155 1949 Germany 1951 EMail: julian.reschke@greenbytes.de 1952 URI: http://greenbytes.de/tech/webdav/