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