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