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