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