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