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