1 | |
---|
2 | |
---|
3 | |
---|
4 | HTTPbis Working Group R. Fielding, Ed. |
---|
5 | Internet-Draft Day Software |
---|
6 | Obsoletes: 2616 (if approved) J. Gettys |
---|
7 | Intended status: Standards Track Alcatel-Lucent |
---|
8 | Expires: January 13, 2011 J. Mogul |
---|
9 | HP |
---|
10 | H. Frystyk |
---|
11 | Microsoft |
---|
12 | L. Masinter |
---|
13 | Adobe Systems |
---|
14 | P. Leach |
---|
15 | Microsoft |
---|
16 | T. Berners-Lee |
---|
17 | W3C/MIT |
---|
18 | Y. Lafon, Ed. |
---|
19 | W3C |
---|
20 | M. Nottingham, Ed. |
---|
21 | |
---|
22 | J. Reschke, Ed. |
---|
23 | greenbytes |
---|
24 | July 12, 2010 |
---|
25 | |
---|
26 | |
---|
27 | HTTP/1.1, part 6: Caching |
---|
28 | draft-ietf-httpbis-p6-cache-10 |
---|
29 | |
---|
30 | Abstract |
---|
31 | |
---|
32 | The Hypertext Transfer Protocol (HTTP) is an application-level |
---|
33 | protocol for distributed, collaborative, hypermedia information |
---|
34 | systems. This document is Part 6 of the seven-part specification |
---|
35 | that defines the protocol referred to as "HTTP/1.1" and, taken |
---|
36 | together, obsoletes RFC 2616. Part 6 defines requirements on HTTP |
---|
37 | caches and the associated header fields that control cache behavior |
---|
38 | or indicate cacheable response messages. |
---|
39 | |
---|
40 | Editorial Note (To be removed by RFC Editor) |
---|
41 | |
---|
42 | Discussion of this draft should take place on the HTTPBIS working |
---|
43 | group mailing list (ietf-http-wg@w3.org). The current issues list is |
---|
44 | at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related |
---|
45 | documents (including fancy diffs) can be found at |
---|
46 | <http://tools.ietf.org/wg/httpbis/>. |
---|
47 | |
---|
48 | The changes in this draft are summarized in Appendix C.11. |
---|
49 | |
---|
50 | Status of This Memo |
---|
51 | |
---|
52 | |
---|
53 | |
---|
54 | |
---|
55 | Fielding, et al. Expires January 13, 2011 [Page 1] |
---|
56 | |
---|
57 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
58 | |
---|
59 | |
---|
60 | This Internet-Draft is submitted in full conformance with the |
---|
61 | provisions of BCP 78 and BCP 79. |
---|
62 | |
---|
63 | Internet-Drafts are working documents of the Internet Engineering |
---|
64 | Task Force (IETF). Note that other groups may also distribute |
---|
65 | working documents as Internet-Drafts. The list of current Internet- |
---|
66 | Drafts is at http://datatracker.ietf.org/drafts/current/. |
---|
67 | |
---|
68 | Internet-Drafts are draft documents valid for a maximum of six months |
---|
69 | and may be updated, replaced, or obsoleted by other documents at any |
---|
70 | time. It is inappropriate to use Internet-Drafts as reference |
---|
71 | material or to cite them other than as "work in progress." |
---|
72 | |
---|
73 | This Internet-Draft will expire on January 13, 2011. |
---|
74 | |
---|
75 | Copyright Notice |
---|
76 | |
---|
77 | Copyright (c) 2010 IETF Trust and the persons identified as the |
---|
78 | document authors. All rights reserved. |
---|
79 | |
---|
80 | This document is subject to BCP 78 and the IETF Trust's Legal |
---|
81 | Provisions Relating to IETF Documents |
---|
82 | (http://trustee.ietf.org/license-info) in effect on the date of |
---|
83 | publication of this document. Please review these documents |
---|
84 | carefully, as they describe your rights and restrictions with respect |
---|
85 | to this document. Code Components extracted from this document must |
---|
86 | include Simplified BSD License text as described in Section 4.e of |
---|
87 | the Trust Legal Provisions and are provided without warranty as |
---|
88 | described in the Simplified BSD License. |
---|
89 | |
---|
90 | This document may contain material from IETF Documents or IETF |
---|
91 | Contributions published or made publicly available before November |
---|
92 | 10, 2008. The person(s) controlling the copyright in some of this |
---|
93 | material may not have granted the IETF Trust the right to allow |
---|
94 | modifications of such material outside the IETF Standards Process. |
---|
95 | Without obtaining an adequate license from the person(s) controlling |
---|
96 | the copyright in such materials, this document may not be modified |
---|
97 | outside the IETF Standards Process, and derivative works of it may |
---|
98 | not be created outside the IETF Standards Process, except to format |
---|
99 | it for publication as an RFC or to translate it into languages other |
---|
100 | than English. |
---|
101 | |
---|
102 | Table of Contents |
---|
103 | |
---|
104 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
105 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
106 | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 |
---|
107 | 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 |
---|
108 | |
---|
109 | |
---|
110 | |
---|
111 | Fielding, et al. Expires January 13, 2011 [Page 2] |
---|
112 | |
---|
113 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
114 | |
---|
115 | |
---|
116 | 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 |
---|
117 | 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 |
---|
118 | 1.4.2. ABNF Rules defined in other Parts of the |
---|
119 | Specification . . . . . . . . . . . . . . . . . . . . 7 |
---|
120 | 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7 |
---|
121 | 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7 |
---|
122 | 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 |
---|
123 | 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9 |
---|
124 | 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 |
---|
125 | 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 |
---|
126 | 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12 |
---|
127 | 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 |
---|
128 | 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14 |
---|
129 | 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 |
---|
130 | 2.6. Shared Caching of Authenticated Responses . . . . . . . . 15 |
---|
131 | 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16 |
---|
132 | 2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 16 |
---|
133 | 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 |
---|
134 | 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 |
---|
135 | 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18 |
---|
136 | 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19 |
---|
137 | 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 |
---|
138 | 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23 |
---|
139 | 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24 |
---|
140 | 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
---|
141 | 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 |
---|
142 | 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26 |
---|
143 | 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 |
---|
144 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 |
---|
145 | 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29 |
---|
146 | 5.2. Message Header Registration . . . . . . . . . . . . . . . 30 |
---|
147 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 |
---|
148 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 |
---|
149 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 |
---|
150 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 30 |
---|
151 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 31 |
---|
152 | Appendix A. Compatibility with Previous Versions . . . . . . . . 32 |
---|
153 | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 32 |
---|
154 | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 32 |
---|
155 | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 32 |
---|
156 | Appendix C. Change Log (to be removed by RFC Editor before |
---|
157 | publication) . . . . . . . . . . . . . . . . . . . . 34 |
---|
158 | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 34 |
---|
159 | C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 34 |
---|
160 | C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 35 |
---|
161 | C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 35 |
---|
162 | C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35 |
---|
163 | C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 |
---|
164 | |
---|
165 | |
---|
166 | |
---|
167 | Fielding, et al. Expires January 13, 2011 [Page 3] |
---|
168 | |
---|
169 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
170 | |
---|
171 | |
---|
172 | C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36 |
---|
173 | C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36 |
---|
174 | C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36 |
---|
175 | C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37 |
---|
176 | C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37 |
---|
177 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 |
---|
178 | |
---|
179 | |
---|
180 | |
---|
181 | |
---|
182 | |
---|
183 | |
---|
184 | |
---|
185 | |
---|
186 | |
---|
187 | |
---|
188 | |
---|
189 | |
---|
190 | |
---|
191 | |
---|
192 | |
---|
193 | |
---|
194 | |
---|
195 | |
---|
196 | |
---|
197 | |
---|
198 | |
---|
199 | |
---|
200 | |
---|
201 | |
---|
202 | |
---|
203 | |
---|
204 | |
---|
205 | |
---|
206 | |
---|
207 | |
---|
208 | |
---|
209 | |
---|
210 | |
---|
211 | |
---|
212 | |
---|
213 | |
---|
214 | |
---|
215 | |
---|
216 | |
---|
217 | |
---|
218 | |
---|
219 | |
---|
220 | |
---|
221 | |
---|
222 | |
---|
223 | Fielding, et al. Expires January 13, 2011 [Page 4] |
---|
224 | |
---|
225 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
226 | |
---|
227 | |
---|
228 | 1. Introduction |
---|
229 | |
---|
230 | HTTP is typically used for distributed information systems, where |
---|
231 | performance can be improved by the use of response caches. This |
---|
232 | document defines aspects of HTTP/1.1 related to caching and reusing |
---|
233 | response messages. |
---|
234 | |
---|
235 | 1.1. Purpose |
---|
236 | |
---|
237 | An HTTP cache is a local store of response messages and the subsystem |
---|
238 | that controls its message storage, retrieval, and deletion. A cache |
---|
239 | stores cacheable responses in order to reduce the response time and |
---|
240 | network bandwidth consumption on future, equivalent requests. Any |
---|
241 | client or server may include a cache, though a cache cannot be used |
---|
242 | by a server that is acting as a tunnel. |
---|
243 | |
---|
244 | Caching would be useless if it did not significantly improve |
---|
245 | performance. The goal of caching in HTTP/1.1 is to reuse a prior |
---|
246 | response message to satisfy a current request. In some cases, a |
---|
247 | stored response can be reused without the need for a network request, |
---|
248 | reducing latency and network round-trips; a "freshness" mechanism is |
---|
249 | used for this purpose (see Section 2.3). Even when a new request is |
---|
250 | required, it is often possible to reuse all or parts of the payload |
---|
251 | of a prior response to satisfy the request, thereby reducing network |
---|
252 | bandwidth usage; a "validation" mechanism is used for this purpose |
---|
253 | (see Section 2.4). |
---|
254 | |
---|
255 | 1.2. Terminology |
---|
256 | |
---|
257 | This specification uses a number of terms to refer to the roles |
---|
258 | played by participants in, and objects of, HTTP caching. |
---|
259 | |
---|
260 | cacheable |
---|
261 | |
---|
262 | A response is cacheable if a cache is allowed to store a copy of |
---|
263 | the response message for use in answering subsequent requests. |
---|
264 | Even when a response is cacheable, there may be additional |
---|
265 | constraints on whether a cache can use the cached copy to satisfy |
---|
266 | a particular request. |
---|
267 | |
---|
268 | explicit expiration time |
---|
269 | |
---|
270 | The time at which the origin server intends that an entity should |
---|
271 | no longer be returned by a cache without further validation. |
---|
272 | |
---|
273 | |
---|
274 | |
---|
275 | |
---|
276 | |
---|
277 | |
---|
278 | |
---|
279 | Fielding, et al. Expires January 13, 2011 [Page 5] |
---|
280 | |
---|
281 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
282 | |
---|
283 | |
---|
284 | heuristic expiration time |
---|
285 | |
---|
286 | An expiration time assigned by a cache when no explicit expiration |
---|
287 | time is available. |
---|
288 | |
---|
289 | age |
---|
290 | |
---|
291 | The age of a response is the time since it was sent by, or |
---|
292 | successfully validated with, the origin server. |
---|
293 | |
---|
294 | first-hand |
---|
295 | |
---|
296 | A response is first-hand if the freshness model is not in use; |
---|
297 | i.e., its age is 0. |
---|
298 | |
---|
299 | freshness lifetime |
---|
300 | |
---|
301 | The length of time between the generation of a response and its |
---|
302 | expiration time. |
---|
303 | |
---|
304 | fresh |
---|
305 | |
---|
306 | A response is fresh if its age has not yet exceeded its freshness |
---|
307 | lifetime. |
---|
308 | |
---|
309 | stale |
---|
310 | |
---|
311 | A response is stale if its age has passed its freshness lifetime |
---|
312 | (either explicit or heuristic). |
---|
313 | |
---|
314 | validator |
---|
315 | |
---|
316 | A protocol element (e.g., an entity tag or a Last-Modified time) |
---|
317 | that is used to find out whether a stored response is an |
---|
318 | equivalent copy of an entity. |
---|
319 | |
---|
320 | shared cache |
---|
321 | |
---|
322 | A cache that is accessible to more than one user. A non-shared |
---|
323 | cache is dedicated to a single user. |
---|
324 | |
---|
325 | 1.3. Requirements |
---|
326 | |
---|
327 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
---|
328 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
---|
329 | document are to be interpreted as described in [RFC2119]. |
---|
330 | |
---|
331 | An implementation is not compliant if it fails to satisfy one or more |
---|
332 | |
---|
333 | |
---|
334 | |
---|
335 | Fielding, et al. Expires January 13, 2011 [Page 6] |
---|
336 | |
---|
337 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
338 | |
---|
339 | |
---|
340 | of the "MUST" or "REQUIRED" level requirements for the protocols it |
---|
341 | implements. An implementation that satisfies all the "MUST" or |
---|
342 | "REQUIRED" level and all the "SHOULD" level requirements for its |
---|
343 | protocols is said to be "unconditionally compliant"; one that |
---|
344 | satisfies all the "MUST" level requirements but not all the "SHOULD" |
---|
345 | level requirements for its protocols is said to be "conditionally |
---|
346 | compliant". |
---|
347 | |
---|
348 | 1.4. Syntax Notation |
---|
349 | |
---|
350 | This specification uses the ABNF syntax defined in Section 1.2 of |
---|
351 | [Part1] (which extends the syntax defined in [RFC5234] with a list |
---|
352 | rule). Appendix B shows the collected ABNF, with the list rule |
---|
353 | expanded. |
---|
354 | |
---|
355 | The following core rules are included by reference, as defined in |
---|
356 | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF |
---|
357 | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), |
---|
358 | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit |
---|
359 | sequence of data), SP (space), VCHAR (any visible USASCII character), |
---|
360 | and WSP (whitespace). |
---|
361 | |
---|
362 | 1.4.1. Core Rules |
---|
363 | |
---|
364 | The core rules below are defined in Section 1.2.2 of [Part1]: |
---|
365 | |
---|
366 | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
---|
367 | token = <token, defined in [Part1], Section 1.2.2> |
---|
368 | OWS = <OWS, defined in [Part1], Section 1.2.2> |
---|
369 | |
---|
370 | 1.4.2. ABNF Rules defined in other Parts of the Specification |
---|
371 | |
---|
372 | The ABNF rules below are defined in other parts: |
---|
373 | |
---|
374 | field-name = <field-name, defined in [Part1], Section 3.2> |
---|
375 | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
---|
376 | port = <port, defined in [Part1], Section 2.6> |
---|
377 | pseudonym = <pseudonym, defined in [Part1], Section 9.9> |
---|
378 | uri-host = <uri-host, defined in [Part1], Section 2.6> |
---|
379 | |
---|
380 | 2. Cache Operation |
---|
381 | |
---|
382 | 2.1. Response Cacheability |
---|
383 | |
---|
384 | A cache MUST NOT store a response to any request, unless: |
---|
385 | |
---|
386 | o The request method is understood by the cache and defined as being |
---|
387 | cacheable, and |
---|
388 | |
---|
389 | |
---|
390 | |
---|
391 | Fielding, et al. Expires January 13, 2011 [Page 7] |
---|
392 | |
---|
393 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
394 | |
---|
395 | |
---|
396 | o the response status code is understood by the cache, and |
---|
397 | |
---|
398 | o the "no-store" cache directive (see Section 3.2) does not appear |
---|
399 | in request or response headers, and |
---|
400 | |
---|
401 | o the "private" cache response directive (see Section 3.2.2 does not |
---|
402 | appear in the response, if the cache is shared, and |
---|
403 | |
---|
404 | o the "Authorization" header (see Section 3.1 of [Part7]) does not |
---|
405 | appear in the request, if the cache is shared, unless the response |
---|
406 | explicitly allows it (see Section 2.6), and |
---|
407 | |
---|
408 | o the response either: |
---|
409 | |
---|
410 | * contains an Expires header (see Section 3.3), or |
---|
411 | |
---|
412 | * contains a max-age response cache directive (see |
---|
413 | Section 3.2.2), or |
---|
414 | |
---|
415 | * contains a s-maxage response cache directive and the cache is |
---|
416 | shared, or |
---|
417 | |
---|
418 | * contains a Cache Control Extension (see Section 3.2.3) that |
---|
419 | allows it to be cached, or |
---|
420 | |
---|
421 | * has a status code that can be served with heuristic freshness |
---|
422 | (see Section 2.3.1.1). |
---|
423 | |
---|
424 | In this context, a cache has "understood" a request method or a |
---|
425 | response status code if it recognises it and implements any cache- |
---|
426 | specific behaviour. In particular, 206 Partial Content responses |
---|
427 | cannot be cached by an implementation that does not handle partial |
---|
428 | content (see Section 2.1.1). |
---|
429 | |
---|
430 | Note that in normal operation, most caches will not store a response |
---|
431 | that has neither a cache validator nor an explicit expiration time, |
---|
432 | as such responses are not usually useful to store. However, caches |
---|
433 | are not prohibited from storing such responses. |
---|
434 | |
---|
435 | 2.1.1. Storing Partial and Incomplete Responses |
---|
436 | |
---|
437 | A cache that receives an incomplete response (for example, with fewer |
---|
438 | bytes of data than specified in a Content-Length header) can store |
---|
439 | the response, but MUST treat it as a partial response [Part5]. |
---|
440 | Partial responses can be combined as described in Section 4 of |
---|
441 | [Part5]; the result might be a full response or might still be |
---|
442 | partial. A cache MUST NOT return a partial response to a client |
---|
443 | without explicitly marking it as such using the 206 (Partial Content) |
---|
444 | |
---|
445 | |
---|
446 | |
---|
447 | Fielding, et al. Expires January 13, 2011 [Page 8] |
---|
448 | |
---|
449 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
450 | |
---|
451 | |
---|
452 | status code. |
---|
453 | |
---|
454 | A cache that does not support the Range and Content-Range headers |
---|
455 | MUST NOT store incomplete or partial responses. |
---|
456 | |
---|
457 | 2.2. Constructing Responses from Caches |
---|
458 | |
---|
459 | For a presented request, a cache MUST NOT return a stored response, |
---|
460 | unless: |
---|
461 | |
---|
462 | o The presented Effective Request URI (Section 4.3 of [Part1]) and |
---|
463 | that of the stored response match, and |
---|
464 | |
---|
465 | o the request method associated with the stored response allows it |
---|
466 | to be used for the presented request, and |
---|
467 | |
---|
468 | o selecting request-headers nominated by the stored response (if |
---|
469 | any) match those presented (see Section 2.7), and |
---|
470 | |
---|
471 | o the presented request and stored response are free from directives |
---|
472 | that would prevent its use (see Section 3.2 and Section 3.4), and |
---|
473 | |
---|
474 | o the stored response is either: |
---|
475 | |
---|
476 | * fresh (see Section 2.3), or |
---|
477 | |
---|
478 | * allowed to be served stale (see Section 2.3.3), or |
---|
479 | |
---|
480 | * successfully validated (see Section 2.4). |
---|
481 | |
---|
482 | [[TODO-method-cacheability: define method cacheability for GET, HEAD |
---|
483 | and POST in p2-semantics.]] |
---|
484 | |
---|
485 | When a stored response is used to satisfy a request, caches MUST |
---|
486 | include a single Age header field (Section 3.1) in the response with |
---|
487 | a value equal to the stored response's current_age; see |
---|
488 | Section 2.3.2. [[DISCUSS-includes-validated: this currently includes |
---|
489 | successfully validated responses.]] |
---|
490 | |
---|
491 | Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST |
---|
492 | be written through the cache to the origin server; i.e., a cache must |
---|
493 | not reply to such a request before having forwarded the request and |
---|
494 | having received a corresponding response. |
---|
495 | |
---|
496 | Also, note that unsafe requests might invalidate already stored |
---|
497 | responses; see Section 2.5. |
---|
498 | |
---|
499 | Caches MUST use the most recent response (as determined by the Date |
---|
500 | |
---|
501 | |
---|
502 | |
---|
503 | Fielding, et al. Expires January 13, 2011 [Page 9] |
---|
504 | |
---|
505 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
506 | |
---|
507 | |
---|
508 | header) when more than one suitable response is stored. They can |
---|
509 | also forward a request with "Cache-Control: max-age=0" or "Cache- |
---|
510 | Control: no-cache" to disambiguate which response to use. |
---|
511 | |
---|
512 | 2.3. Freshness Model |
---|
513 | |
---|
514 | When a response is "fresh" in the cache, it can be used to satisfy |
---|
515 | subsequent requests without contacting the origin server, thereby |
---|
516 | improving efficiency. |
---|
517 | |
---|
518 | The primary mechanism for determining freshness is for an origin |
---|
519 | server to provide an explicit expiration time in the future, using |
---|
520 | either the Expires header (Section 3.3) or the max-age response cache |
---|
521 | directive (Section 3.2.2). Generally, origin servers will assign |
---|
522 | future explicit expiration times to responses in the belief that the |
---|
523 | entity is not likely to change in a semantically significant way |
---|
524 | before the expiration time is reached. |
---|
525 | |
---|
526 | If an origin server wishes to force a cache to validate every |
---|
527 | request, it can assign an explicit expiration time in the past. This |
---|
528 | means that the response is always stale, so that caches should |
---|
529 | validate it before using it for subsequent requests. [[TODO- |
---|
530 | response-stale: This wording may cause confusion, because the |
---|
531 | response may still be served stale.]] |
---|
532 | |
---|
533 | Since origin servers do not always provide explicit expiration times, |
---|
534 | HTTP caches may also assign heuristic expiration times when they are |
---|
535 | not specified, employing algorithms that use other header values |
---|
536 | (such as the Last-Modified time) to estimate a plausible expiration |
---|
537 | time. The HTTP/1.1 specification does not provide specific |
---|
538 | algorithms, but does impose worst-case constraints on their results. |
---|
539 | |
---|
540 | The calculation to determine if a response is fresh is: |
---|
541 | |
---|
542 | response_is_fresh = (freshness_lifetime > current_age) |
---|
543 | |
---|
544 | The freshness_lifetime is defined in Section 2.3.1; the current_age |
---|
545 | is defined in Section 2.3.2. |
---|
546 | |
---|
547 | Additionally, clients may need to influence freshness calculation. |
---|
548 | They can do this using several request cache directives, with the |
---|
549 | effect of either increasing or loosening constraints on freshness. |
---|
550 | See Section 3.2.1. |
---|
551 | |
---|
552 | [[ISSUE-no-req-for-directives: there are not requirements directly |
---|
553 | applying to cache-request-directives and freshness.]] |
---|
554 | |
---|
555 | Note that freshness applies only to cache operation; it cannot be |
---|
556 | |
---|
557 | |
---|
558 | |
---|
559 | Fielding, et al. Expires January 13, 2011 [Page 10] |
---|
560 | |
---|
561 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
562 | |
---|
563 | |
---|
564 | used to force a user agent to refresh its display or reload a |
---|
565 | resource. See Section 4 for an explanation of the difference between |
---|
566 | caches and history mechanisms. |
---|
567 | |
---|
568 | 2.3.1. Calculating Freshness Lifetime |
---|
569 | |
---|
570 | A cache can calculate the freshness lifetime (denoted as |
---|
571 | freshness_lifetime) of a response by using the first match of: |
---|
572 | |
---|
573 | o If the cache is shared and the s-maxage response cache directive |
---|
574 | (Section 3.2.2) is present, use its value, or |
---|
575 | |
---|
576 | o If the max-age response cache directive (Section 3.2.2) is |
---|
577 | present, use its value, or |
---|
578 | |
---|
579 | o If the Expires response header (Section 3.3) is present, use its |
---|
580 | value minus the value of the Date response header, or |
---|
581 | |
---|
582 | o Otherwise, no explicit expiration time is present in the response. |
---|
583 | A heuristic freshness lifetime might be applicable; see |
---|
584 | Section 2.3.1.1. |
---|
585 | |
---|
586 | Note that this calculation is not vulnerable to clock skew, since all |
---|
587 | of the information comes from the origin server. |
---|
588 | |
---|
589 | 2.3.1.1. Calculating Heuristic Freshness |
---|
590 | |
---|
591 | If no explicit expiration time is present in a stored response that |
---|
592 | has a status code of 200, 203, 206, 300, 301 or 410, a heuristic |
---|
593 | expiration time can be calculated. Heuristics MUST NOT be used for |
---|
594 | other response status codes. |
---|
595 | |
---|
596 | When a heuristic is used to calculate freshness lifetime, the cache |
---|
597 | SHOULD attach a Warning header with a 113 warn-code to the response |
---|
598 | if its current_age is more than 24 hours and such a warning is not |
---|
599 | already present. |
---|
600 | |
---|
601 | Also, if the response has a Last-Modified header (Section 6.6 of |
---|
602 | [Part4]), the heuristic expiration value SHOULD be no more than some |
---|
603 | fraction of the interval since that time. A typical setting of this |
---|
604 | fraction might be 10%. |
---|
605 | |
---|
606 | Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do |
---|
607 | not calculate heuristic freshness for URLs with query components |
---|
608 | (i.e., those containing '?'). In practice, this has not been |
---|
609 | widely implemented. Therefore, servers are encouraged to send |
---|
610 | explicit directives (e.g., Cache-Control: no-cache) if they wish |
---|
611 | to preclude caching. |
---|
612 | |
---|
613 | |
---|
614 | |
---|
615 | Fielding, et al. Expires January 13, 2011 [Page 11] |
---|
616 | |
---|
617 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
618 | |
---|
619 | |
---|
620 | 2.3.2. Calculating Age |
---|
621 | |
---|
622 | HTTP/1.1 uses the Age response-header to convey the estimated age of |
---|
623 | the response message when obtained from a cache. The Age field value |
---|
624 | is the cache's estimate of the amount of time since the response was |
---|
625 | generated or validated by the origin server. In essence, the Age |
---|
626 | value is the sum of the time that the response has been resident in |
---|
627 | each of the caches along the path from the origin server, plus the |
---|
628 | amount of time it has been in transit along network paths. |
---|
629 | |
---|
630 | The following data is used for the age calculation: |
---|
631 | |
---|
632 | age_value |
---|
633 | |
---|
634 | The term "age_value" denotes the value of the Age header |
---|
635 | (Section 3.1), in a form appropriate for arithmetic operation; or |
---|
636 | 0, if not available. |
---|
637 | |
---|
638 | date_value |
---|
639 | |
---|
640 | HTTP/1.1 requires origin servers to send a Date header, if |
---|
641 | possible, with every response, giving the time at which the |
---|
642 | response was generated. The term "date_value" denotes the value |
---|
643 | of the Date header, in a form appropriate for arithmetic |
---|
644 | operations. See Section 9.3 of [Part1] for the definition of the |
---|
645 | Date header, and for requirements regarding responses without a |
---|
646 | Date response header. |
---|
647 | |
---|
648 | now |
---|
649 | |
---|
650 | The term "now" means "the current value of the clock at the host |
---|
651 | performing the calculation". Hosts that use HTTP, but especially |
---|
652 | hosts running origin servers and caches, SHOULD use NTP |
---|
653 | ([RFC1305]) or some similar protocol to synchronize their clocks |
---|
654 | to a globally accurate time standard. |
---|
655 | |
---|
656 | request_time |
---|
657 | |
---|
658 | The current value of the clock at the host at the time the request |
---|
659 | resulting in the stored response was made. |
---|
660 | |
---|
661 | response_time |
---|
662 | |
---|
663 | The current value of the clock at the host at the time the |
---|
664 | response was received. |
---|
665 | |
---|
666 | A response's age can be calculated in two entirely independent ways: |
---|
667 | |
---|
668 | |
---|
669 | |
---|
670 | |
---|
671 | Fielding, et al. Expires January 13, 2011 [Page 12] |
---|
672 | |
---|
673 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
674 | |
---|
675 | |
---|
676 | 1. the "apparent_age": response_time minus date_value, if the local |
---|
677 | clock is reasonably well synchronized to the origin server's |
---|
678 | clock. If the result is negative, the result is replaced by |
---|
679 | zero. |
---|
680 | |
---|
681 | 2. the "corrected_age_value", if all of the caches along the |
---|
682 | response path implement HTTP/1.1; note this value MUST be |
---|
683 | interpreted relative to the time the request was initiated, not |
---|
684 | the time that the response was received. |
---|
685 | |
---|
686 | |
---|
687 | apparent_age = max(0, response_time - date_value); |
---|
688 | |
---|
689 | response_delay = response_time - request_time; |
---|
690 | corrected_age_value = age_value + response_delay; |
---|
691 | |
---|
692 | These are combined as |
---|
693 | |
---|
694 | corrected_initial_age = max(apparent_age, corrected_age_value); |
---|
695 | |
---|
696 | The current_age of a stored response can then be calculated by adding |
---|
697 | the amount of time (in seconds) since the stored response was last |
---|
698 | validated by the origin server to the corrected_initial_age. |
---|
699 | |
---|
700 | resident_time = now - response_time; |
---|
701 | current_age = corrected_initial_age + resident_time; |
---|
702 | |
---|
703 | 2.3.3. Serving Stale Responses |
---|
704 | |
---|
705 | A "stale" response is one that either has explicit expiry information |
---|
706 | or is allowed to have heuristic expiry calculated, but is not fresh |
---|
707 | according to the calculations in Section 2.3. |
---|
708 | |
---|
709 | Caches MUST NOT return a stale response if it is prohibited by an |
---|
710 | explicit in-protocol directive (e.g., by a "no-store" or "no-cache" |
---|
711 | cache directive, a "must-revalidate" cache-response-directive, or an |
---|
712 | applicable "s-maxage" or "proxy-revalidate" cache-response-directive; |
---|
713 | see Section 3.2.2). |
---|
714 | |
---|
715 | Caches SHOULD NOT return stale responses unless they are disconnected |
---|
716 | (i.e., it cannot contact the origin server or otherwise find a |
---|
717 | forward path) or otherwise explicitly allowed (e.g., the max-stale |
---|
718 | request directive; see Section 3.2.1). |
---|
719 | |
---|
720 | Stale responses SHOULD have a Warning header with the 110 warn-code |
---|
721 | (see Section 3.6). Likewise, the 112 warn-code SHOULD be sent on |
---|
722 | stale responses if the cache is disconnected. |
---|
723 | |
---|
724 | |
---|
725 | |
---|
726 | |
---|
727 | Fielding, et al. Expires January 13, 2011 [Page 13] |
---|
728 | |
---|
729 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
730 | |
---|
731 | |
---|
732 | If a cache receives a first-hand response (either an entire response, |
---|
733 | or a 304 (Not Modified) response) that it would normally forward to |
---|
734 | the requesting client, and the received response is no longer fresh, |
---|
735 | the cache SHOULD forward it to the requesting client without adding a |
---|
736 | new Warning (but without removing any existing Warning headers). A |
---|
737 | cache SHOULD NOT attempt to validate a response simply because that |
---|
738 | response became stale in transit. |
---|
739 | |
---|
740 | 2.4. Validation Model |
---|
741 | |
---|
742 | When a cache has one or more stored responses for a requested URI, |
---|
743 | but cannot serve any of them (e.g., because they are not fresh, or |
---|
744 | one cannot be selected; see Section 2.7), it can use the conditional |
---|
745 | request mechanism [Part4] in the forwarded request to give the origin |
---|
746 | server an opportunity to both select a valid stored response to be |
---|
747 | used, and to update it. This process is known as "validating" or |
---|
748 | "revalidating" the stored response. |
---|
749 | |
---|
750 | When sending such a conditional request, the cache SHOULD add an If- |
---|
751 | Modified-Since header whose value is that of the Last-Modified header |
---|
752 | from the selected (see Section 2.7) stored response, if available. |
---|
753 | |
---|
754 | Additionally, the cache SHOULD add an If-None-Match header whose |
---|
755 | value is that of the ETag header(s) from all responses stored for the |
---|
756 | requested URI, if present. However, if any of the stored responses |
---|
757 | contains only partial content, its entity-tag SHOULD NOT be included |
---|
758 | in the If-None-Match header field unless the request is for a range |
---|
759 | that would be fully satisfied by that stored response. |
---|
760 | |
---|
761 | A 304 (Not Modified) response status code indicates that the stored |
---|
762 | response can be updated and reused; see Section 2.8. |
---|
763 | |
---|
764 | A full response (i.e., one with a response body) indicates that none |
---|
765 | of the stored responses nominated in the conditional request is |
---|
766 | suitable. Instead, the full response is used both to satisfy the |
---|
767 | request and replace the stored response. [[TODO-req-missing: Should |
---|
768 | there be a requirement here?]] |
---|
769 | |
---|
770 | If a cache receives a 5xx response while attempting to validate a |
---|
771 | response, it MAY either forward this response to the requesting |
---|
772 | client, or act as if the server failed to respond. In the latter |
---|
773 | case, it MAY return a previously stored response (see Section 2.3.3). |
---|
774 | |
---|
775 | 2.5. Request Methods that Invalidate |
---|
776 | |
---|
777 | Because unsafe methods (Section 7.1.1 of [Part2]) have the potential |
---|
778 | for changing state on the origin server, intervening caches can use |
---|
779 | them to keep their contents up-to-date. |
---|
780 | |
---|
781 | |
---|
782 | |
---|
783 | Fielding, et al. Expires January 13, 2011 [Page 14] |
---|
784 | |
---|
785 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
786 | |
---|
787 | |
---|
788 | The following HTTP methods MUST cause a cache to invalidate the |
---|
789 | Effective Request URI (Section 4.3 of [Part1]) as well as the URI(s) |
---|
790 | in the Location and Content-Location headers (if present): |
---|
791 | |
---|
792 | o PUT |
---|
793 | |
---|
794 | o DELETE |
---|
795 | |
---|
796 | o POST |
---|
797 | |
---|
798 | An invalidation based on a URI from a Location or Content-Location |
---|
799 | header MUST NOT be performed if the host part of that URI differs |
---|
800 | from the host part in the Effective Request URI (Section 4.3 of |
---|
801 | [Part1]). This helps prevent denial of service attacks. |
---|
802 | |
---|
803 | [[TODO-def-host-part: "host part" needs to be specified better.]] |
---|
804 | |
---|
805 | A cache that passes through requests for methods it does not |
---|
806 | understand SHOULD invalidate the Effective Request URI (Section 4.3 |
---|
807 | of [Part1]). |
---|
808 | |
---|
809 | Here, "invalidate" means that the cache will either remove all stored |
---|
810 | responses related to the Effective Request URI, or will mark these as |
---|
811 | "invalid" and in need of a mandatory validation before they can be |
---|
812 | returned in response to a subsequent request. |
---|
813 | |
---|
814 | Note that this does not guarantee that all appropriate responses are |
---|
815 | invalidated. For example, the request that caused the change at the |
---|
816 | origin server might not have gone through the cache where a response |
---|
817 | is stored. |
---|
818 | |
---|
819 | [[TODO-spec-success-invalidate: specify that only successful (2xx, |
---|
820 | 3xx?) responses invalidate.]] |
---|
821 | |
---|
822 | 2.6. Shared Caching of Authenticated Responses |
---|
823 | |
---|
824 | Shared caches MUST NOT use a cached response to a request with an |
---|
825 | Authorization header (Section 3.1 of [Part7]) to satisfy any |
---|
826 | subsequent request unless a cache directive that allows such |
---|
827 | responses to be stored is present in the response. |
---|
828 | |
---|
829 | In this specification, the following Cache-Control response |
---|
830 | directives (Section 3.2.2) have such an effect: must-revalidate, |
---|
831 | public, s-maxage. |
---|
832 | |
---|
833 | Note that cached responses that contain the "must-revalidate" and/or |
---|
834 | "s-maxage" response directives are not allowed to be served stale |
---|
835 | (Section 2.3.3) by shared caches. In particular, a response with |
---|
836 | |
---|
837 | |
---|
838 | |
---|
839 | Fielding, et al. Expires January 13, 2011 [Page 15] |
---|
840 | |
---|
841 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
842 | |
---|
843 | |
---|
844 | either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to |
---|
845 | satisfy a subsequent request without revalidating it on the origin |
---|
846 | server. |
---|
847 | |
---|
848 | 2.7. Caching Negotiated Responses |
---|
849 | |
---|
850 | When a cache receives a request that can be satisfied by a stored |
---|
851 | response that has a Vary header field (Section 3.5), it MUST NOT use |
---|
852 | that response unless all of the selecting request-headers nominated |
---|
853 | by the Vary header match in both the original request (i.e., that |
---|
854 | associated with the stored response), and the presented request. |
---|
855 | |
---|
856 | The selecting request-headers from two requests are defined to match |
---|
857 | if and only if those in the first request can be transformed to those |
---|
858 | in the second request by applying any of the following: |
---|
859 | |
---|
860 | o adding or removing whitespace, where allowed in the header's |
---|
861 | syntax |
---|
862 | |
---|
863 | o combining multiple message-header fields with the same field name |
---|
864 | (see Section 3.2 of [Part1]) |
---|
865 | |
---|
866 | o normalizing both header values in a way that is known to have |
---|
867 | identical semantics, according to the header's specification |
---|
868 | (e.g., re-ordering field values when order is not significant; |
---|
869 | case-normalization, where values are defined to be case- |
---|
870 | insensitive) |
---|
871 | |
---|
872 | If (after any normalisation that may take place) a header field is |
---|
873 | absent from a request, it can only match another request if it is |
---|
874 | also absent there. |
---|
875 | |
---|
876 | A Vary header field-value of "*" always fails to match, and |
---|
877 | subsequent requests to that resource can only be properly interpreted |
---|
878 | by the origin server. |
---|
879 | |
---|
880 | The stored response with matching selecting request-headers is known |
---|
881 | as the selected response. |
---|
882 | |
---|
883 | If no selected response is available, the cache MAY forward the |
---|
884 | presented request to the origin server in a conditional request; see |
---|
885 | Section 2.4. |
---|
886 | |
---|
887 | 2.8. Combining Responses |
---|
888 | |
---|
889 | When a cache receives a 304 (Not Modified) response or a 206 (Partial |
---|
890 | Content) response (in this section, the "new" response"), it needs to |
---|
891 | created an updated response by combining the stored response with the |
---|
892 | |
---|
893 | |
---|
894 | |
---|
895 | Fielding, et al. Expires January 13, 2011 [Page 16] |
---|
896 | |
---|
897 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
898 | |
---|
899 | |
---|
900 | new one, so that the updated response can be used to satisfy the |
---|
901 | request. |
---|
902 | |
---|
903 | If the new response contains an ETag, it identifies the stored |
---|
904 | response to use. [[TODO-mention-CL: may need language about Content- |
---|
905 | Location here]][[TODO-inm-mult-etags: cover case where INM with |
---|
906 | multiple etags was sent]] |
---|
907 | |
---|
908 | If the status code is 206 (partial content), both the stored and new |
---|
909 | responses MUST have validators, and those validators MUST match using |
---|
910 | the strong comparison function (see Section 4 of [Part4]). |
---|
911 | Otherwise, the responses MUST NOT be combined. |
---|
912 | |
---|
913 | The stored response headers are used as those of the updated |
---|
914 | response, except that |
---|
915 | |
---|
916 | o any stored Warning headers with warn-code 1xx (see Section 3.6) |
---|
917 | MUST be deleted from the stored response and the updated response. |
---|
918 | |
---|
919 | o any stored Warning headers with warn-code 2xx MUST be retained in |
---|
920 | the stored response and the updated response. |
---|
921 | |
---|
922 | o any headers provided in the new response MUST replace the |
---|
923 | corresponding headers from the stored response. |
---|
924 | |
---|
925 | If a header field-name in the new response matches more than one |
---|
926 | header in the stored response, all such stored headers MUST be |
---|
927 | replaced. |
---|
928 | |
---|
929 | The updated response can [[TODO-is-req: requirement?]] be used to |
---|
930 | replace the stored response in cache. In the case of a 206 response, |
---|
931 | the combined entity-body MAY be stored. |
---|
932 | |
---|
933 | [[ISSUE-how-head: discuss how to handle HEAD updates]] |
---|
934 | |
---|
935 | 3. Header Field Definitions |
---|
936 | |
---|
937 | This section defines the syntax and semantics of HTTP/1.1 header |
---|
938 | fields related to caching. |
---|
939 | |
---|
940 | For entity-header fields, both sender and recipient refer to either |
---|
941 | the client or the server, depending on who sends and who receives the |
---|
942 | entity. |
---|
943 | |
---|
944 | 3.1. Age |
---|
945 | |
---|
946 | The "Age" response-header field conveys the sender's estimate of the |
---|
947 | amount of time since the response was generated or successfully |
---|
948 | |
---|
949 | |
---|
950 | |
---|
951 | Fielding, et al. Expires January 13, 2011 [Page 17] |
---|
952 | |
---|
953 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
954 | |
---|
955 | |
---|
956 | validated at the origin server. Age values are calculated as |
---|
957 | specified in Section 2.3.2. |
---|
958 | |
---|
959 | Age = "Age" ":" OWS Age-v |
---|
960 | Age-v = delta-seconds |
---|
961 | |
---|
962 | Age field-values are non-negative integers, representing time in |
---|
963 | seconds. |
---|
964 | |
---|
965 | delta-seconds = 1*DIGIT |
---|
966 | |
---|
967 | If a cache receives a value larger than the largest positive integer |
---|
968 | it can represent, or if any of its age calculations overflows, it |
---|
969 | MUST transmit an Age header with a field-value of 2147483648 (2^31). |
---|
970 | Caches SHOULD use an arithmetic type of at least 31 bits of range. |
---|
971 | |
---|
972 | The presence of an Age header field in a response implies that a |
---|
973 | response is not first-hand. However, the converse is not true, since |
---|
974 | HTTP/1.0 caches may not implement the Age header field. |
---|
975 | |
---|
976 | 3.2. Cache-Control |
---|
977 | |
---|
978 | The "Cache-Control" general-header field is used to specify |
---|
979 | directives for caches along the request/response chain. Such cache |
---|
980 | directives are unidirectional in that the presence of a directive in |
---|
981 | a request does not imply that the same directive is to be given in |
---|
982 | the response. |
---|
983 | |
---|
984 | HTTP/1.1 caches MUST obey the requirements of the Cache-Control |
---|
985 | directives defined in this section. See Section 3.2.3 for |
---|
986 | information about how Cache-Control directives defined elsewhere are |
---|
987 | handled. |
---|
988 | |
---|
989 | Note: HTTP/1.0 caches might not implement Cache-Control and might |
---|
990 | only implement Pragma: no-cache (see Section 3.4). |
---|
991 | |
---|
992 | Cache directives MUST be passed through by a proxy or gateway |
---|
993 | application, regardless of their significance to that application, |
---|
994 | since the directives might be applicable to all recipients along the |
---|
995 | request/response chain. It is not possible to target a directive to |
---|
996 | a specific cache. |
---|
997 | |
---|
998 | Cache-Control = "Cache-Control" ":" OWS Cache-Control-v |
---|
999 | Cache-Control-v = 1#cache-directive |
---|
1000 | |
---|
1001 | cache-directive = cache-request-directive |
---|
1002 | / cache-response-directive |
---|
1003 | |
---|
1004 | |
---|
1005 | |
---|
1006 | |
---|
1007 | Fielding, et al. Expires January 13, 2011 [Page 18] |
---|
1008 | |
---|
1009 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1010 | |
---|
1011 | |
---|
1012 | cache-extension = token [ "=" ( token / quoted-string ) ] |
---|
1013 | |
---|
1014 | 3.2.1. Request Cache-Control Directives |
---|
1015 | |
---|
1016 | cache-request-directive = |
---|
1017 | "no-cache" |
---|
1018 | / "no-store" |
---|
1019 | / "max-age" "=" delta-seconds |
---|
1020 | / "max-stale" [ "=" delta-seconds ] |
---|
1021 | / "min-fresh" "=" delta-seconds |
---|
1022 | / "no-transform" |
---|
1023 | / "only-if-cached" |
---|
1024 | / cache-extension |
---|
1025 | |
---|
1026 | no-cache |
---|
1027 | |
---|
1028 | The no-cache request directive indicates that a stored response |
---|
1029 | MUST NOT be used to satisfy the request without successful |
---|
1030 | validation on the origin server. |
---|
1031 | |
---|
1032 | no-store |
---|
1033 | |
---|
1034 | The no-store request directive indicates that a cache MUST NOT |
---|
1035 | store any part of either this request or any response to it. This |
---|
1036 | directive applies to both non-shared and shared caches. "MUST NOT |
---|
1037 | store" in this context means that the cache MUST NOT intentionally |
---|
1038 | store the information in non-volatile storage, and MUST make a |
---|
1039 | best-effort attempt to remove the information from volatile |
---|
1040 | storage as promptly as possible after forwarding it. |
---|
1041 | |
---|
1042 | This directive is NOT a reliable or sufficient mechanism for |
---|
1043 | ensuring privacy. In particular, malicious or compromised caches |
---|
1044 | might not recognize or obey this directive, and communications |
---|
1045 | networks may be vulnerable to eavesdropping. |
---|
1046 | |
---|
1047 | max-age |
---|
1048 | |
---|
1049 | The max-age request directive indicates that the client is willing |
---|
1050 | to accept a response whose age is no greater than the specified |
---|
1051 | time in seconds. Unless the max-stale request directive is also |
---|
1052 | present, the client is not willing to accept a stale response. |
---|
1053 | |
---|
1054 | max-stale |
---|
1055 | |
---|
1056 | The max-stale request directive indicates that the client is |
---|
1057 | willing to accept a response that has exceeded its expiration |
---|
1058 | time. If max-stale is assigned a value, then the client is |
---|
1059 | willing to accept a response that has exceeded its expiration time |
---|
1060 | |
---|
1061 | |
---|
1062 | |
---|
1063 | Fielding, et al. Expires January 13, 2011 [Page 19] |
---|
1064 | |
---|
1065 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1066 | |
---|
1067 | |
---|
1068 | by no more than the specified number of seconds. If no value is |
---|
1069 | assigned to max-stale, then the client is willing to accept a |
---|
1070 | stale response of any age. [[TODO-staleness: of any staleness? |
---|
1071 | --mnot]] |
---|
1072 | |
---|
1073 | min-fresh |
---|
1074 | |
---|
1075 | The min-fresh request directive indicates that the client is |
---|
1076 | willing to accept a response whose freshness lifetime is no less |
---|
1077 | than its current age plus the specified time in seconds. That is, |
---|
1078 | the client wants a response that will still be fresh for at least |
---|
1079 | the specified number of seconds. |
---|
1080 | |
---|
1081 | no-transform |
---|
1082 | |
---|
1083 | The no-transform request directive indicates that an intermediate |
---|
1084 | cache or proxy MUST NOT change the Content-Encoding, Content-Range |
---|
1085 | or Content-Type request headers, nor the request entity-body. |
---|
1086 | |
---|
1087 | only-if-cached |
---|
1088 | |
---|
1089 | The only-if-cached request directive indicates that the client |
---|
1090 | only wishes to return a stored response. If it receives this |
---|
1091 | directive, a cache SHOULD either respond using a stored response |
---|
1092 | that is consistent with the other constraints of the request, or |
---|
1093 | respond with a 504 (Gateway Timeout) status. If a group of caches |
---|
1094 | is being operated as a unified system with good internal |
---|
1095 | connectivity, such a request MAY be forwarded within that group of |
---|
1096 | caches. |
---|
1097 | |
---|
1098 | 3.2.2. Response Cache-Control Directives |
---|
1099 | |
---|
1100 | cache-response-directive = |
---|
1101 | "public" |
---|
1102 | / "private" [ "=" DQUOTE 1#field-name DQUOTE ] |
---|
1103 | / "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] |
---|
1104 | / "no-store" |
---|
1105 | / "no-transform" |
---|
1106 | / "must-revalidate" |
---|
1107 | / "proxy-revalidate" |
---|
1108 | / "max-age" "=" delta-seconds |
---|
1109 | / "s-maxage" "=" delta-seconds |
---|
1110 | / cache-extension |
---|
1111 | |
---|
1112 | public |
---|
1113 | |
---|
1114 | The public response directive indicates that the response MAY be |
---|
1115 | cached, even if it would normally be non-cacheable or cacheable |
---|
1116 | |
---|
1117 | |
---|
1118 | |
---|
1119 | Fielding, et al. Expires January 13, 2011 [Page 20] |
---|
1120 | |
---|
1121 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1122 | |
---|
1123 | |
---|
1124 | only within a non-shared cache. (See also Authorization, Section |
---|
1125 | 3.1 of [Part7], for additional details.) |
---|
1126 | |
---|
1127 | private |
---|
1128 | |
---|
1129 | The private response directive indicates that the response message |
---|
1130 | is intended for a single user and MUST NOT be stored by a shared |
---|
1131 | cache. A private (non-shared) cache MAY store the response. |
---|
1132 | |
---|
1133 | If the private response directive specifies one or more field- |
---|
1134 | names, this requirement is limited to the field-values associated |
---|
1135 | with the listed response headers. That is, the specified field- |
---|
1136 | names(s) MUST NOT be stored by a shared cache, whereas the |
---|
1137 | remainder of the response message MAY be. |
---|
1138 | |
---|
1139 | Note: This usage of the word private only controls where the |
---|
1140 | response may be stored, and cannot ensure the privacy of the |
---|
1141 | message content. Also, private response directives with field- |
---|
1142 | names are often handled by implementations as if an unqualified |
---|
1143 | private directive was received; i.e., the special handling for the |
---|
1144 | qualified form is not widely implemented. |
---|
1145 | |
---|
1146 | no-cache |
---|
1147 | |
---|
1148 | The no-cache response directive indicates that the response MUST |
---|
1149 | NOT be used to satisfy a subsequent request without successful |
---|
1150 | validation on the origin server. This allows an origin server to |
---|
1151 | prevent caching even by caches that have been configured to return |
---|
1152 | stale responses. |
---|
1153 | |
---|
1154 | If the no-cache response directive specifies one or more field- |
---|
1155 | names, this requirement is limited to the field-values associated |
---|
1156 | with the listed response headers. That is, the specified field- |
---|
1157 | name(s) MUST NOT be sent in the response to a subsequent request |
---|
1158 | without successful validation on the origin server. This allows |
---|
1159 | an origin server to prevent the re-use of certain header fields in |
---|
1160 | a response, while still allowing caching of the rest of the |
---|
1161 | response. |
---|
1162 | |
---|
1163 | Note: Most HTTP/1.0 caches will not recognize or obey this |
---|
1164 | directive. Also, no-cache response directives with field-names |
---|
1165 | are often handled by implementations as if an unqualified no-cache |
---|
1166 | directive was received; i.e., the special handling for the |
---|
1167 | qualified form is not widely implemented. |
---|
1168 | |
---|
1169 | |
---|
1170 | |
---|
1171 | |
---|
1172 | |
---|
1173 | |
---|
1174 | |
---|
1175 | Fielding, et al. Expires January 13, 2011 [Page 21] |
---|
1176 | |
---|
1177 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1178 | |
---|
1179 | |
---|
1180 | no-store |
---|
1181 | |
---|
1182 | The no-store response directive indicates that a cache MUST NOT |
---|
1183 | store any part of either the immediate request or response. This |
---|
1184 | directive applies to both non-shared and shared caches. "MUST NOT |
---|
1185 | store" in this context means that the cache MUST NOT intentionally |
---|
1186 | store the information in non-volatile storage, and MUST make a |
---|
1187 | best-effort attempt to remove the information from volatile |
---|
1188 | storage as promptly as possible after forwarding it. |
---|
1189 | |
---|
1190 | This directive is NOT a reliable or sufficient mechanism for |
---|
1191 | ensuring privacy. In particular, malicious or compromised caches |
---|
1192 | might not recognize or obey this directive, and communications |
---|
1193 | networks may be vulnerable to eavesdropping. |
---|
1194 | |
---|
1195 | must-revalidate |
---|
1196 | |
---|
1197 | The must-revalidate response directive indicates that once it has |
---|
1198 | become stale, the response MUST NOT be used to satisfy subsequent |
---|
1199 | requests without successful validation on the origin server. |
---|
1200 | |
---|
1201 | The must-revalidate directive is necessary to support reliable |
---|
1202 | operation for certain protocol features. In all circumstances an |
---|
1203 | HTTP/1.1 cache MUST obey the must-revalidate directive; in |
---|
1204 | particular, if the cache cannot reach the origin server for any |
---|
1205 | reason, it MUST generate a 504 (Gateway Timeout) response. |
---|
1206 | |
---|
1207 | Servers SHOULD send the must-revalidate directive if and only if |
---|
1208 | failure to validate a request on the entity could result in |
---|
1209 | incorrect operation, such as a silently unexecuted financial |
---|
1210 | transaction. |
---|
1211 | |
---|
1212 | proxy-revalidate |
---|
1213 | |
---|
1214 | The proxy-revalidate response directive has the same meaning as |
---|
1215 | the must-revalidate response directive, except that it does not |
---|
1216 | apply to non-shared caches. |
---|
1217 | |
---|
1218 | max-age |
---|
1219 | |
---|
1220 | The max-age response directive indicates that response is to be |
---|
1221 | considered stale after its age is greater than the specified |
---|
1222 | number of seconds. |
---|
1223 | |
---|
1224 | s-maxage |
---|
1225 | |
---|
1226 | The s-maxage response directive indicates that, in shared caches, |
---|
1227 | the maximum age specified by this directive overrides the maximum |
---|
1228 | |
---|
1229 | |
---|
1230 | |
---|
1231 | Fielding, et al. Expires January 13, 2011 [Page 22] |
---|
1232 | |
---|
1233 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1234 | |
---|
1235 | |
---|
1236 | age specified by either the max-age directive or the Expires |
---|
1237 | header. The s-maxage directive also implies the semantics of the |
---|
1238 | proxy-revalidate response directive. |
---|
1239 | |
---|
1240 | no-transform |
---|
1241 | |
---|
1242 | The no-transform response directive indicates that an intermediate |
---|
1243 | cache or proxy MUST NOT change the Content-Encoding, Content-Range |
---|
1244 | or Content-Type response headers, nor the response entity-body. |
---|
1245 | |
---|
1246 | 3.2.3. Cache Control Extensions |
---|
1247 | |
---|
1248 | The Cache-Control header field can be extended through the use of one |
---|
1249 | or more cache-extension tokens, each with an optional value. |
---|
1250 | Informational extensions (those that do not require a change in cache |
---|
1251 | behavior) can be added without changing the semantics of other |
---|
1252 | directives. Behavioral extensions are designed to work by acting as |
---|
1253 | modifiers to the existing base of cache directives. Both the new |
---|
1254 | directive and the standard directive are supplied, such that |
---|
1255 | applications that do not understand the new directive will default to |
---|
1256 | the behavior specified by the standard directive, and those that |
---|
1257 | understand the new directive will recognize it as modifying the |
---|
1258 | requirements associated with the standard directive. In this way, |
---|
1259 | extensions to the cache-control directives can be made without |
---|
1260 | requiring changes to the base protocol. |
---|
1261 | |
---|
1262 | This extension mechanism depends on an HTTP cache obeying all of the |
---|
1263 | cache-control directives defined for its native HTTP-version, obeying |
---|
1264 | certain extensions, and ignoring all directives that it does not |
---|
1265 | understand. |
---|
1266 | |
---|
1267 | For example, consider a hypothetical new response directive called |
---|
1268 | "community" that acts as a modifier to the private directive. We |
---|
1269 | define this new directive to mean that, in addition to any non-shared |
---|
1270 | cache, any cache that is shared only by members of the community |
---|
1271 | named within its value may cache the response. An origin server |
---|
1272 | wishing to allow the UCI community to use an otherwise private |
---|
1273 | response in their shared cache(s) could do so by including |
---|
1274 | |
---|
1275 | Cache-Control: private, community="UCI" |
---|
1276 | |
---|
1277 | A cache seeing this header field will act correctly even if the cache |
---|
1278 | does not understand the community cache-extension, since it will also |
---|
1279 | see and understand the private directive and thus default to the safe |
---|
1280 | behavior. |
---|
1281 | |
---|
1282 | Unrecognized cache directives MUST be ignored; it is assumed that any |
---|
1283 | cache directive likely to be unrecognized by an HTTP/1.1 cache will |
---|
1284 | |
---|
1285 | |
---|
1286 | |
---|
1287 | Fielding, et al. Expires January 13, 2011 [Page 23] |
---|
1288 | |
---|
1289 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1290 | |
---|
1291 | |
---|
1292 | be combined with standard directives (or the response's default |
---|
1293 | cacheability) such that the cache behavior will remain minimally |
---|
1294 | correct even if the cache does not understand the extension(s). |
---|
1295 | |
---|
1296 | The HTTP Cache Directive Registry defines the name space for the |
---|
1297 | cache directives. |
---|
1298 | |
---|
1299 | Registrations MUST include the following fields: |
---|
1300 | |
---|
1301 | o Cache Directive Name |
---|
1302 | |
---|
1303 | o Pointer to specification text |
---|
1304 | |
---|
1305 | Values to be added to this name space are subject to IETF review |
---|
1306 | ([RFC5226], Section 4.1). |
---|
1307 | |
---|
1308 | The registry itself is maintained at |
---|
1309 | <http://www.iana.org/assignments/http-cache-directives>. |
---|
1310 | |
---|
1311 | 3.3. Expires |
---|
1312 | |
---|
1313 | The "Expires" entity-header field gives the date/time after which the |
---|
1314 | response is considered stale. See Section 2.3 for further discussion |
---|
1315 | of the freshness model. |
---|
1316 | |
---|
1317 | The presence of an Expires field does not imply that the original |
---|
1318 | resource will change or cease to exist at, before, or after that |
---|
1319 | time. |
---|
1320 | |
---|
1321 | The field-value is an absolute date and time as defined by HTTP-date |
---|
1322 | in Section 6.1 of [Part1]; it MUST be sent in rfc1123-date format. |
---|
1323 | |
---|
1324 | Expires = "Expires" ":" OWS Expires-v |
---|
1325 | Expires-v = HTTP-date |
---|
1326 | |
---|
1327 | For example |
---|
1328 | |
---|
1329 | Expires: Thu, 01 Dec 1994 16:00:00 GMT |
---|
1330 | |
---|
1331 | Note: If a response includes a Cache-Control field with the max- |
---|
1332 | age directive (see Section 3.2.2), that directive overrides the |
---|
1333 | Expires field. Likewise, the s-maxage directive overrides Expires |
---|
1334 | in shared caches. |
---|
1335 | |
---|
1336 | HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in |
---|
1337 | the future. |
---|
1338 | |
---|
1339 | HTTP/1.1 clients and caches MUST treat other invalid date formats, |
---|
1340 | |
---|
1341 | |
---|
1342 | |
---|
1343 | Fielding, et al. Expires January 13, 2011 [Page 24] |
---|
1344 | |
---|
1345 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1346 | |
---|
1347 | |
---|
1348 | especially including the value "0", as in the past (i.e., "already |
---|
1349 | expired"). |
---|
1350 | |
---|
1351 | 3.4. Pragma |
---|
1352 | |
---|
1353 | The "Pragma" general-header field is used to include implementation- |
---|
1354 | specific directives that might apply to any recipient along the |
---|
1355 | request/response chain. All pragma directives specify optional |
---|
1356 | behavior from the viewpoint of the protocol; however, some systems |
---|
1357 | MAY require that behavior be consistent with the directives. |
---|
1358 | |
---|
1359 | Pragma = "Pragma" ":" OWS Pragma-v |
---|
1360 | Pragma-v = 1#pragma-directive |
---|
1361 | pragma-directive = "no-cache" / extension-pragma |
---|
1362 | extension-pragma = token [ "=" ( token / quoted-string ) ] |
---|
1363 | |
---|
1364 | When the no-cache directive is present in a request message, an |
---|
1365 | application SHOULD forward the request toward the origin server even |
---|
1366 | if it has a cached copy of what is being requested. This pragma |
---|
1367 | directive has the same semantics as the no-cache response directive |
---|
1368 | (see Section 3.2.2) and is defined here for backward compatibility |
---|
1369 | with HTTP/1.0. Clients SHOULD include both header fields when a no- |
---|
1370 | cache request is sent to a server not known to be HTTP/1.1 compliant. |
---|
1371 | HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had |
---|
1372 | sent "Cache-Control: no-cache". |
---|
1373 | |
---|
1374 | Note: Because the meaning of "Pragma: no-cache" as a response- |
---|
1375 | header field is not actually specified, it does not provide a |
---|
1376 | reliable replacement for "Cache-Control: no-cache" in a response. |
---|
1377 | |
---|
1378 | This mechanism is deprecated; no new Pragma directives will be |
---|
1379 | defined in HTTP. |
---|
1380 | |
---|
1381 | 3.5. Vary |
---|
1382 | |
---|
1383 | The "Vary" response-header field conveys the set of request-header |
---|
1384 | fields that were used to select the representation. |
---|
1385 | |
---|
1386 | Caches use this information, in part, to determine whether a stored |
---|
1387 | response can be used to satisfy a given request; see Section 2.7. |
---|
1388 | determines, while the response is fresh, whether a cache is permitted |
---|
1389 | to use the response to reply to a subsequent request without |
---|
1390 | validation; see Section 2.7. |
---|
1391 | |
---|
1392 | In uncacheable or stale responses, the Vary field value advises the |
---|
1393 | user agent about the criteria that were used to select the |
---|
1394 | representation. |
---|
1395 | |
---|
1396 | |
---|
1397 | |
---|
1398 | |
---|
1399 | Fielding, et al. Expires January 13, 2011 [Page 25] |
---|
1400 | |
---|
1401 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1402 | |
---|
1403 | |
---|
1404 | Vary = "Vary" ":" OWS Vary-v |
---|
1405 | Vary-v = "*" / 1#field-name |
---|
1406 | |
---|
1407 | The set of header fields named by the Vary field value is known as |
---|
1408 | the selecting request-headers. |
---|
1409 | |
---|
1410 | Servers SHOULD include a Vary header field with any cacheable |
---|
1411 | response that is subject to server-driven negotiation. Doing so |
---|
1412 | allows a cache to properly interpret future requests on that resource |
---|
1413 | and informs the user agent about the presence of negotiation on that |
---|
1414 | resource. A server MAY include a Vary header field with a non- |
---|
1415 | cacheable response that is subject to server-driven negotiation, |
---|
1416 | since this might provide the user agent with useful information about |
---|
1417 | the dimensions over which the response varies at the time of the |
---|
1418 | response. |
---|
1419 | |
---|
1420 | A Vary field value of "*" signals that unspecified parameters not |
---|
1421 | limited to the request-headers (e.g., the network address of the |
---|
1422 | client), play a role in the selection of the response representation; |
---|
1423 | therefore, a cache cannot determine whether this response is |
---|
1424 | appropriate. The "*" value MUST NOT be generated by a proxy server; |
---|
1425 | it may only be generated by an origin server. |
---|
1426 | |
---|
1427 | The field-names given are not limited to the set of standard request- |
---|
1428 | header fields defined by this specification. Field names are case- |
---|
1429 | insensitive. |
---|
1430 | |
---|
1431 | 3.6. Warning |
---|
1432 | |
---|
1433 | The "Warning" general-header field is used to carry additional |
---|
1434 | information about the status or transformation of a message that |
---|
1435 | might not be reflected in the message. This information is typically |
---|
1436 | used to warn about possible incorrectness introduced by caching |
---|
1437 | operations or transformations applied to the entity body of the |
---|
1438 | message. |
---|
1439 | |
---|
1440 | Warnings can be used for other purposes, both cache-related and |
---|
1441 | otherwise. The use of a warning, rather than an error status code, |
---|
1442 | distinguishes these responses from true failures. |
---|
1443 | |
---|
1444 | Warning headers can in general be applied to any message, however |
---|
1445 | some warn-codes are specific to caches and can only be applied to |
---|
1446 | response messages. |
---|
1447 | |
---|
1448 | |
---|
1449 | |
---|
1450 | |
---|
1451 | |
---|
1452 | |
---|
1453 | |
---|
1454 | |
---|
1455 | Fielding, et al. Expires January 13, 2011 [Page 26] |
---|
1456 | |
---|
1457 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1458 | |
---|
1459 | |
---|
1460 | Warning = "Warning" ":" OWS Warning-v |
---|
1461 | Warning-v = 1#warning-value |
---|
1462 | |
---|
1463 | warning-value = warn-code SP warn-agent SP warn-text |
---|
1464 | [SP warn-date] |
---|
1465 | |
---|
1466 | warn-code = 3DIGIT |
---|
1467 | warn-agent = ( uri-host [ ":" port ] ) / pseudonym |
---|
1468 | ; the name or pseudonym of the server adding |
---|
1469 | ; the Warning header, for use in debugging |
---|
1470 | warn-text = quoted-string |
---|
1471 | warn-date = DQUOTE HTTP-date DQUOTE |
---|
1472 | |
---|
1473 | Multiple warnings can be attached to a response (either by the origin |
---|
1474 | server or by a cache), including multiple warnings with the same code |
---|
1475 | number, only differing in warn-text. |
---|
1476 | |
---|
1477 | When this occurs, the user agent SHOULD inform the user of as many of |
---|
1478 | them as possible, in the order that they appear in the response. |
---|
1479 | |
---|
1480 | Systems that generate multiple Warning headers SHOULD order them with |
---|
1481 | this user agent behavior in mind. New Warning headers SHOULD be |
---|
1482 | added after any existing Warning headers. |
---|
1483 | |
---|
1484 | Warnings are assigned three digit warn-codes. The first digit |
---|
1485 | indicates whether the Warning is required to be deleted from a stored |
---|
1486 | response after validation: |
---|
1487 | |
---|
1488 | o 1xx Warnings describe the freshness or validation status of the |
---|
1489 | response, and so MUST be deleted by caches after validation. They |
---|
1490 | can only be generated by a cache when validating a cached entry, |
---|
1491 | and MUST NOT be generated in any other situation. |
---|
1492 | |
---|
1493 | o 2xx Warnings describe some aspect of the entity body or entity |
---|
1494 | headers that is not rectified by a validation (for example, a |
---|
1495 | lossy compression of the entity bodies) and MUST NOT be deleted by |
---|
1496 | caches after validation, unless a full response is returned, in |
---|
1497 | which case they MUST be. |
---|
1498 | |
---|
1499 | If an implementation sends a message with one or more Warning headers |
---|
1500 | to a receiver whose version is HTTP/1.0 or lower, then the sender |
---|
1501 | MUST include in each warning-value a warn-date that matches the Date |
---|
1502 | header in the message. |
---|
1503 | |
---|
1504 | If an implementation receives a message with a warning-value that |
---|
1505 | includes a warn-date, and that warn-date is different from the Date |
---|
1506 | value in the response, then that warning-value MUST be deleted from |
---|
1507 | the message before storing, forwarding, or using it. (preventing the |
---|
1508 | |
---|
1509 | |
---|
1510 | |
---|
1511 | Fielding, et al. Expires January 13, 2011 [Page 27] |
---|
1512 | |
---|
1513 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1514 | |
---|
1515 | |
---|
1516 | consequences of naive caching of Warning header fields.) If all of |
---|
1517 | the warning-values are deleted for this reason, the Warning header |
---|
1518 | MUST be deleted as well. |
---|
1519 | |
---|
1520 | The following warn-codes are defined by this specification, each with |
---|
1521 | a recommended warn-text in English, and a description of its meaning. |
---|
1522 | |
---|
1523 | 110 Response is stale |
---|
1524 | |
---|
1525 | SHOULD be included whenever the returned response is stale. |
---|
1526 | |
---|
1527 | 111 Revalidation failed |
---|
1528 | |
---|
1529 | SHOULD be included if a cache returns a stale response because an |
---|
1530 | attempt to validate the response failed, due to an inability to |
---|
1531 | reach the server. |
---|
1532 | |
---|
1533 | 112 Disconnected operation |
---|
1534 | |
---|
1535 | SHOULD be included if the cache is intentionally disconnected from |
---|
1536 | the rest of the network for a period of time. |
---|
1537 | |
---|
1538 | 113 Heuristic expiration |
---|
1539 | |
---|
1540 | SHOULD be included if the cache heuristically chose a freshness |
---|
1541 | lifetime greater than 24 hours and the response's age is greater |
---|
1542 | than 24 hours. |
---|
1543 | |
---|
1544 | 199 Miscellaneous warning |
---|
1545 | |
---|
1546 | The warning text can include arbitrary information to be presented |
---|
1547 | to a human user, or logged. A system receiving this warning MUST |
---|
1548 | NOT take any automated action, besides presenting the warning to |
---|
1549 | the user. |
---|
1550 | |
---|
1551 | 214 Transformation applied |
---|
1552 | |
---|
1553 | MUST be added by an intermediate cache or proxy if it applies any |
---|
1554 | transformation changing the content-coding (as specified in the |
---|
1555 | Content-Encoding header) or media-type (as specified in the |
---|
1556 | Content-Type header) of the response, or the entity-body of the |
---|
1557 | response, unless this Warning code already appears in the |
---|
1558 | response. |
---|
1559 | |
---|
1560 | 299 Miscellaneous persistent warning |
---|
1561 | |
---|
1562 | The warning text can include arbitrary information to be presented |
---|
1563 | to a human user, or logged. A system receiving this warning MUST |
---|
1564 | |
---|
1565 | |
---|
1566 | |
---|
1567 | Fielding, et al. Expires January 13, 2011 [Page 28] |
---|
1568 | |
---|
1569 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1570 | |
---|
1571 | |
---|
1572 | NOT take any automated action. |
---|
1573 | |
---|
1574 | 4. History Lists |
---|
1575 | |
---|
1576 | User agents often have history mechanisms, such as "Back" buttons and |
---|
1577 | history lists, that can be used to redisplay an entity retrieved |
---|
1578 | earlier in a session. |
---|
1579 | |
---|
1580 | The freshness model (Section 2.3) does not necessarily apply to |
---|
1581 | history mechanisms. I.e., a history mechanism can display a previous |
---|
1582 | representation even if it has expired. |
---|
1583 | |
---|
1584 | This does not prohibit the history mechanism from telling the user |
---|
1585 | that a view might be stale, or from honoring cache directives (e.g., |
---|
1586 | Cache-Control: no-store). |
---|
1587 | |
---|
1588 | 5. IANA Considerations |
---|
1589 | |
---|
1590 | 5.1. Cache Directive Registry |
---|
1591 | |
---|
1592 | The registration procedure for HTTP Cache Directives is defined by |
---|
1593 | Section 3.2.3 of this document. |
---|
1594 | |
---|
1595 | The HTTP Cache Directive Registry should be created at |
---|
1596 | <http://www.iana.org/assignments/http-cache-directives> and be |
---|
1597 | populated with the registrations below: |
---|
1598 | |
---|
1599 | +------------------------+------------------------------+ |
---|
1600 | | Cache Directive | Reference | |
---|
1601 | +------------------------+------------------------------+ |
---|
1602 | | max-age | Section 3.2.1, Section 3.2.2 | |
---|
1603 | | max-stale | Section 3.2.1 | |
---|
1604 | | min-fresh | Section 3.2.1 | |
---|
1605 | | must-revalidate | Section 3.2.2 | |
---|
1606 | | no-cache | Section 3.2.1, Section 3.2.2 | |
---|
1607 | | no-store | Section 3.2.1, Section 3.2.2 | |
---|
1608 | | no-transform | Section 3.2.1, Section 3.2.2 | |
---|
1609 | | only-if-cached | Section 3.2.1 | |
---|
1610 | | private | Section 3.2.2 | |
---|
1611 | | proxy-revalidate | Section 3.2.2 | |
---|
1612 | | public | Section 3.2.2 | |
---|
1613 | | s-maxage | Section 3.2.2 | |
---|
1614 | | stale-if-error | [RFC5861], Section 4 | |
---|
1615 | | stale-while-revalidate | [RFC5861], Section 3 | |
---|
1616 | +------------------------+------------------------------+ |
---|
1617 | |
---|
1618 | |
---|
1619 | |
---|
1620 | |
---|
1621 | |
---|
1622 | |
---|
1623 | Fielding, et al. Expires January 13, 2011 [Page 29] |
---|
1624 | |
---|
1625 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1626 | |
---|
1627 | |
---|
1628 | 5.2. Message Header Registration |
---|
1629 | |
---|
1630 | The Message Header Registry located at <http://www.iana.org/ |
---|
1631 | assignments/message-headers/message-header-index.html> should be |
---|
1632 | updated with the permanent registrations below (see [RFC3864]): |
---|
1633 | |
---|
1634 | +-------------------+----------+----------+-------------+ |
---|
1635 | | Header Field Name | Protocol | Status | Reference | |
---|
1636 | +-------------------+----------+----------+-------------+ |
---|
1637 | | Age | http | standard | Section 3.1 | |
---|
1638 | | Cache-Control | http | standard | Section 3.2 | |
---|
1639 | | Expires | http | standard | Section 3.3 | |
---|
1640 | | Pragma | http | standard | Section 3.4 | |
---|
1641 | | Vary | http | standard | Section 3.5 | |
---|
1642 | | Warning | http | standard | Section 3.6 | |
---|
1643 | +-------------------+----------+----------+-------------+ |
---|
1644 | |
---|
1645 | The change controller is: "IETF (iesg@ietf.org) - Internet |
---|
1646 | Engineering Task Force". |
---|
1647 | |
---|
1648 | 6. Security Considerations |
---|
1649 | |
---|
1650 | Caches expose additional potential vulnerabilities, since the |
---|
1651 | contents of the cache represent an attractive target for malicious |
---|
1652 | exploitation. Because cache contents persist after an HTTP request |
---|
1653 | is complete, an attack on the cache can reveal information long after |
---|
1654 | a user believes that the information has been removed from the |
---|
1655 | network. Therefore, cache contents should be protected as sensitive |
---|
1656 | information. |
---|
1657 | |
---|
1658 | 7. Acknowledgments |
---|
1659 | |
---|
1660 | Much of the content and presentation of the caching design is due to |
---|
1661 | suggestions and comments from individuals including: Shel Kaphan, |
---|
1662 | Paul Leach, Koen Holtman, David Morris, and Larry Masinter. |
---|
1663 | |
---|
1664 | 8. References |
---|
1665 | |
---|
1666 | 8.1. Normative References |
---|
1667 | |
---|
1668 | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
1669 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
1670 | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, |
---|
1671 | and Message Parsing", draft-ietf-httpbis-p1-messaging-10 |
---|
1672 | (work in progress), July 2010. |
---|
1673 | |
---|
1674 | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
1675 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
1676 | |
---|
1677 | |
---|
1678 | |
---|
1679 | Fielding, et al. Expires January 13, 2011 [Page 30] |
---|
1680 | |
---|
1681 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1682 | |
---|
1683 | |
---|
1684 | and J. Reschke, Ed., "HTTP/1.1, part 2: Message |
---|
1685 | Semantics", draft-ietf-httpbis-p2-semantics-10 (work in |
---|
1686 | progress), July 2010. |
---|
1687 | |
---|
1688 | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
1689 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
1690 | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional |
---|
1691 | Requests", draft-ietf-httpbis-p4-conditional-10 (work in |
---|
1692 | progress), July 2010. |
---|
1693 | |
---|
1694 | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
1695 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
1696 | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and |
---|
1697 | Partial Responses", draft-ietf-httpbis-p5-range-10 (work |
---|
1698 | in progress), July 2010. |
---|
1699 | |
---|
1700 | [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., |
---|
1701 | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., |
---|
1702 | and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", |
---|
1703 | draft-ietf-httpbis-p7-auth-10 (work in progress), |
---|
1704 | July 2010. |
---|
1705 | |
---|
1706 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
---|
1707 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
---|
1708 | |
---|
1709 | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax |
---|
1710 | Specifications: ABNF", STD 68, RFC 5234, January 2008. |
---|
1711 | |
---|
1712 | 8.2. Informative References |
---|
1713 | |
---|
1714 | [RFC1305] Mills, D., "Network Time Protocol (Version 3) |
---|
1715 | Specification, Implementation", RFC 1305, March 1992. |
---|
1716 | |
---|
1717 | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
---|
1718 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext |
---|
1719 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
---|
1720 | |
---|
1721 | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration |
---|
1722 | Procedures for Message Header Fields", BCP 90, RFC 3864, |
---|
1723 | September 2004. |
---|
1724 | |
---|
1725 | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an |
---|
1726 | IANA Considerations Section in RFCs", BCP 26, RFC 5226, |
---|
1727 | May 2008. |
---|
1728 | |
---|
1729 | [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale |
---|
1730 | Content", RFC 5861, April 2010. |
---|
1731 | |
---|
1732 | |
---|
1733 | |
---|
1734 | |
---|
1735 | Fielding, et al. Expires January 13, 2011 [Page 31] |
---|
1736 | |
---|
1737 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1738 | |
---|
1739 | |
---|
1740 | Appendix A. Compatibility with Previous Versions |
---|
1741 | |
---|
1742 | A.1. Changes from RFC 2068 |
---|
1743 | |
---|
1744 | A case was missed in the Cache-Control model of HTTP/1.1; s-maxage |
---|
1745 | was introduced to add this missing case. (Sections 2.1, 3.2). |
---|
1746 | |
---|
1747 | Range request responses would become very verbose if all meta-data |
---|
1748 | were always returned; by allowing the server to only send needed |
---|
1749 | headers in a 206 response, this problem can be avoided. |
---|
1750 | (Section 2.8) |
---|
1751 | |
---|
1752 | The Cache-Control: max-age directive was not properly defined for |
---|
1753 | responses. (Section 3.2.2) |
---|
1754 | |
---|
1755 | Warnings could be cached incorrectly, or not updated appropriately. |
---|
1756 | (Section 2.3, 2.8, 3.2, and 3.6) Warning also needed to be a general |
---|
1757 | header, as PUT or other methods may have need for it in requests. |
---|
1758 | |
---|
1759 | A.2. Changes from RFC 2616 |
---|
1760 | |
---|
1761 | Make the specified age calculation algorithm less conservative. |
---|
1762 | (Section 2.3.2) |
---|
1763 | |
---|
1764 | Remove requirement to consider Content-Location in successful |
---|
1765 | responses in order to determine the appropriate response to use. |
---|
1766 | (Section 2.4) |
---|
1767 | |
---|
1768 | Clarify denial of service attack avoidance requirement. |
---|
1769 | (Section 2.5) |
---|
1770 | |
---|
1771 | Do not mention RFC 2047 encoding and multiple languages in Warning |
---|
1772 | headers anymore, as these aspects never were implemented. |
---|
1773 | (Section 3.6) |
---|
1774 | |
---|
1775 | Appendix B. Collected ABNF |
---|
1776 | |
---|
1777 | Age = "Age:" OWS Age-v |
---|
1778 | Age-v = delta-seconds |
---|
1779 | |
---|
1780 | Cache-Control = "Cache-Control:" OWS Cache-Control-v |
---|
1781 | Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS |
---|
1782 | cache-directive ] ) |
---|
1783 | |
---|
1784 | Expires = "Expires:" OWS Expires-v |
---|
1785 | Expires-v = HTTP-date |
---|
1786 | |
---|
1787 | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> |
---|
1788 | |
---|
1789 | |
---|
1790 | |
---|
1791 | Fielding, et al. Expires January 13, 2011 [Page 32] |
---|
1792 | |
---|
1793 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1794 | |
---|
1795 | |
---|
1796 | OWS = <OWS, defined in [Part1], Section 1.2.2> |
---|
1797 | |
---|
1798 | Pragma = "Pragma:" OWS Pragma-v |
---|
1799 | Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS |
---|
1800 | pragma-directive ] ) |
---|
1801 | |
---|
1802 | Vary = "Vary:" OWS Vary-v |
---|
1803 | Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name |
---|
1804 | ] ) ) |
---|
1805 | |
---|
1806 | Warning = "Warning:" OWS Warning-v |
---|
1807 | Warning-v = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value |
---|
1808 | ] ) |
---|
1809 | |
---|
1810 | cache-directive = cache-request-directive / cache-response-directive |
---|
1811 | cache-extension = token [ "=" ( token / quoted-string ) ] |
---|
1812 | cache-request-directive = "no-cache" / "no-store" / ( "max-age=" |
---|
1813 | delta-seconds ) / ( "max-stale" [ "=" delta-seconds ] ) / ( |
---|
1814 | "min-fresh=" delta-seconds ) / "no-transform" / "only-if-cached" / |
---|
1815 | cache-extension |
---|
1816 | cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( "," |
---|
1817 | OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( |
---|
1818 | "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS |
---|
1819 | field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / |
---|
1820 | "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds |
---|
1821 | ) / ( "s-maxage=" delta-seconds ) / cache-extension |
---|
1822 | |
---|
1823 | delta-seconds = 1*DIGIT |
---|
1824 | |
---|
1825 | extension-pragma = token [ "=" ( token / quoted-string ) ] |
---|
1826 | |
---|
1827 | field-name = <field-name, defined in [Part1], Section 3.2> |
---|
1828 | |
---|
1829 | port = <port, defined in [Part1], Section 2.6> |
---|
1830 | pragma-directive = "no-cache" / extension-pragma |
---|
1831 | pseudonym = <pseudonym, defined in [Part1], Section 9.9> |
---|
1832 | |
---|
1833 | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> |
---|
1834 | |
---|
1835 | token = <token, defined in [Part1], Section 1.2.2> |
---|
1836 | |
---|
1837 | uri-host = <uri-host, defined in [Part1], Section 2.6> |
---|
1838 | |
---|
1839 | warn-agent = ( uri-host [ ":" port ] ) / pseudonym |
---|
1840 | warn-code = 3DIGIT |
---|
1841 | warn-date = DQUOTE HTTP-date DQUOTE |
---|
1842 | warn-text = quoted-string |
---|
1843 | |
---|
1844 | |
---|
1845 | |
---|
1846 | |
---|
1847 | Fielding, et al. Expires January 13, 2011 [Page 33] |
---|
1848 | |
---|
1849 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1850 | |
---|
1851 | |
---|
1852 | warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date |
---|
1853 | ] |
---|
1854 | |
---|
1855 | ABNF diagnostics: |
---|
1856 | |
---|
1857 | ; Age defined but not used |
---|
1858 | ; Cache-Control defined but not used |
---|
1859 | ; Expires defined but not used |
---|
1860 | ; Pragma defined but not used |
---|
1861 | ; Vary defined but not used |
---|
1862 | ; Warning defined but not used |
---|
1863 | |
---|
1864 | Appendix C. Change Log (to be removed by RFC Editor before publication) |
---|
1865 | |
---|
1866 | C.1. Since RFC2616 |
---|
1867 | |
---|
1868 | Extracted relevant partitions from [RFC2616]. |
---|
1869 | |
---|
1870 | C.2. Since draft-ietf-httpbis-p6-cache-00 |
---|
1871 | |
---|
1872 | Closed issues: |
---|
1873 | |
---|
1874 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/9>: "Trailer" |
---|
1875 | (<http://purl.org/NET/http-errata#trailer-hop>) |
---|
1876 | |
---|
1877 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/12>: "Invalidation |
---|
1878 | after Update or Delete" |
---|
1879 | (<http://purl.org/NET/http-errata#invalidupd>) |
---|
1880 | |
---|
1881 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and |
---|
1882 | Informative references" |
---|
1883 | |
---|
1884 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference |
---|
1885 | typo" |
---|
1886 | |
---|
1887 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/49>: "Connection |
---|
1888 | header text" |
---|
1889 | |
---|
1890 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative |
---|
1891 | references" |
---|
1892 | |
---|
1893 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1 |
---|
1894 | Reference" |
---|
1895 | |
---|
1896 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up- |
---|
1897 | to-date references" |
---|
1898 | |
---|
1899 | |
---|
1900 | |
---|
1901 | |
---|
1902 | |
---|
1903 | Fielding, et al. Expires January 13, 2011 [Page 34] |
---|
1904 | |
---|
1905 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1906 | |
---|
1907 | |
---|
1908 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/87>: "typo in |
---|
1909 | 13.2.2" |
---|
1910 | |
---|
1911 | Other changes: |
---|
1912 | |
---|
1913 | o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress |
---|
1914 | on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |
---|
1915 | |
---|
1916 | C.3. Since draft-ietf-httpbis-p6-cache-01 |
---|
1917 | |
---|
1918 | Closed issues: |
---|
1919 | |
---|
1920 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not |
---|
1921 | used" |
---|
1922 | |
---|
1923 | Other changes: |
---|
1924 | |
---|
1925 | o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work |
---|
1926 | in progress on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>) |
---|
1927 | |
---|
1928 | o Add explicit references to BNF syntax and rules imported from |
---|
1929 | other parts of the specification. |
---|
1930 | |
---|
1931 | C.4. Since draft-ietf-httpbis-p6-cache-02 |
---|
1932 | |
---|
1933 | Ongoing work on IANA Message Header Registration |
---|
1934 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>): |
---|
1935 | |
---|
1936 | o Reference RFC 3984, and update header registrations for headers |
---|
1937 | defined in this document. |
---|
1938 | |
---|
1939 | C.5. Since draft-ietf-httpbis-p6-cache-03 |
---|
1940 | |
---|
1941 | Closed issues: |
---|
1942 | |
---|
1943 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/106>: "Vary header |
---|
1944 | classification" |
---|
1945 | |
---|
1946 | C.6. Since draft-ietf-httpbis-p6-cache-04 |
---|
1947 | |
---|
1948 | Ongoing work on ABNF conversion |
---|
1949 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
1950 | |
---|
1951 | o Use "/" instead of "|" for alternatives. |
---|
1952 | |
---|
1953 | o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional |
---|
1954 | whitespace ("OWS") and required whitespace ("RWS"). |
---|
1955 | |
---|
1956 | |
---|
1957 | |
---|
1958 | |
---|
1959 | Fielding, et al. Expires January 13, 2011 [Page 35] |
---|
1960 | |
---|
1961 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
1962 | |
---|
1963 | |
---|
1964 | o Rewrite ABNFs to spell out whitespace rules, factor out header |
---|
1965 | value format definitions. |
---|
1966 | |
---|
1967 | C.7. Since draft-ietf-httpbis-p6-cache-05 |
---|
1968 | |
---|
1969 | This is a total rewrite of this part of the specification. |
---|
1970 | |
---|
1971 | Affected issues: |
---|
1972 | |
---|
1973 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of |
---|
1974 | 1xx Warn-Codes" |
---|
1975 | |
---|
1976 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |
---|
1977 | 13.5.1 and 13.5.2" |
---|
1978 | |
---|
1979 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/138>: "The role of |
---|
1980 | Warning and Semantic Transparency in Caching" |
---|
1981 | |
---|
1982 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and |
---|
1983 | Caching" |
---|
1984 | |
---|
1985 | In addition: Final work on ABNF conversion |
---|
1986 | (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>): |
---|
1987 | |
---|
1988 | o Add appendix containing collected and expanded ABNF, reorganize |
---|
1989 | ABNF introduction. |
---|
1990 | |
---|
1991 | C.8. Since draft-ietf-httpbis-p6-cache-06 |
---|
1992 | |
---|
1993 | Closed issues: |
---|
1994 | |
---|
1995 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for |
---|
1996 | numeric protocol elements" |
---|
1997 | |
---|
1998 | Affected issues: |
---|
1999 | |
---|
2000 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non- |
---|
2001 | existant headers |
---|
2002 | |
---|
2003 | C.9. Since draft-ietf-httpbis-p6-cache-07 |
---|
2004 | |
---|
2005 | Closed issues: |
---|
2006 | |
---|
2007 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of |
---|
2008 | 1xx Warn-Codes" |
---|
2009 | |
---|
2010 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- |
---|
2011 | Location on 304 responses" |
---|
2012 | |
---|
2013 | |
---|
2014 | |
---|
2015 | Fielding, et al. Expires January 13, 2011 [Page 36] |
---|
2016 | |
---|
2017 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
2018 | |
---|
2019 | |
---|
2020 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and |
---|
2021 | no-cache CC directives with headers" |
---|
2022 | |
---|
2023 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and |
---|
2024 | warn-text" |
---|
2025 | |
---|
2026 | C.10. Since draft-ietf-httpbis-p6-cache-08 |
---|
2027 | |
---|
2028 | Closed issues: |
---|
2029 | |
---|
2030 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/147>: "serving |
---|
2031 | negotiated responses from cache: header-specific canonicalization" |
---|
2032 | |
---|
2033 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/197>: "Effect of CC |
---|
2034 | directives on history lists" |
---|
2035 | |
---|
2036 | Affected issues: |
---|
2037 | |
---|
2038 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes |
---|
2039 | and caching |
---|
2040 | |
---|
2041 | Partly resolved issues: |
---|
2042 | |
---|
2043 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of |
---|
2044 | 13.5.1 and 13.5.2" |
---|
2045 | |
---|
2046 | C.11. Since draft-ietf-httpbis-p6-cache-09 |
---|
2047 | |
---|
2048 | Closed issues: |
---|
2049 | |
---|
2050 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/29>: "Age |
---|
2051 | calculation" |
---|
2052 | |
---|
2053 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/168>: "Clarify |
---|
2054 | differences between / requirements for request and response CC |
---|
2055 | directives" |
---|
2056 | |
---|
2057 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/174>: "Caching |
---|
2058 | authenticated responses" |
---|
2059 | |
---|
2060 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/208>: "IANA registry |
---|
2061 | for cache-control directives" |
---|
2062 | |
---|
2063 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/211>: "Heuristic |
---|
2064 | caching of URLs with query components" |
---|
2065 | |
---|
2066 | Partly resolved issues: |
---|
2067 | |
---|
2068 | |
---|
2069 | |
---|
2070 | |
---|
2071 | Fielding, et al. Expires January 13, 2011 [Page 37] |
---|
2072 | |
---|
2073 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
2074 | |
---|
2075 | |
---|
2076 | o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the |
---|
2077 | requested resource's URI" |
---|
2078 | |
---|
2079 | Index |
---|
2080 | |
---|
2081 | A |
---|
2082 | age 6 |
---|
2083 | Age header 17 |
---|
2084 | |
---|
2085 | C |
---|
2086 | cache 5 |
---|
2087 | Cache Directives |
---|
2088 | max-age 19, 22 |
---|
2089 | max-stale 19 |
---|
2090 | min-fresh 20 |
---|
2091 | must-revalidate 22 |
---|
2092 | no-cache 19, 21 |
---|
2093 | no-store 19, 22 |
---|
2094 | no-transform 20, 23 |
---|
2095 | only-if-cached 20 |
---|
2096 | private 21 |
---|
2097 | proxy-revalidate 22 |
---|
2098 | public 20 |
---|
2099 | s-maxage 22 |
---|
2100 | Cache-Control header 18 |
---|
2101 | cacheable 5 |
---|
2102 | |
---|
2103 | E |
---|
2104 | Expires header 24 |
---|
2105 | explicit expiration time 5 |
---|
2106 | |
---|
2107 | F |
---|
2108 | first-hand 6 |
---|
2109 | fresh 6 |
---|
2110 | freshness lifetime 6 |
---|
2111 | |
---|
2112 | G |
---|
2113 | Grammar |
---|
2114 | Age 18 |
---|
2115 | Age-v 18 |
---|
2116 | Cache-Control 18 |
---|
2117 | Cache-Control-v 18 |
---|
2118 | cache-extension 18 |
---|
2119 | cache-request-directive 19 |
---|
2120 | cache-response-directive 20 |
---|
2121 | delta-seconds 18 |
---|
2122 | Expires 24 |
---|
2123 | Expires-v 24 |
---|
2124 | |
---|
2125 | |
---|
2126 | |
---|
2127 | Fielding, et al. Expires January 13, 2011 [Page 38] |
---|
2128 | |
---|
2129 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
2130 | |
---|
2131 | |
---|
2132 | extension-pragma 25 |
---|
2133 | Pragma 25 |
---|
2134 | pragma-directive 25 |
---|
2135 | Pragma-v 25 |
---|
2136 | Vary 26 |
---|
2137 | Vary-v 26 |
---|
2138 | warn-agent 27 |
---|
2139 | warn-code 27 |
---|
2140 | warn-date 27 |
---|
2141 | warn-text 27 |
---|
2142 | Warning 27 |
---|
2143 | Warning-v 27 |
---|
2144 | warning-value 27 |
---|
2145 | |
---|
2146 | H |
---|
2147 | Headers |
---|
2148 | Age 17 |
---|
2149 | Cache-Control 18 |
---|
2150 | Expires 24 |
---|
2151 | Pragma 25 |
---|
2152 | Vary 25 |
---|
2153 | Warning 26 |
---|
2154 | heuristic expiration time 5 |
---|
2155 | |
---|
2156 | M |
---|
2157 | max-age |
---|
2158 | Cache Directive 19, 22 |
---|
2159 | max-stale |
---|
2160 | Cache Directive 19 |
---|
2161 | min-fresh |
---|
2162 | Cache Directive 20 |
---|
2163 | must-revalidate |
---|
2164 | Cache Directive 22 |
---|
2165 | |
---|
2166 | N |
---|
2167 | no-cache |
---|
2168 | Cache Directive 19, 21 |
---|
2169 | no-store |
---|
2170 | Cache Directive 19, 22 |
---|
2171 | no-transform |
---|
2172 | Cache Directive 20, 23 |
---|
2173 | |
---|
2174 | O |
---|
2175 | only-if-cached |
---|
2176 | Cache Directive 20 |
---|
2177 | |
---|
2178 | P |
---|
2179 | Pragma header 25 |
---|
2180 | |
---|
2181 | |
---|
2182 | |
---|
2183 | Fielding, et al. Expires January 13, 2011 [Page 39] |
---|
2184 | |
---|
2185 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
2186 | |
---|
2187 | |
---|
2188 | private |
---|
2189 | Cache Directive 21 |
---|
2190 | proxy-revalidate |
---|
2191 | Cache Directive 22 |
---|
2192 | public |
---|
2193 | Cache Directive 20 |
---|
2194 | |
---|
2195 | S |
---|
2196 | s-maxage |
---|
2197 | Cache Directive 22 |
---|
2198 | stale 6 |
---|
2199 | |
---|
2200 | V |
---|
2201 | validator 6 |
---|
2202 | Vary header 25 |
---|
2203 | |
---|
2204 | W |
---|
2205 | Warning header 26 |
---|
2206 | |
---|
2207 | Authors' Addresses |
---|
2208 | |
---|
2209 | Roy T. Fielding (editor) |
---|
2210 | Day Software |
---|
2211 | 23 Corporate Plaza DR, Suite 280 |
---|
2212 | Newport Beach, CA 92660 |
---|
2213 | USA |
---|
2214 | |
---|
2215 | Phone: +1-949-706-5300 |
---|
2216 | Fax: +1-949-706-5305 |
---|
2217 | EMail: fielding@gbiv.com |
---|
2218 | URI: http://roy.gbiv.com/ |
---|
2219 | |
---|
2220 | |
---|
2221 | Jim Gettys |
---|
2222 | Alcatel-Lucent Bell Labs |
---|
2223 | 21 Oak Knoll Road |
---|
2224 | Carlisle, MA 01741 |
---|
2225 | USA |
---|
2226 | |
---|
2227 | EMail: jg@freedesktop.org |
---|
2228 | URI: http://gettys.wordpress.com/ |
---|
2229 | |
---|
2230 | |
---|
2231 | |
---|
2232 | |
---|
2233 | |
---|
2234 | |
---|
2235 | |
---|
2236 | |
---|
2237 | |
---|
2238 | |
---|
2239 | Fielding, et al. Expires January 13, 2011 [Page 40] |
---|
2240 | |
---|
2241 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
2242 | |
---|
2243 | |
---|
2244 | Jeffrey C. Mogul |
---|
2245 | Hewlett-Packard Company |
---|
2246 | HP Labs, Large Scale Systems Group |
---|
2247 | 1501 Page Mill Road, MS 1177 |
---|
2248 | Palo Alto, CA 94304 |
---|
2249 | USA |
---|
2250 | |
---|
2251 | EMail: JeffMogul@acm.org |
---|
2252 | |
---|
2253 | |
---|
2254 | Henrik Frystyk Nielsen |
---|
2255 | Microsoft Corporation |
---|
2256 | 1 Microsoft Way |
---|
2257 | Redmond, WA 98052 |
---|
2258 | USA |
---|
2259 | |
---|
2260 | EMail: henrikn@microsoft.com |
---|
2261 | |
---|
2262 | |
---|
2263 | Larry Masinter |
---|
2264 | Adobe Systems, Incorporated |
---|
2265 | 345 Park Ave |
---|
2266 | San Jose, CA 95110 |
---|
2267 | USA |
---|
2268 | |
---|
2269 | EMail: LMM@acm.org |
---|
2270 | URI: http://larry.masinter.net/ |
---|
2271 | |
---|
2272 | |
---|
2273 | Paul J. Leach |
---|
2274 | Microsoft Corporation |
---|
2275 | 1 Microsoft Way |
---|
2276 | Redmond, WA 98052 |
---|
2277 | |
---|
2278 | EMail: paulle@microsoft.com |
---|
2279 | |
---|
2280 | |
---|
2281 | Tim Berners-Lee |
---|
2282 | World Wide Web Consortium |
---|
2283 | MIT Computer Science and Artificial Intelligence Laboratory |
---|
2284 | The Stata Center, Building 32 |
---|
2285 | 32 Vassar Street |
---|
2286 | Cambridge, MA 02139 |
---|
2287 | USA |
---|
2288 | |
---|
2289 | EMail: timbl@w3.org |
---|
2290 | URI: http://www.w3.org/People/Berners-Lee/ |
---|
2291 | |
---|
2292 | |
---|
2293 | |
---|
2294 | |
---|
2295 | Fielding, et al. Expires January 13, 2011 [Page 41] |
---|
2296 | |
---|
2297 | Internet-Draft HTTP/1.1, Part 6 July 2010 |
---|
2298 | |
---|
2299 | |
---|
2300 | Yves Lafon (editor) |
---|
2301 | World Wide Web Consortium |
---|
2302 | W3C / ERCIM |
---|
2303 | 2004, rte des Lucioles |
---|
2304 | Sophia-Antipolis, AM 06902 |
---|
2305 | France |
---|
2306 | |
---|
2307 | EMail: ylafon@w3.org |
---|
2308 | URI: http://www.raubacapeu.net/people/yves/ |
---|
2309 | |
---|
2310 | |
---|
2311 | Mark Nottingham (editor) |
---|
2312 | |
---|
2313 | EMail: mnot@mnot.net |
---|
2314 | URI: http://www.mnot.net/ |
---|
2315 | |
---|
2316 | |
---|
2317 | Julian F. Reschke (editor) |
---|
2318 | greenbytes GmbH |
---|
2319 | Hafenweg 16 |
---|
2320 | Muenster, NW 48155 |
---|
2321 | Germany |
---|
2322 | |
---|
2323 | Phone: +49 251 2807760 |
---|
2324 | Fax: +49 251 2807761 |
---|
2325 | EMail: julian.reschke@greenbytes.de |
---|
2326 | URI: http://greenbytes.de/tech/webdav/ |
---|
2327 | |
---|
2328 | |
---|
2329 | |
---|
2330 | |
---|
2331 | |
---|
2332 | |
---|
2333 | |
---|
2334 | |
---|
2335 | |
---|
2336 | |
---|
2337 | |
---|
2338 | |
---|
2339 | |
---|
2340 | |
---|
2341 | |
---|
2342 | |
---|
2343 | |
---|
2344 | |
---|
2345 | |
---|
2346 | |
---|
2347 | |
---|
2348 | |
---|
2349 | |
---|
2350 | |
---|
2351 | Fielding, et al. Expires January 13, 2011 [Page 42] |
---|
2352 | |
---|