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

Last change on this file since 394 was 394, checked in by mnot@…, 11 years ago

big stab at a major rewrite

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