source: draft-ietf-httpbis/latest/p6-cache.xml @ 1333

Last change on this file since 1333 was 1333, checked in by julian.reschke@…, 8 years ago

update change logs

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