source: draft-ietf-httpbis/02/draft-ietf-httpbis-p6-cache-02.xml @ 872

Last change on this file since 872 was 559, checked in by fielding@…, 11 years ago

remove executable and set eol-style for earlier drafts

  • Property svn:eol-style set to native
File size: 122.6 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
7<?rfc toc="yes" ?>
8<?rfc symrefs="yes" ?>
9<?rfc sortrefs="yes" ?>
10<?rfc compact="yes"?>
11<?rfc subcompact="no" ?>
12<?rfc linkmailto="no" ?>
13<?rfc editing="no" ?>
14<?rfc comments="yes"?>
15<?rfc inline="yes"?>
16<!DOCTYPE rfc
17  PUBLIC "" "rfc2629.dtd">
18<rfc obsoletes="2616" category="std" ipr="full3978" docName="draft-ietf-httpbis-p6-cache-02">
19<front>
20
21  <title abbrev="HTTP/1.1, Part 6">HTTP/1.1, part 6: Caching</title>
22
23  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
24    <organization abbrev="Day Software">Day Software</organization>
25    <address>
26      <postal>
27        <street>23 Corporate Plaza DR, Suite 280</street>
28        <city>Newport Beach</city>
29        <region>CA</region>
30        <code>92660</code>
31        <country>USA</country>
32      </postal>
33      <phone>+1-949-706-5300</phone>
34      <facsimile>+1-949-706-5305</facsimile>
35      <email>fielding@gbiv.com</email>
36      <uri>http://roy.gbiv.com/</uri>
37    </address>
38  </author>
39
40  <author initials="J." surname="Gettys" fullname="Jim Gettys">
41    <organization>One Laptop per Child</organization>
42    <address>
43      <postal>
44        <street>21 Oak Knoll Road</street>
45        <city>Carlisle</city>
46        <region>MA</region>
47        <code>01741</code>
48        <country>USA</country>
49      </postal>
50      <email>jg@laptop.org</email>
51      <uri>http://www.laptop.org/</uri>
52    </address>
53  </author>
54 
55  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
56    <organization abbrev="HP">Hewlett-Packard Company</organization>
57    <address>
58      <postal>
59        <street>HP Labs, Large Scale Systems Group</street>
60        <street>1501 Page Mill Road, MS 1177</street>
61        <city>Palo Alto</city>
62        <region>CA</region>
63        <code>94304</code>
64        <country>USA</country>
65      </postal>
66      <email>JeffMogul@acm.org</email>
67    </address>
68  </author>
69
70  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
71    <organization abbrev="Microsoft">Microsoft Corporation</organization>
72    <address>
73      <postal>
74        <street>1 Microsoft Way</street>
75        <city>Redmond</city>
76        <region>WA</region>
77        <code>98052</code>
78        <country>USA</country>
79      </postal>
80      <email>henrikn@microsoft.com</email>
81    </address>
82  </author>
83
84  <author initials="L." surname="Masinter" fullname="Larry Masinter">
85    <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
86    <address>
87      <postal>
88        <street>345 Park Ave</street>
89        <city>San Jose</city>
90        <region>CA</region>
91        <code>95110</code>
92        <country>USA</country>
93      </postal>
94      <email>LMM@acm.org</email>
95      <uri>http://larry.masinter.net/</uri>
96    </address>
97  </author>
98 
99  <author initials="P." surname="Leach" fullname="Paul J. Leach">
100    <organization abbrev="Microsoft">Microsoft Corporation</organization>
101    <address>
102      <postal>
103        <street>1 Microsoft Way</street>
104        <city>Redmond</city>
105        <region>WA</region>
106        <code>98052</code>
107      </postal>
108      <email>paulle@microsoft.com</email>
109    </address>
110  </author>
111   
112  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
113    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
114    <address>
115      <postal>
116        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
117        <street>The Stata Center, Building 32</street>
118        <street>32 Vassar Street</street>
119        <city>Cambridge</city>
120        <region>MA</region>
121        <code>02139</code>
122        <country>USA</country>
123      </postal>
124      <email>timbl@w3.org</email>
125      <uri>http://www.w3.org/People/Berners-Lee/</uri>
126    </address>
127  </author>
128
129  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
130    <organization abbrev="W3C">World Wide Web Consortium</organization>
131    <address>
132      <postal>
133        <street>W3C / ERCIM</street>
134        <street>2004, rte des Lucioles</street>
135        <city>Sophia-Antipolis</city>
136        <region>AM</region>
137        <code>06902</code>
138        <country>France</country>
139      </postal>
140      <email>ylafon@w3.org</email>
141      <uri>http://www.raubacapeu.net/people/yves/</uri>
142    </address>
143  </author>
144
145  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
146    <organization abbrev="greenbytes">greenbytes GmbH</organization>
147    <address>
148      <postal>
149        <street>Hafenweg 16</street>
150        <city>Muenster</city><region>NW</region><code>48155</code>
151        <country>Germany</country>
152      </postal>
153      <phone>+49 251 2807760</phone>   
154      <facsimile>+49 251 2807761</facsimile>   
155      <email>julian.reschke@greenbytes.de</email>       
156      <uri>http://greenbytes.de/tech/webdav/</uri>     
157    </address>
158  </author>
159
160  <date month="February" year="2008" day="24"/>
161
162<abstract>
163<t>
164   The Hypertext Transfer Protocol (HTTP) is an application-level
165   protocol for distributed, collaborative, hypermedia information
166   systems. HTTP has been in use by the World Wide Web global information
167   initiative since 1990. This document is Part 6 of the seven-part specification
168   that defines the protocol referred to as "HTTP/1.1" and, taken together,
169   obsoletes RFC 2616.  Part 6 defines requirements on HTTP caches
170   and the associated header fields that control cache behavior or indicate
171   cacheable response messages.
172</t>
173</abstract>
174
175<note title="Editorial Note (To be removed by RFC Editor)">
176  <t>
177    Discussion of this draft should take place on the HTTPBIS working group
178    mailing list (ietf-http-wg@w3.org). The current issues list is
179    at <eref target="http://www.tools.ietf.org/wg/httpbis/trac/report/11"/>
180    and related documents (including fancy diffs) can be found at
181    <eref target="http://www.tools.ietf.org/wg/httpbis/"/>.
182  </t>
183  <t>
184    This draft incorporates those issue resolutions that were either
185    collected in the original RFC2616 errata list (<eref target="http://purl.org/NET/http-errata"/>),
186    or which were agreed upon on the mailing list between October 2006 and
187    November 2007 (as published in "draft-lafon-rfc2616bis-03").
188  </t>
189</note>
190</front>
191<middle>
192<section title="Introduction" anchor="caching">
193<t>
194   HTTP is typically used for distributed information systems, where
195   performance can be improved by the use of response caches, and includes
196   a number of elements intended to make caching work as well as possible.
197   Because these elements interact with each other, it is useful to describe
198   the caching design of HTTP separately.  This document defines aspects of
199   HTTP/1.1 related to caching and reusing response messages.
200</t>
201
202<section title="Purpose" anchor="intro.purpose">
203<iref item="cache"/>
204<t>
205   An HTTP cache is a local store of response messages
206   and the subsystem that controls its message storage, retrieval, and
207   deletion. A cache stores cacheable responses in order to reduce the
208   response time and network bandwidth consumption on future, equivalent
209   requests. Any client or server may include a cache, though a cache
210   cannot be used by a server that is acting as a tunnel.
211</t>
212<t>
213   Caching would be useless if it did not significantly improve
214   performance. The goal of caching in HTTP/1.1 is to reuse a prior response
215   message to satisfy a current request.  In some cases, the existing response
216   can be reused without the need for a network request, reducing latency and
217   network round-trips; we use an "expiration" mechanism for this purpose
218   (see <xref target="expiration.model"/>).  Even when a new request is required,
219   it is often possible to reuse all or parts of the payload of a prior response
220   to satisfy the request, thereby reducing network bandwidth usage; we use a
221   "validation" mechanism for this purpose (see <xref target="validation.model"/>).
222</t>
223<iref item="semantically transparent"/>
224<t>
225   A cache behaves in a "semantically transparent" manner, with
226   respect to a particular response, when its use affects neither the
227   requesting client nor the origin server, except to improve
228   performance. When a cache is semantically transparent, the client
229   receives exactly the same response status and payload
230   that it would have received had its request been handled directly
231   by the origin server.
232</t>
233<t>
234   In an ideal world, all interactions with an HTTP cache would be
235   semantically transparent.  However, for some resources, semantic
236   transparency is not always necessary and can be effectively traded
237   for the sake of bandwidth scaling, disconnected operation, and
238   high availability.  HTTP/1.1 allows origin servers, caches,
239   and clients to explicitly reduce transparency when necessary.
240   However, because non-transparent operation may confuse non-expert
241   users and might be incompatible with certain server applications
242   (such as those for ordering merchandise), the protocol requires that
243   transparency be relaxed
244  <list style="symbols">
245     <t>only by an explicit protocol-level request when relaxed by
246        client or origin server</t>
247
248     <t>only with an explicit warning to the end user when relaxed by
249        cache or client</t>
250  </list>
251</t>
252<t>
253   Therefore, HTTP/1.1 provides these important elements:
254  <list style="numbers">
255      <t>Protocol features that provide full semantic transparency when
256         this is required by all parties.</t>
257
258      <t>Protocol features that allow an origin server or user agent to
259         explicitly request and control non-transparent operation.</t>
260
261      <t>Protocol features that allow a cache to attach warnings to
262         responses that do not preserve the requested approximation of
263         semantic transparency.</t>
264  </list>
265</t>
266<t>
267   A basic principle is that it must be possible for the clients to
268   detect any potential relaxation of semantic transparency.
269  <list><t>
270      Note: The server, cache, or client implementor might be faced with
271      design decisions not explicitly discussed in this specification.
272      If a decision might affect semantic transparency, the implementor
273      ought to err on the side of maintaining transparency unless a
274      careful and complete analysis shows significant benefits in
275      breaking transparency.
276    </t></list>
277</t>
278</section>
279
280<section title="Terminology" anchor="intro.terminology">
281<t>
282   This specification uses a number of terms to refer to the roles
283   played by participants in, and objects of, HTTP caching.
284</t>
285<t>
286  <iref item="cacheable"/>
287  cacheable
288  <list>
289    <t>
290      A response is cacheable if a cache is allowed to store a copy of
291      the response message for use in answering subsequent requests.
292      Even when a response is cacheable, there may
293      be additional constraints on whether a cache can use the cached
294      copy for a particular request.
295    </t>
296  </list>
297</t>
298<t>
299  <iref item="first-hand"/>
300  first-hand
301  <list>
302    <t>
303      A response is first-hand if it comes directly and without
304      unnecessary delay from the origin server, perhaps via one or more
305      proxies. A response is also first-hand if its validity has just
306      been checked directly with the origin server.
307    </t>
308  </list>
309</t>
310<t>
311  <iref item="explicit expiration time"/>
312  explicit expiration time
313  <list>
314    <t>
315      The time at which the origin server intends that an entity should
316      no longer be returned by a cache without further validation.
317    </t>
318  </list>
319</t>
320<t>
321  <iref item="heuristic expiration time"/>
322  heuristic expiration time
323  <list>
324    <t>
325      An expiration time assigned by a cache when no explicit expiration
326      time is available.
327    </t>
328  </list>
329</t>
330<t>
331  <iref item="age"/>
332  age
333  <list>
334    <t>
335      The age of a response is the time since it was sent by, or
336      successfully validated with, the origin server.
337    </t>
338  </list>
339</t>
340<t>
341  <iref item="freshness lifetime"/>
342  freshness lifetime
343  <list>
344    <t>
345      The length of time between the generation of a response and its
346      expiration time.
347    </t>
348  </list>
349</t>
350<t>
351  <iref item="fresh"/>
352  fresh
353  <list>
354    <t>
355      A response is fresh if its age has not yet exceeded its freshness
356      lifetime.
357    </t>
358  </list>
359</t>
360<t>
361  <iref item="stale"/>
362  stale
363  <list>
364    <t>
365      A response is stale if its age has passed its freshness lifetime.
366    </t>
367  </list>
368</t>
369<t>
370  <iref item="validator"/>
371  validator
372  <list>
373    <t>
374      A protocol element (e.g., an entity tag or a Last-Modified time)
375      that is used to find out whether a cache entry is an equivalent
376      copy of an entity.
377    </t>
378  </list>
379</t>
380</section>
381
382<section title="Requirements" anchor="intro.requirements">
383<t>
384   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
385   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
386   document are to be interpreted as described in <xref target="RFC2119"/>.
387</t>
388<t>
389   An implementation is not compliant if it fails to satisfy one or more
390   of the MUST or REQUIRED level requirements for the protocols it
391   implements. An implementation that satisfies all the MUST or REQUIRED
392   level and all the SHOULD level requirements for its protocols is said
393   to be "unconditionally compliant"; one that satisfies all the MUST
394   level requirements but not all the SHOULD level requirements for its
395   protocols is said to be "conditionally compliant."
396</t>
397</section>
398</section>
399
400
401<section title="Notational Conventions and Generic Grammar" anchor="notation">
402<t>
403  This specification uses the ABNF syntax defined in Section 2.1 of <xref target="Part1"/> and
404  the core rules defined in Section 2.2 of <xref target="Part1"/>:
405  <cref anchor="abnf.dep">ABNF syntax and basic rules will be adopted from RFC 5234, see
406  &lt;http://tools.ietf.org/wg/httpbis/trac/ticket/36&gt;.</cref>
407</t>
408<figure><artwork type="abnf2616"><![CDATA[
409  DIGIT         = <DIGIT, defined in [Part1], Section 2.2>
410  DQUOTE        = <DQUOTE, defined in [Part1], Section 2.2>
411  SP            = <SP, defined in [Part1], Section 2.2>
412]]></artwork></figure>
413<figure><artwork type="abnf2616"><![CDATA[
414  quoted-string = <quoted-string, defined in [Part1], Section 2.2>
415  token         = <token, defined in [Part1], Section 2.2>
416]]></artwork></figure>
417<t anchor="abnf.dependencies">
418  The ABNF rules below are defined in other parts:
419</t>
420<figure><!--Part1--><artwork type="abnf2616"><![CDATA[
421  field-name    = <field-name, defined in [Part1], Section 4.2>
422  HTTP-date     = <HTTP-date, defined in [Part1], Section 3.3.1>
423  port          = <port, defined in [Part1], Section 3.2.1>
424  pseudonym     = <pseudonym, defined in [Part1], Section 8.9>
425  uri-host      = <uri-host, defined in [Part1], Section 3.2.1>
426]]></artwork></figure>
427</section>
428
429<section title="Overview" anchor="caching.overview">
430<section title="Cache Correctness" anchor="cache.correctness">
431<t>
432   A correct cache MUST respond to a request with the most up-to-date
433   response held by the cache that is appropriate to the request (see
434   Sections <xref target="disambiguating.expiration.values" format="counter"/>,
435   <xref target="disambiguating.multiple.responses" format="counter"/>,
436   and <xref target="cache.replacement" format="counter"/>) which meets one of the following
437   conditions:
438  <list style="numbers">
439      <t>It has been checked for equivalence with what the origin server
440         would have returned by revalidating the response with the
441         origin server (<xref target="validation.model"/>);</t>
442
443      <t>It is "fresh enough" (see <xref target="expiration.model"/>). In the default case,
444         this means it meets the least restrictive freshness requirement
445         of the client, origin server, and cache (see <xref target="header.cache-control"/>); if
446         the origin server so specifies, it is the freshness requirement
447         of the origin server alone.
448
449         If a stored response is not "fresh enough" by the most
450         restrictive freshness requirement of both the client and the
451         origin server, in carefully considered circumstances the cache
452         MAY still return the response with the appropriate Warning
453         header (see Sections <xref target="exceptions.to.the.rules.and.warnings" format="counter"/>
454         and <xref target="header.warning" format="counter"/>), unless such a response
455         is prohibited (e.g., by a "no-store" cache-directive, or by a
456         "no-cache" cache-request-directive; see <xref target="header.cache-control"/>).</t>
457
458      <t>It is an appropriate 304 (Not Modified), 305 (Use Proxy),
459         or error (4xx or 5xx) response message.</t>
460  </list>
461</t>
462<t>
463   If the cache can not communicate with the origin server, then a
464   correct cache SHOULD respond as above if the response can be
465   correctly served from the cache; if not it MUST return an error or
466   warning indicating that there was a communication failure.
467</t>
468<t>
469   If a cache receives a response (either an entire response, or a 304
470   (Not Modified) response) that it would normally forward to the
471   requesting client, and the received response is no longer fresh, the
472   cache SHOULD forward it to the requesting client without adding a new
473   Warning (but without removing any existing Warning headers). A cache
474   SHOULD NOT  attempt to revalidate a response simply because that
475   response became stale in transit; this might lead to an infinite
476   loop. A user agent that receives a stale response without a Warning
477   MAY display a warning indication to the user.
478</t>
479</section>
480
481<section title="Warnings" anchor="warnings">
482<t>
483   Whenever a cache returns a response that is neither first-hand nor
484   "fresh enough" (in the sense of condition 2 in <xref target="cache.correctness"/>), it
485   MUST attach a warning to that effect, using a Warning general-header.
486   The Warning header and the currently defined warnings are described
487   in <xref target="header.warning"/>. The warning allows clients to take appropriate
488   action.
489</t>
490<t>
491   Warnings MAY be used for other purposes, both cache-related and
492   otherwise. The use of a warning, rather than an error status code,
493   distinguish these responses from true failures.
494</t>
495<t>
496   Warnings are assigned three digit warn-codes. The first digit
497   indicates whether the Warning MUST or MUST NOT be deleted from a
498   stored cache entry after a successful revalidation:
499</t>
500<t>
501  <list style="hanging">
502    <t hangText="1xx">Warnings that describe the freshness or revalidation status of
503     the response, and so MUST be deleted after a successful
504     revalidation. 1xx warn-codes MAY be generated by a cache only when
505     validating a cached entry. It MUST NOT be generated by clients.</t>
506
507    <t hangText="2xx">Warnings that describe some aspect of the entity body or entity
508     headers that is not rectified by a revalidation (for example, a
509     lossy compression of the entity bodies) and which MUST NOT be
510     deleted after a successful revalidation.</t>
511    </list>
512</t>
513<t>
514   See <xref target="header.warning"/> for the definitions of the codes themselves.
515</t>
516<t>
517   HTTP/1.0 caches will cache all Warnings in responses, without
518   deleting the ones in the first category. Warnings in responses that
519   are passed to HTTP/1.0 caches carry an extra warning-date field,
520   which prevents a future HTTP/1.1 recipient from believing an
521   erroneously cached Warning.
522</t>
523<t>
524   Warnings also carry a warning text. The text MAY be in any
525   appropriate natural language (perhaps based on the client's Accept
526   headers), and include an OPTIONAL indication of what character set is
527   used.
528</t>
529<t>
530   Multiple warnings MAY be attached to a response (either by the origin
531   server or by a cache), including multiple warnings with the same code
532   number. For example, a server might provide the same warning with
533   texts in both English and Basque.
534</t>
535<t>
536   When multiple warnings are attached to a response, it might not be
537   practical or reasonable to display all of them to the user. This
538   version of HTTP does not specify strict priority rules for deciding
539   which warnings to display and in what order, but does suggest some
540   heuristics.
541</t>
542</section>
543
544<section title="Cache-control Mechanisms" anchor="cache-control.mechanisms">
545<t>
546   The basic cache mechanisms in HTTP/1.1 (server-specified expiration
547   times and validators) are implicit directives to caches. In some
548   cases, a server or client might need to provide explicit directives
549   to the HTTP caches. We use the Cache-Control header for this purpose.
550</t>
551<t>
552   The Cache-Control header allows a client or server to transmit a
553   variety of directives in either requests or responses. These
554   directives typically override the default caching algorithms. As a
555   general rule, if there is any apparent conflict between header
556   values, the most restrictive interpretation is applied (that is, the
557   one that is most likely to preserve semantic transparency). However,
558   in some cases, cache-control directives are explicitly specified as
559   weakening the approximation of semantic transparency (for example,
560   "max-stale" or "public").
561</t>
562<t>
563   The cache-control directives are described in detail in <xref target="header.cache-control"/>.
564</t>
565</section>
566
567<section title="Explicit User Agent Warnings" anchor="explicit.ua.warnings">
568<t>
569   Many user agents make it possible for users to override the basic
570   caching mechanisms. For example, the user agent might allow the user
571   to specify that cached entities (even explicitly stale ones) are
572   never validated. Or the user agent might habitually add "Cache-Control:
573   max-stale=3600" to every request. The user agent SHOULD NOT
574   default to either non-transparent behavior, or behavior that results
575   in abnormally ineffective caching, but MAY be explicitly configured
576   to do so by an explicit action of the user.
577</t>
578<t>
579   If the user has overridden the basic caching mechanisms, the user
580   agent SHOULD explicitly indicate to the user whenever this results in
581   the display of information that might not meet the server's
582   transparency requirements (in particular, if the displayed entity is
583   known to be stale). Since the protocol normally allows the user agent
584   to determine if responses are stale or not, this indication need only
585   be displayed when this actually happens. The indication need not be a
586   dialog box; it could be an icon (for example, a picture of a rotting
587   fish) or some other indicator.
588</t>
589<t>
590   If the user has overridden the caching mechanisms in a way that would
591   abnormally reduce the effectiveness of caches, the user agent SHOULD
592   continually indicate this state to the user (for example, by a
593   display of a picture of currency in flames) so that the user does not
594   inadvertently consume excess resources or suffer from excessive
595   latency.
596</t>
597</section>
598
599<section title="Exceptions to the Rules and Warnings" anchor="exceptions.to.the.rules.and.warnings">
600<t>
601   In some cases, the operator of a cache MAY choose to configure it to
602   return stale responses even when not requested by clients. This
603   decision ought not be made lightly, but may be necessary for reasons
604   of availability or performance, especially when the cache is poorly
605   connected to the origin server. Whenever a cache returns a stale
606   response, it MUST mark it as such (using a Warning header) enabling
607   the client software to alert the user that there might be a potential
608   problem.
609</t>
610<t>
611   It also allows the user agent to take steps to obtain a first-hand or
612   fresh response. For this reason, a cache SHOULD NOT  return a stale
613   response if the client explicitly requests a first-hand or fresh one,
614   unless it is impossible to comply for technical or policy reasons.
615</t>
616</section>
617
618<section title="Client-controlled Behavior" anchor="client-controlled.behavior">
619<t>
620   While the origin server (and to a lesser extent, intermediate caches,
621   by their contribution to the age of a response) are the primary
622   source of expiration information, in some cases the client might need
623   to control a cache's decision about whether to return a cached
624   response without validating it. Clients do this using several
625   directives of the Cache-Control header.
626</t>
627<t>
628   A client's request MAY specify the maximum age it is willing to
629   accept of an unvalidated response; specifying a value of zero forces
630   the cache(s) to revalidate all responses. A client MAY also specify
631   the minimum time remaining before a response expires. Both of these
632   options increase constraints on the behavior of caches, and so cannot
633   further relax the cache's approximation of semantic transparency.
634</t>
635<t>
636   A client MAY also specify that it will accept stale responses, up to
637   some maximum amount of staleness. This loosens the constraints on the
638   caches, and so might violate the origin server's specified
639   constraints on semantic transparency, but might be necessary to
640   support disconnected operation, or high availability in the face of
641   poor connectivity.
642</t>
643</section>
644</section>
645
646<section title="Expiration Model" anchor="expiration.model">
647
648<section title="Server-Specified Expiration" anchor="server-specified.expiration">
649<t>
650   HTTP caching works best when caches can entirely avoid making
651   requests to the origin server. The primary mechanism for avoiding
652   requests is for an origin server to provide an explicit expiration
653   time in the future, indicating that a response MAY be used to satisfy
654   subsequent requests. In other words, a cache can return a fresh
655   response without first contacting the server.
656</t>
657<t>
658   Our expectation is that servers will assign future explicit
659   expiration times to responses in the belief that the entity is not
660   likely to change, in a semantically significant way, before the
661   expiration time is reached. This normally preserves semantic
662   transparency, as long as the server's expiration times are carefully
663   chosen.
664</t>
665<t>
666   The expiration mechanism applies only to responses taken from a cache
667   and not to first-hand responses forwarded immediately to the
668   requesting client.
669</t>
670<t>
671   If an origin server wishes to force a semantically transparent cache
672   to validate every request, it MAY assign an explicit expiration time
673   in the past. This means that the response is always stale, and so the
674   cache SHOULD validate it before using it for subsequent requests. See
675   <xref target="cache.revalidation.and.reload.controls"/> for a more restrictive way to force revalidation.
676</t>
677<t>
678   If an origin server wishes to force any HTTP/1.1 cache, no matter how
679   it is configured, to validate every request, it SHOULD use the "must-revalidate"
680   cache-control directive (see <xref target="header.cache-control"/>).
681</t>
682<t>
683   Servers specify explicit expiration times using either the Expires
684   header, or the max-age directive of the Cache-Control header.
685</t>
686<t>
687   An expiration time cannot be used to force a user agent to refresh
688   its display or reload a resource; its semantics apply only to caching
689   mechanisms, and such mechanisms need only check a resource's
690   expiration status when a new request for that resource is initiated.
691   See <xref target="history.lists"/> for an explanation of the difference between caches
692   and history mechanisms.
693</t>
694</section>
695
696<section title="Heuristic Expiration" anchor="heuristic.expiration">
697<t>
698   Since origin servers do not always provide explicit expiration times,
699   HTTP caches typically assign heuristic expiration times, employing
700   algorithms that use other header values (such as the Last-Modified
701   time) to estimate a plausible expiration time. The HTTP/1.1
702   specification does not provide specific algorithms, but does impose
703   worst-case constraints on their results. Since heuristic expiration
704   times might compromise semantic transparency, they ought to be used
705   cautiously, and we encourage origin servers to provide explicit
706   expiration times as much as possible.
707</t>
708</section>
709
710<section title="Age Calculations" anchor="age.calculations">
711<t>
712   In order to know if a cached entry is fresh, a cache needs to know if
713   its age exceeds its freshness lifetime. We discuss how to calculate
714   the latter in <xref target="expiration.calculations"/>; this section describes how to calculate
715   the age of a response or cache entry.
716</t>
717<t>
718   In this discussion, we use the term "now" to mean "the current value
719   of the clock at the host performing the calculation." Hosts that use
720   HTTP, but especially hosts running origin servers and caches, SHOULD
721   use NTP <xref target="RFC1305"/> or some similar protocol to synchronize their clocks to
722   a globally accurate time standard.
723</t>
724<t>
725   HTTP/1.1 requires origin servers to send a Date header, if possible,
726   with every response, giving the time at which the response was
727   generated (see Section 8.3 of <xref target="Part1"/>). We use the term "date_value" to denote
728   the value of the Date header, in a form appropriate for arithmetic
729   operations.
730</t>
731<t>
732   HTTP/1.1 uses the Age response-header to convey the estimated age of
733   the response message when obtained from a cache. The Age field value
734   is the cache's estimate of the amount of time since the response was
735   generated or revalidated by the origin server.
736</t>
737<t>
738   In essence, the Age value is the sum of the time that the response
739   has been resident in each of the caches along the path from the
740   origin server, plus the amount of time it has been in transit along
741   network paths.
742</t>
743<t>
744   We use the term "age_value" to denote the value of the Age header, in
745   a form appropriate for arithmetic operations.
746</t>
747<t>
748   A response's age can be calculated in two entirely independent ways:
749  <list style="numbers">
750      <t>now minus date_value, if the local clock is reasonably well
751         synchronized to the origin server's clock. If the result is
752         negative, the result is replaced by zero.</t>
753
754      <t>age_value, if all of the caches along the response path
755         implement HTTP/1.1.</t>
756  </list>
757</t>
758<t>
759   Given that we have two independent ways to compute the age of a
760   response when it is received, we can combine these as
761</t>
762<figure><artwork type="code"><![CDATA[
763    corrected_received_age = max(now - date_value, age_value)
764]]></artwork></figure>
765<t>
766   and as long as we have either nearly synchronized clocks or all-HTTP/1.1
767   paths, one gets a reliable (conservative) result.
768</t>
769<t>
770   Because of network-imposed delays, some significant interval might
771   pass between the time that a server generates a response and the time
772   it is received at the next outbound cache or client. If uncorrected,
773   this delay could result in improperly low ages.
774</t>
775<t>
776   Because the request that resulted in the returned Age value must have
777   been initiated prior to that Age value's generation, we can correct
778   for delays imposed by the network by recording the time at which the
779   request was initiated. Then, when an Age value is received, it MUST
780   be interpreted relative to the time the request was initiated, not
781   the time that the response was received. This algorithm results in
782   conservative behavior no matter how much delay is experienced. So, we
783   compute:
784</t>
785<figure><artwork type="code"><![CDATA[
786   corrected_initial_age = corrected_received_age
787                         + (now - request_time)
788]]></artwork></figure>
789<t>
790   where "request_time" is the time (according to the local clock) when
791   the request that elicited this response was sent.
792</t>
793<t>
794   Summary of age calculation algorithm, when a cache receives a
795   response:
796</t>
797<figure><artwork type="code"><![CDATA[
798   /*
799    * age_value
800    *      is the value of Age: header received by the cache with
801    *              this response.
802    * date_value
803    *      is the value of the origin server's Date: header
804    * request_time
805    *      is the (local) time when the cache made the request
806    *              that resulted in this cached response
807    * response_time
808    *      is the (local) time when the cache received the
809    *              response
810    * now
811    *      is the current (local) time
812    */
813
814   apparent_age = max(0, response_time - date_value);
815   corrected_received_age = max(apparent_age, age_value);
816   response_delay = response_time - request_time;
817   corrected_initial_age = corrected_received_age + response_delay;
818   resident_time = now - response_time;
819   current_age   = corrected_initial_age + resident_time;
820]]></artwork></figure>
821<t>
822   The current_age of a cache entry is calculated by adding the amount
823   of time (in seconds) since the cache entry was last validated by the
824   origin server to the corrected_initial_age. When a response is
825   generated from a cache entry, the cache MUST include a single Age
826   header field in the response with a value equal to the cache entry's
827   current_age.
828</t>
829<t>
830   The presence of an Age header field in a response implies that a
831   response is not first-hand. However, the converse is not true, since
832   the lack of an Age header field in a response does not imply that the
833   response is first-hand unless all caches along the request path are
834   compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
835   the Age header field).
836</t>
837</section>
838
839<section title="Expiration Calculations" anchor="expiration.calculations">
840<t>
841   In order to decide whether a response is fresh or stale, we need to
842   compare its freshness lifetime to its age. The age is calculated as
843   described in <xref target="age.calculations"/>; this section describes how to calculate
844   the freshness lifetime, and to determine if a response has expired.
845   In the discussion below, the values can be represented in any form
846   appropriate for arithmetic operations.
847</t>
848<t>
849   We use the term "expires_value" to denote the value of the Expires
850   header. We use the term "max_age_value" to denote an appropriate
851   value of the number of seconds carried by the "max-age" directive of
852   the Cache-Control header in a response (see <xref target="modifications.of.the.basic.expiration.mechanism"/>).
853</t>
854<t>
855   The max-age directive takes priority over Expires, so if max-age is
856   present in a response, the calculation is simply:
857</t>
858<figure><artwork type="code"><![CDATA[
859   freshness_lifetime = max_age_value
860]]></artwork></figure>
861<t>
862   Otherwise, if Expires is present in the response, the calculation is:
863</t>
864<figure><artwork type="code"><![CDATA[
865   freshness_lifetime = expires_value - date_value
866]]></artwork></figure>
867<t>
868   Note that neither of these calculations is vulnerable to clock skew,
869   since all of the information comes from the origin server.
870</t>
871<t>
872   If none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage
873   (see <xref target="modifications.of.the.basic.expiration.mechanism"/>) appears in the response, and the response
874   does not include other restrictions on caching, the cache MAY compute
875   a freshness lifetime using a heuristic. The cache MUST attach Warning
876   113 to any response whose age is more than 24 hours if such warning
877   has not already been added.
878</t>
879<t>
880   Also, if the response does have a Last-Modified time, the heuristic
881   expiration value SHOULD be no more than some fraction of the interval
882   since that time. A typical setting of this fraction might be 10%.
883</t>
884<t>
885   The calculation to determine if a response has expired is quite
886   simple:
887</t>
888<figure><artwork type="code"><![CDATA[
889   response_is_fresh = (freshness_lifetime > current_age)
890]]></artwork></figure>
891</section>
892
893<section title="Disambiguating Expiration Values" anchor="disambiguating.expiration.values">
894<t>
895   Because expiration values are assigned optimistically, it is possible
896   for two caches to contain fresh values for the same resource that are
897   different.
898</t>
899<t>
900   If a client performing a retrieval receives a non-first-hand response
901   for a request that was already fresh in its own cache, and the Date
902   header in its existing cache entry is newer than the Date on the new
903   response, then the client MAY ignore the response. If so, it MAY
904   retry the request with a "Cache-Control: max-age=0" directive (see
905   <xref target="header.cache-control"/>), to force a check with the origin server.
906</t>
907<t>
908   If a cache has two fresh responses for the same representation with
909   different validators, it MUST use the one with the more recent Date
910   header. This situation might arise because the cache is pooling
911   responses from other caches, or because a client has asked for a
912   reload or a revalidation of an apparently fresh cache entry.
913</t>
914</section>
915
916<section title="Disambiguating Multiple Responses" anchor="disambiguating.multiple.responses">
917<t>
918   Because a client might be receiving responses via multiple paths, so
919   that some responses flow through one set of caches and other
920   responses flow through a different set of caches, a client might
921   receive responses in an order different from that in which the origin
922   server sent them. We would like the client to use the most recently
923   generated response, even if older responses are still apparently
924   fresh.
925</t>
926<t>
927   Neither the entity tag nor the expiration value can impose an
928   ordering on responses, since it is possible that a later response
929   intentionally carries an earlier expiration time. The Date values are
930   ordered to a granularity of one second.
931</t>
932<t>
933   When a client tries to revalidate a cache entry, and the response it
934   receives contains a Date header that appears to be older than the one
935   for the existing entry, then the client SHOULD repeat the request
936   unconditionally, and include
937</t>
938<figure><artwork type="example"><![CDATA[
939    Cache-Control: max-age=0
940]]></artwork></figure>
941<t>
942   to force any intermediate caches to validate their copies directly
943   with the origin server, or
944</t>
945<figure><artwork type="example"><![CDATA[
946    Cache-Control: no-cache
947]]></artwork></figure>
948<t>
949   to force any intermediate caches to obtain a new copy from the origin
950   server.
951</t>
952<t>
953   If the Date values are equal, then the client MAY use either response
954   (or MAY, if it is being extremely prudent, request a new response).
955   Servers MUST NOT depend on clients being able to choose
956   deterministically between responses generated during the same second,
957   if their expiration times overlap.
958</t>
959</section>
960</section>
961
962<section title="Validation Model" anchor="validation.model">
963<t>
964   When a cache has a stale entry that it would like to use as a
965   response to a client's request, it first has to check with the origin
966   server (or possibly an intermediate cache with a fresh response) to
967   see if its cached entry is still usable. We call this "validating"
968   the cache entry.
969</t>
970<t>
971   HTTP's conditional request mechanism, defined in <xref target="Part4"/>, is
972   used to avoid retransmitting the response payload when the cached entry
973   is valid.  When a cached response includes one or more "cache validators,"
974   such as the field values of an ETag or Last-Modified header field, then
975   a validating GET request SHOULD be made conditional to those field values.
976   The server checks the conditional request's validator against the current
977   state of the requested resource and, if they match, the server responds
978   with a 304 (Not Modified) status code to indicate that the cached response
979   can be refreshed and reused without retransmitting the response payload.
980   If the validator does not match the current state of the requested
981   resource, then the server returns a full response, including payload,
982   so that the request can be satisfied and the cache entry supplanted
983   without the need for an additional network round-trip.
984</t>
985</section>
986
987<section title="Response Cacheability" anchor="response.cacheability">
988<t>
989   Unless specifically constrained by a cache-control (<xref target="header.cache-control"/>)
990   directive, a caching system MAY always store a successful response
991   (see <xref target="errors.or.incomplete.response.cache.behavior"/>) as a cache entry, MAY return it without validation
992   if it is fresh, and MAY return it after successful validation. If
993   there is neither a cache validator nor an explicit expiration time
994   associated with a response, we do not expect it to be cached, but
995   certain caches MAY violate this expectation (for example, when little
996   or no network connectivity is available). A client can usually detect
997   that such a response was taken from a cache by comparing the Date
998   header to the current time.
999  <list><t>
1000      Note: some HTTP/1.0 caches are known to violate this expectation
1001      without providing any Warning.
1002  </t></list>
1003</t>
1004<t>
1005   However, in some cases it might be inappropriate for a cache to
1006   retain an entity, or to return it in response to a subsequent
1007   request. This might be because absolute semantic transparency is
1008   deemed necessary by the service author, or because of security or
1009   privacy considerations. Certain cache-control directives are
1010   therefore provided so that the server can indicate that certain
1011   resource entities, or portions thereof, are not to be cached
1012   regardless of other considerations.
1013</t>
1014<t>
1015   Note that Section 4.1 of <xref target="Part7"/> normally prevents a shared cache from saving
1016   and returning a response to a previous request if that request
1017   included an Authorization header.
1018</t>
1019<t>
1020   A response received with a status code of 200, 203, 206, 300, 301 or
1021   410 MAY be stored by a cache and used in reply to a subsequent
1022   request, subject to the expiration mechanism, unless a cache-control
1023   directive prohibits caching. However, a cache that does not support
1024   the Range and Content-Range headers MUST NOT cache 206 (Partial
1025   Content) responses.
1026</t>
1027<t>
1028   A response received with any other status code (e.g. status codes 302
1029   and 307) MUST NOT be returned in a reply to a subsequent request
1030   unless there are cache-control directives or another header(s) that
1031   explicitly allow it. For example, these include the following: an
1032   Expires header (<xref target="header.expires"/>); a "max-age", "s-maxage",  "must-revalidate",
1033   "proxy-revalidate", "public" or "private" cache-control
1034   directive (<xref target="header.cache-control"/>).
1035</t>
1036</section>
1037
1038<section title="Constructing Responses From Caches" anchor="constructing.responses.from.caches">
1039<t>
1040   The purpose of an HTTP cache is to store information received in
1041   response to requests for use in responding to future requests. In
1042   many cases, a cache simply returns the appropriate parts of a
1043   response to the requester. However, if the cache holds a cache entry
1044   based on a previous response, it might have to combine parts of a new
1045   response with what is held in the cache entry.
1046</t>
1047
1048<section title="End-to-end and Hop-by-hop Headers" anchor="end-to-end.and.hop-by-hop.headers">
1049<t>
1050   For the purpose of defining the behavior of caches and non-caching
1051   proxies, we divide HTTP headers into two categories:
1052  <list style="symbols">
1053      <t>End-to-end headers, which are  transmitted to the ultimate
1054        recipient of a request or response. End-to-end headers in
1055        responses MUST be stored as part of a cache entry and MUST be
1056        transmitted in any response formed from a cache entry.</t>
1057
1058      <t>Hop-by-hop headers, which are meaningful only for a single
1059        transport-level connection, and are not stored by caches or
1060        forwarded by proxies.</t>
1061  </list>
1062</t>
1063<t>
1064   The following HTTP/1.1 headers are hop-by-hop headers:
1065  <list style="symbols">
1066      <t>Connection</t>
1067      <t>Keep-Alive</t>
1068      <t>Proxy-Authenticate</t>
1069      <t>Proxy-Authorization</t>
1070      <t>TE</t>
1071      <t>Trailer</t>
1072      <t>Transfer-Encoding</t>
1073      <t>Upgrade</t>
1074  </list>
1075</t>
1076<t>
1077   All other headers defined by HTTP/1.1 are end-to-end headers.
1078</t>
1079<t>
1080   Other hop-by-hop headers MUST be listed in a Connection header
1081   (Section 8.1 of <xref target="Part1"/>).
1082</t>
1083</section>
1084
1085<section title="Non-modifiable Headers" anchor="non-modifiable.headers">
1086<t>
1087   Some features of HTTP/1.1, such as Digest
1088   Authentication, depend on the value of certain end-to-end headers. A
1089   transparent proxy SHOULD NOT  modify an end-to-end header unless the
1090   definition of that header requires or specifically allows that.
1091</t>
1092<t>
1093   A transparent proxy MUST NOT modify any of the following fields in a
1094   request or response, and it MUST NOT add any of these fields if not
1095   already present:
1096  <list style="symbols">
1097      <t>Content-Location</t>
1098      <t>Content-MD5</t>
1099      <t>ETag</t>
1100      <t>Last-Modified</t>
1101  </list>
1102</t>
1103<t>
1104   A transparent proxy MUST NOT modify any of the following fields in a
1105   response:
1106  <list style="symbols">
1107    <t>Expires</t>
1108  </list>
1109</t>
1110<t>
1111   but it MAY add any of these fields if not already present. If an
1112   Expires header is added, it MUST be given a field-value identical to
1113   that of the Date header in that response.
1114</t>
1115<t>
1116   A  proxy MUST NOT modify or add any of the following fields in a
1117   message that contains the no-transform cache-control directive, or in
1118   any request:
1119  <list style="symbols">
1120    <t>Content-Encoding</t>
1121    <t>Content-Range</t>
1122    <t>Content-Type</t>
1123  </list>
1124</t>
1125<t>
1126   A non-transparent proxy MAY modify or add these fields to a message
1127   that does not include no-transform, but if it does so, it MUST add a
1128   Warning 214 (Transformation applied) if one does not already appear
1129   in the message (see <xref target="header.warning"/>).
1130  <list><t>
1131      Warning: unnecessary modification of end-to-end headers might
1132      cause authentication failures if stronger authentication
1133      mechanisms are introduced in later versions of HTTP. Such
1134      authentication mechanisms MAY rely on the values of header fields
1135      not listed here.
1136    </t></list>
1137</t>
1138<t>
1139   The Content-Length field of a request or response is added or deleted
1140   according to the rules in Section 4.4 of <xref target="Part1"/>. A transparent proxy MUST
1141   preserve the entity-length (Section 4.2.2 of <xref target="Part3"/>) of the entity-body,
1142   although it MAY change the transfer-length (Section 4.4 of <xref target="Part1"/>).
1143</t>
1144</section>
1145
1146<section title="Combining Headers" anchor="combining.headers">
1147<t>
1148   When a cache makes a validating request to a server, and the server
1149   provides a 304 (Not Modified) response or a 206 (Partial Content)
1150   response, the cache then constructs a response to send to the
1151   requesting client.
1152</t>
1153<t>
1154   If the status code is 304 (Not Modified), the cache uses the entity-body
1155   stored in the cache entry as the entity-body of this outgoing
1156   response. If the status code is 206 (Partial Content) and the ETag or
1157   Last-Modified headers match exactly, the cache MAY combine the
1158   contents stored in the cache entry with the new contents received in
1159   the response and use the result as the entity-body of this outgoing
1160   response, (see Section 5 of <xref target="Part5"/>).
1161</t>
1162<t>
1163   The end-to-end headers stored in the cache entry are used for the
1164   constructed response, except that
1165  <list style="symbols">
1166    <t>any stored Warning headers with warn-code 1xx (see <xref target="header.warning"/>)
1167      MUST be deleted from the cache entry and the forwarded response.</t>
1168    <t>any stored Warning headers with warn-code 2xx MUST be retained
1169        in the cache entry and the forwarded response.</t>
1170    <t>any end-to-end headers provided in the 304 or 206 response MUST
1171        replace the corresponding headers from the cache entry.</t>
1172  </list>
1173</t>
1174<t>
1175   Unless the cache decides to remove the cache entry, it MUST also
1176   replace the end-to-end headers stored with the cache entry with
1177   corresponding headers received in the incoming response, except for
1178   Warning headers as described immediately above. If a header field-name
1179   in the incoming response matches more than one header in the
1180   cache entry, all such old headers MUST be replaced.
1181</t>
1182<t>
1183   In other words, the set of end-to-end headers received in the
1184   incoming response overrides all corresponding end-to-end headers
1185   stored with the cache entry (except for stored Warning headers with
1186   warn-code 1xx, which are deleted even if not overridden).
1187  <list><t>
1188      Note: this rule allows an origin server to use a 304 (Not
1189      Modified) or a 206 (Partial Content) response to update any header
1190      associated with a previous response for the same entity or sub-ranges
1191      thereof, although it might not always be meaningful or
1192      correct to do so. This rule does not allow an origin server to use
1193      a 304 (Not Modified) or a 206 (Partial Content) response to
1194      entirely delete a header that it had provided with a previous
1195      response.
1196  </t></list>
1197</t>
1198</section>
1199
1200</section>
1201
1202<section title="Caching Negotiated Responses" anchor="caching.negotiated.responses">
1203<t>
1204   Use of server-driven content negotiation (Section 5.1 of <xref target="Part3"/>), as indicated
1205   by the presence of a Vary header field in a response, alters the
1206   conditions and procedure by which a cache can use the response for
1207   subsequent requests. See <xref target="header.vary"/> for use of the Vary header
1208   field by servers.
1209</t>
1210<t>
1211   A server SHOULD use the Vary header field to inform a cache of what
1212   request-header fields were used to select among multiple
1213   representations of a cacheable response subject to server-driven
1214   negotiation. The set of header fields named by the Vary field value
1215   is known as the "selecting" request-headers.
1216</t>
1217<t>
1218   When the cache receives a subsequent request whose Request-URI
1219   specifies one or more cache entries including a Vary header field,
1220   the cache MUST NOT use such a cache entry to construct a response to
1221   the new request unless all of the selecting request-headers present
1222   in the new request match the corresponding stored request-headers in
1223   the original request.
1224</t>
1225<t>
1226   The selecting request-headers from two requests are defined to match
1227   if and only if the selecting request-headers in the first request can
1228   be transformed to the selecting request-headers in the second request
1229   by adding or removing linear white space (LWS) at places where this
1230   is allowed by the corresponding BNF, and/or combining multiple
1231   message-header fields with the same field name following the rules
1232   about message headers in Section 4.2 of <xref target="Part1"/>.
1233</t>
1234<t>
1235   A Vary header field-value of "*" always fails to match and subsequent
1236   requests on that resource can only be properly interpreted by the
1237   origin server.
1238</t>
1239<t>
1240   If the selecting request header fields for the cached entry do not
1241   match the selecting request header fields of the new request, then
1242   the cache MUST NOT use a cached entry to satisfy the request unless
1243   it first relays the new request to the origin server in a conditional
1244   request and the server responds with 304 (Not Modified), including an
1245   entity tag or Content-Location that indicates the entity to be used.
1246</t>
1247<t>
1248   If an entity tag was assigned to a cached representation, the
1249   forwarded request SHOULD be conditional and include the entity tags
1250   in an If-None-Match header field from all its cache entries for the
1251   resource. This conveys to the server the set of entities currently
1252   held by the cache, so that if any one of these entities matches the
1253   requested entity, the server can use the ETag header field in its 304
1254   (Not Modified) response to tell the cache which entry is appropriate.
1255   If the entity-tag of the new response matches that of an existing
1256   entry, the new response SHOULD be used to update the header fields of
1257   the existing entry, and the result MUST be returned to the client.
1258</t>
1259<t>
1260   If any of the existing cache entries contains only partial content
1261   for the associated entity, its entity-tag SHOULD NOT  be included in
1262   the If-None-Match header field unless the request is for a range that
1263   would be fully satisfied by that entry.
1264</t>
1265<t>
1266   If a cache receives a successful response whose Content-Location
1267   field matches that of an existing cache entry for the same Request-URI,
1268   whose entity-tag differs from that of the existing entry, and
1269   whose Date is more recent than that of the existing entry, the
1270   existing entry SHOULD NOT  be returned in response to future requests
1271   and SHOULD be deleted from the cache.
1272</t>
1273</section>
1274
1275<section title="Shared and Non-Shared Caches" anchor="shared.and.non-shared.caches">
1276<t>
1277   For reasons of security and privacy, it is necessary to make a
1278   distinction between "shared" and "non-shared" caches. A non-shared
1279   cache is one that is accessible only to a single user. Accessibility
1280   in this case SHOULD be enforced by appropriate security mechanisms.
1281   All other caches are considered to be "shared." Other sections of
1282   this specification place certain constraints on the operation of
1283   shared caches in order to prevent loss of privacy or failure of
1284   access controls.
1285</t>
1286</section>
1287
1288<section title="Errors or Incomplete Response Cache Behavior" anchor="errors.or.incomplete.response.cache.behavior">
1289<t>
1290   A cache that receives an incomplete response (for example, with fewer
1291   bytes of data than specified in a Content-Length header) MAY store
1292   the response. However, the cache MUST treat this as a partial
1293   response. Partial responses MAY be combined as described in Section 5 of <xref target="Part5"/>;
1294   the result might be a full response or might still be
1295   partial. A cache MUST NOT return a partial response to a client
1296   without explicitly marking it as such, using the 206 (Partial
1297   Content) status code. A cache MUST NOT return a partial response
1298   using a status code of 200 (OK).
1299</t>
1300<t>
1301   If a cache receives a 5xx response while attempting to revalidate an
1302   entry, it MAY either forward this response to the requesting client,
1303   or act as if the server failed to respond. In the latter case, it MAY
1304   return a previously received response unless the cached entry
1305   includes the "must-revalidate" cache-control directive (see <xref target="header.cache-control"/>).
1306</t>
1307</section>
1308
1309<section title="Side Effects of GET and HEAD" anchor="side.effects.of.get.and.head">
1310<t>
1311   Unless the origin server explicitly prohibits the caching of their
1312   responses, the application of GET and HEAD methods to any resources
1313   SHOULD NOT  have side effects that would lead to erroneous behavior if
1314   these responses are taken from a cache. They MAY still have side
1315   effects, but a cache is not required to consider such side effects in
1316   its caching decisions. Caches are always expected to observe an
1317   origin server's explicit restrictions on caching.
1318</t>
1319<t>
1320   We note one exception to this rule: since some applications have
1321   traditionally used GET and HEAD requests with URLs containing a query part
1322   to perform operations with significant side
1323   effects, caches MUST NOT treat responses to such URIs as fresh unless
1324   the server provides an explicit expiration time. This specifically
1325   means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
1326   be taken from a cache. See Section 8.1.1 of <xref target="Part2"/> for related information.
1327</t>
1328</section>
1329
1330<section title="Invalidation After Updates or Deletions" anchor="invalidation.after.updates.or.deletions">
1331<t>
1332   The effect of certain methods performed on a resource at the origin
1333   server might cause one or more existing cache entries to become non-transparently
1334   invalid. That is, although they might continue to be
1335   "fresh," they do not accurately reflect what the origin server would
1336   return for a new request on that resource.
1337</t>
1338<t>
1339   There is no way for HTTP to guarantee that all such
1340   cache entries are marked invalid. For example, the request that
1341   caused the change at the origin server might not have gone through
1342   the proxy where a cache entry is stored. However, several rules help
1343   reduce the likelihood of erroneous behavior.
1344</t>
1345<t>
1346   In this section, the phrase "invalidate an entity" means that the
1347   cache will either remove all instances of that entity from its
1348   storage, or will mark these as "invalid" and in need of a mandatory
1349   revalidation before they can be returned in response to a subsequent
1350   request.
1351</t>
1352<t>
1353   Some HTTP methods MUST cause a cache to invalidate an entity. This is
1354   either the entity referred to by the Request-URI, or by the Location
1355   or Content-Location headers (if present). These methods are:
1356  <list style="symbols">
1357      <t>PUT</t>
1358      <t>DELETE</t>
1359      <t>POST</t>
1360  </list>
1361</t> 
1362<t>
1363   An invalidation based
1364   on the URI in a Location or Content-Location header MUST NOT be
1365   performed if the host part of that URI differs from the host part
1366   in the Request-URI. This helps prevent denial of service attacks.
1367</t>
1368<t>
1369   A cache that passes through requests for methods it does not
1370   understand SHOULD invalidate any entities referred to by the
1371   Request-URI.
1372</t>
1373</section>
1374
1375<section title="Write-Through Mandatory" anchor="write-through.mandatory">
1376<t>
1377   All methods that might be expected to cause modifications to the
1378   origin server's resources MUST be written through to the origin
1379   server. This currently includes all methods except for GET and HEAD.
1380   A cache MUST NOT reply to such a request from a client before having
1381   transmitted the request to the inbound server, and having received a
1382   corresponding response from the inbound server. This does not prevent
1383   a proxy cache from sending a 100 (Continue) response before the
1384   inbound server has sent its final reply.
1385</t>
1386<t>
1387   The alternative (known as "write-back" or "copy-back" caching) is not
1388   allowed in HTTP/1.1, due to the difficulty of providing consistent
1389   updates and the problems arising from server, cache, or network
1390   failure prior to write-back.
1391</t>
1392</section>
1393
1394<section title="Cache Replacement" anchor="cache.replacement">
1395<t>
1396   If a new cacheable (see Sections <xref target="what.may.be.stored.by.caches" format="counter"/>,
1397   <xref target="disambiguating.expiration.values" format="counter"/>,
1398   <xref target="disambiguating.multiple.responses" format="counter"/>
1399   and <xref target="errors.or.incomplete.response.cache.behavior" format="counter"/>)
1400   response is received from a resource while any existing responses for
1401   the same resource are cached, the cache SHOULD use the new response
1402   to reply to the current request. It MAY insert it into cache storage
1403   and MAY, if it meets all other requirements, use it to respond to any
1404   future requests that would previously have caused the old response to
1405   be returned. If it inserts the new response into cache storage  the
1406   rules in <xref target="combining.headers"/> apply.
1407  <list><t>
1408      Note: a new response that has an older Date header value than
1409      existing cached responses is not cacheable.
1410  </t></list>
1411</t>
1412</section>
1413
1414<section title="History Lists" anchor="history.lists">
1415<t>
1416   User agents often have history mechanisms, such as "Back" buttons and
1417   history lists, which can be used to redisplay an entity retrieved
1418   earlier in a session.
1419</t>
1420<t>
1421   History mechanisms and caches are different. In particular history
1422   mechanisms SHOULD NOT  try to show a semantically transparent view of
1423   the current state of a resource. Rather, a history mechanism is meant
1424   to show exactly what the user saw at the time when the resource was
1425   retrieved.
1426</t>
1427<t>
1428   By default, an expiration time does not apply to history mechanisms.
1429   If the entity is still in storage, a history mechanism SHOULD display
1430   it even if the entity has expired, unless the user has specifically
1431   configured the agent to refresh expired history documents.
1432</t>
1433<t>
1434   This is not to be construed to prohibit the history mechanism from
1435   telling the user that a view might be stale.
1436  <list><t>
1437      Note: if history list mechanisms unnecessarily prevent users from
1438      viewing stale resources, this will tend to force service authors
1439      to avoid using HTTP expiration controls and cache controls when
1440      they would otherwise like to. Service authors may consider it
1441      important that users not be presented with error messages or
1442      warning messages when they use navigation controls (such as BACK)
1443      to view previously fetched resources. Even though sometimes such
1444      resources ought not be cached, or ought to expire quickly, user
1445      interface considerations may force service authors to resort to
1446      other means of preventing caching (e.g. "once-only" URLs) in order
1447      not to suffer the effects of improperly functioning history
1448      mechanisms.
1449  </t></list>
1450</t>
1451</section>
1452
1453<section title="Header Field Definitions" anchor="header.fields">
1454<t>
1455   This section defines the syntax and semantics of HTTP/1.1 header fields
1456   related to caching.
1457</t>
1458<t>
1459   For entity-header fields, both sender and recipient refer to either the
1460   client or the server, depending on who sends and who receives the entity.
1461</t>
1462
1463<section title="Age" anchor="header.age">
1464  <iref primary="true" item="Age header"/>
1465  <iref primary="true" item="Headers" subitem="Age"/>
1466<t>
1467      The Age response-header field conveys the sender's estimate of the
1468      amount of time since the response (or its revalidation) was
1469      generated at the origin server. A cached response is "fresh" if
1470      its age does not exceed its freshness lifetime. Age values are
1471      calculated as specified in <xref target="age.calculations"/>.
1472</t>
1473<figure><iref primary="true" item="Grammar" subitem="Age"/><iref primary="true" item="Grammar" subitem="age-value"/><artwork type="abnf2616"><![CDATA[
1474  Age = "Age" ":" age-value
1475  age-value = delta-seconds
1476]]></artwork></figure>
1477<t>
1478      Age values are non-negative decimal integers, representing time in
1479      seconds.
1480</t>
1481<figure><iref primary="true" item="Grammar" subitem="delta-seconds"/><artwork type="abnf2616"><![CDATA[
1482  delta-seconds  = 1*DIGIT
1483]]></artwork></figure>
1484<t>
1485      If a cache receives a value larger than the largest positive
1486      integer it can represent, or if any of its age calculations
1487      overflows, it MUST transmit an Age header with a value of
1488      2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
1489      include an Age header field in every response generated from its
1490      own cache. Caches SHOULD use an arithmetic type of at least 31
1491      bits of range.
1492</t>
1493</section>
1494
1495<section title="Cache-Control" anchor="header.cache-control">
1496  <iref primary="true" item="Cache-Control header"/>
1497  <iref primary="true" item="Headers" subitem="Cache-Control"/>
1498<t>
1499   The Cache-Control general-header field is used to specify directives
1500   that MUST be obeyed by all caching mechanisms along the
1501   request/response chain. The directives specify behavior intended to
1502   prevent caches from adversely interfering with the request or
1503   response. These directives typically override the default caching
1504   algorithms. Cache directives are unidirectional in that the presence
1505   of a directive in a request does not imply that the same directive is
1506   to be given in the response.
1507  <list><t>
1508      Note that HTTP/1.0 caches might not implement Cache-Control and
1509      might only implement Pragma: no-cache (see <xref target="header.pragma"/>).
1510  </t></list>
1511</t>
1512<t>
1513   Cache directives MUST be passed through by a proxy or gateway
1514   application, regardless of their significance to that application,
1515   since the directives might be applicable to all recipients along the
1516   request/response chain. It is not possible to specify a cache-directive
1517   for a specific cache.
1518</t>
1519<figure><iref primary="true" item="Grammar" subitem="Cache-Control"/><iref primary="true" item="Grammar" subitem="cache-directive"/><iref primary="true" item="Grammar" subitem="cache-request-directive"/><iref primary="true" item="Grammar" subitem="cache-response-directive"/><iref primary="true" item="Grammar" subitem="cache-extension"/><artwork type="abnf2616"><![CDATA[
1520  Cache-Control   = "Cache-Control" ":" 1#cache-directive
1521
1522  cache-directive = cache-request-directive
1523     | cache-response-directive
1524
1525  cache-request-directive =
1526       "no-cache"                          ; Section 16.2.1
1527     | "no-store"                          ; Section 16.2.2
1528     | "max-age" "=" delta-seconds         ; Section 16.2.3, 16.2.4
1529     | "max-stale" [ "=" delta-seconds ]   ; Section 16.2.3
1530     | "min-fresh" "=" delta-seconds       ; Section 16.2.3
1531     | "no-transform"                      ; Section 16.2.5
1532     | "only-if-cached"                    ; Section 16.2.4
1533     | cache-extension                     ; Section 16.2.6
1534
1535  cache-response-directive =
1536       "public"                               ; Section 16.2.1
1537     | "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1
1538     | "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1
1539     | "no-store"                             ; Section 16.2.2
1540     | "no-transform"                         ; Section 16.2.5
1541     | "must-revalidate"                      ; Section 16.2.4
1542     | "proxy-revalidate"                     ; Section 16.2.4
1543     | "max-age" "=" delta-seconds            ; Section 16.2.3
1544     | "s-maxage" "=" delta-seconds           ; Section 16.2.3
1545     | cache-extension                        ; Section 16.2.6
1546
1547  cache-extension = token [ "=" ( token | quoted-string ) ]
1548]]></artwork></figure>
1549<t>
1550   When a directive appears without any 1#field-name parameter, the
1551   directive applies to the entire request or response. When such a
1552   directive appears with a 1#field-name parameter, it applies only to
1553   the named field or fields, and not to the rest of the request or
1554   response. This mechanism supports extensibility; implementations of
1555   future versions of HTTP might apply these directives to
1556   header fields not defined in HTTP/1.1.
1557</t>
1558<t>
1559   The cache-control directives can be broken down into these general
1560   categories:
1561  <list style="symbols">
1562     <t>Restrictions on what are cacheable; these may only be imposed by
1563        the origin server.</t>
1564
1565     <t>Restrictions on what may be stored by a cache; these may be
1566        imposed by either the origin server or the user agent.</t>
1567
1568     <t>Modifications of the basic expiration mechanism; these may be
1569        imposed by either the origin server or the user agent.</t>
1570
1571     <t>Controls over cache revalidation and reload; these may only be
1572        imposed by a user agent.</t>
1573
1574     <t>Control over transformation of entities.</t>
1575
1576     <t>Extensions to the caching system.</t>
1577  </list>
1578</t>
1579
1580<section title="What is Cacheable" anchor="what.is.cacheable">
1581<t>
1582   By default, a response is cacheable if the requirements of the
1583   request method, request header fields, and the response status
1584   indicate that it is cacheable. <xref target="response.cacheability"/> summarizes these defaults
1585   for cacheability. The following Cache-Control response directives
1586   allow an origin server to override the default cacheability of a
1587   response:
1588</t>
1589<t>
1590  <iref item="Cache Directives" subitem="public" primary="true"/>
1591  <iref item="public" subitem="Cache Directive" primary="true"/>
1592   public
1593  <list><t>
1594      Indicates that the response MAY be cached by any cache, even if it
1595      would normally be non-cacheable or cacheable only within a non-shared
1596      cache. (See also Authorization, Section 4.1 of <xref target="Part7"/>, for
1597      additional details.)
1598  </t></list>
1599</t>
1600<t>
1601  <iref item="Cache Directives" subitem="private" primary="true"/>
1602  <iref item="private" subitem="Cache Directive" primary="true"/>
1603   private
1604  <list><t>
1605      Indicates that all or part of the response message is intended for
1606      a single user and MUST NOT be cached by a shared cache. This
1607      allows an origin server to state that the specified parts of the
1608      response are intended for only one user and are not a valid
1609      response for requests by other users. A private (non-shared) cache
1610      MAY cache the response.
1611    </t><t>
1612       Note: This usage of the word private only controls where the
1613       response may be cached, and cannot ensure the privacy of the
1614       message content.
1615  </t></list>
1616</t>
1617<t>
1618  <iref item="Cache Directives" subitem="no-cache" primary="true"/>
1619  <iref item="no-cache" subitem="Cache Directive" primary="true"/>
1620   no-cache
1621  <list><t>
1622       If the no-cache directive does not specify a field-name, then a
1623      cache MUST NOT use the response to satisfy a subsequent request
1624      without successful revalidation with the origin server. This
1625      allows an origin server to prevent caching even by caches that
1626      have been configured to return stale responses to client requests.
1627    </t><t>
1628      If the no-cache directive does specify one or more field-names,
1629      then a cache MAY use the response to satisfy a subsequent request,
1630      subject to any other restrictions on caching. However, the
1631      specified field-name(s) MUST NOT be sent in the response to a
1632      subsequent request without successful revalidation with the origin
1633      server. This allows an origin server to prevent the re-use of
1634      certain header fields in a response, while still allowing caching
1635      of the rest of the response.
1636    <list><t>
1637       Note: Most HTTP/1.0 caches will not recognize or obey this
1638       directive.
1639    </t></list>
1640  </t></list>
1641</t>
1642</section>
1643
1644<section title="What May be Stored by Caches" anchor="what.may.be.stored.by.caches">
1645<t>
1646  <iref item="Cache Directives" subitem="no-store" primary="true"/>
1647  <iref item="no-store" subitem="Cache Directive" primary="true"/>
1648   no-store
1649  <list><t>   
1650      The purpose of the no-store directive is to prevent the
1651      inadvertent release or retention of sensitive information (for
1652      example, on backup tapes). The no-store directive applies to the
1653      entire message, and MAY be sent either in a response or in a
1654      request. If sent in a request, a cache MUST NOT store any part of
1655      either this request or any response to it. If sent in a response,
1656      a cache MUST NOT store any part of either this response or the
1657      request that elicited it. This directive applies to both non-shared
1658      and shared caches. "MUST NOT store" in this context means
1659      that the cache MUST NOT intentionally store the information in
1660      non-volatile storage, and MUST make a best-effort attempt to
1661      remove the information from volatile storage as promptly as
1662      possible after forwarding it.
1663  </t><t>
1664      Even when this directive is associated with a response, users
1665      might explicitly store such a response outside of the caching
1666      system (e.g., with a "Save As" dialog). History buffers MAY store
1667      such responses as part of their normal operation.
1668  </t><t>
1669      The purpose of this directive is to meet the stated requirements
1670      of certain users and service authors who are concerned about
1671      accidental releases of information via unanticipated accesses to
1672      cache data structures. While the use of this directive might
1673      improve privacy in some cases, we caution that it is NOT in any
1674      way a reliable or sufficient mechanism for ensuring privacy. In
1675      particular, malicious or compromised caches might not recognize or
1676      obey this directive, and communications networks might be
1677      vulnerable to eavesdropping.
1678  </t></list>
1679</t>
1680</section>
1681
1682<section title="Modifications of the Basic Expiration Mechanism" anchor="modifications.of.the.basic.expiration.mechanism">
1683<t>
1684   The expiration time of an entity MAY be specified by the origin
1685   server using the Expires header (see <xref target="header.expires"/>). Alternatively,
1686   it MAY be specified using the max-age directive in a response. When
1687   the max-age cache-control directive is present in a cached response,
1688   the response is stale if its current age is greater than the age
1689   value given (in seconds) at the time of a new request for that
1690   resource. The max-age directive on a response implies that the
1691   response is cacheable (i.e., "public") unless some other, more
1692   restrictive cache directive is also present.
1693</t>
1694<t>
1695   If a response includes both an Expires header and a max-age
1696   directive, the max-age directive overrides the Expires header, even
1697   if the Expires header is more restrictive. This rule allows an origin
1698   server to provide, for a given response, a longer expiration time to
1699   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
1700   useful if certain HTTP/1.0 caches improperly calculate ages or
1701   expiration times, perhaps due to desynchronized clocks.
1702</t>
1703<t>
1704   Many HTTP/1.0 cache implementations will treat an Expires value that
1705   is less than or equal to the response Date value as being equivalent
1706   to the Cache-Control response directive "no-cache". If an HTTP/1.1
1707   cache receives such a response, and the response does not include a
1708   Cache-Control header field, it SHOULD consider the response to be
1709   non-cacheable in order to retain compatibility with HTTP/1.0 servers.
1710  <list><t>
1711       Note: An origin server might wish to use a relatively new HTTP
1712       cache control feature, such as the "private" directive, on a
1713       network including older caches that do not understand that
1714       feature. The origin server will need to combine the new feature
1715       with an Expires field whose value is less than or equal to the
1716       Date value. This will prevent older caches from improperly
1717       caching the response.
1718  </t></list>
1719</t>
1720<t>
1721  <iref item="Cache Directives" subitem="s-maxage" primary="true"/>
1722  <iref item="s-maxage" subitem="Cache Directive" primary="true"/>
1723   s-maxage
1724  <list><t>
1725       If a response includes an s-maxage directive, then for a shared
1726       cache (but not for a private cache), the maximum age specified by
1727       this directive overrides the maximum age specified by either the
1728       max-age directive or the Expires header. The s-maxage directive
1729       also implies the semantics of the proxy-revalidate directive (see
1730       <xref target="cache.revalidation.and.reload.controls"/>), i.e., that the shared cache must not use the
1731       entry after it becomes stale to respond to a subsequent request
1732       without first revalidating it with the origin server. The s-maxage
1733       directive is always ignored by a private cache.
1734  </t></list>
1735</t>
1736<t>
1737   Note that most older caches, not compliant with this specification,
1738   do not implement any cache-control directives. An origin server
1739   wishing to use a cache-control directive that restricts, but does not
1740   prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
1741   requirement that the max-age directive overrides the Expires header,
1742   and the fact that pre-HTTP/1.1-compliant caches do not observe the
1743   max-age directive.
1744</t>
1745<t>
1746   Other directives allow a user agent to modify the basic expiration
1747   mechanism. These directives MAY be specified on a request:
1748</t>
1749<t>
1750  <iref item="Cache Directives" subitem="max-age" primary="true"/>
1751  <iref item="max-age" subitem="Cache Directive" primary="true"/>
1752   max-age
1753  <list><t>
1754      Indicates that the client is willing to accept a response whose
1755      age is no greater than the specified time in seconds. Unless max-stale
1756      directive is also included, the client is not willing to
1757      accept a stale response.
1758  </t></list>
1759</t>
1760<t>
1761  <iref item="Cache Directives" subitem="min-fresh" primary="true"/>
1762  <iref item="min-fresh" subitem="Cache Directive" primary="true"/>
1763   min-fresh
1764  <list><t>
1765      Indicates that the client is willing to accept a response whose
1766      freshness lifetime is no less than its current age plus the
1767      specified time in seconds. That is, the client wants a response
1768      that will still be fresh for at least the specified number of
1769      seconds.
1770  </t></list>
1771</t>
1772<t>
1773  <iref item="Cache Directives" subitem="max-stale" primary="true"/>
1774  <iref item="max-stale" subitem="Cache Directive" primary="true"/>
1775   max-stale
1776  <list><t>
1777      Indicates that the client is willing to accept a response that has
1778      exceeded its expiration time. If max-stale is assigned a value,
1779      then the client is willing to accept a response that has exceeded
1780      its expiration time by no more than the specified number of
1781      seconds. If no value is assigned to max-stale, then the client is
1782      willing to accept a stale response of any age.
1783  </t></list>
1784</t>
1785<t>
1786   If a cache returns a stale response, either because of a max-stale
1787   directive on a request, or because the cache is configured to
1788   override the expiration time of a response, the cache MUST attach a
1789   Warning header to the stale response, using Warning 110 (Response is
1790   stale).
1791</t>
1792<t>
1793   A cache MAY be configured to return stale responses without
1794   validation, but only if this does not conflict with any "MUST"-level
1795   requirements concerning cache validation (e.g., a "must-revalidate"
1796   cache-control directive).
1797</t>
1798<t>
1799   If both the new request and the cached entry include "max-age"
1800   directives, then the lesser of the two values is used for determining
1801   the freshness of the cached entry for that request.
1802</t>
1803</section>
1804
1805<section title="Cache Revalidation and Reload Controls" anchor="cache.revalidation.and.reload.controls">
1806<t>
1807   Sometimes a user agent might want or need to insist that a cache
1808   revalidate its cache entry with the origin server (and not just with
1809   the next cache along the path to the origin server), or to reload its
1810   cache entry from the origin server. End-to-end revalidation might be
1811   necessary if either the cache or the origin server has overestimated
1812   the expiration time of the cached response. End-to-end reload may be
1813   necessary if the cache entry has become corrupted for some reason.
1814</t>
1815<t>
1816   End-to-end revalidation may be requested either when the client does
1817   not have its own local cached copy, in which case we call it
1818   "unspecified end-to-end revalidation", or when the client does have a
1819   local cached copy, in which case we call it "specific end-to-end
1820   revalidation."
1821</t>
1822<t>
1823   The client can specify these three kinds of action using Cache-Control
1824   request directives:
1825</t>
1826<t>
1827   End-to-end reload
1828  <list><t>
1829      The request includes a "no-cache" cache-control directive or, for
1830      compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
1831      names MUST NOT be included with the no-cache directive in a
1832      request. The server MUST NOT use a cached copy when responding to
1833      such a request.
1834  </t></list>
1835</t>
1836<t>
1837   Specific end-to-end revalidation
1838  <list><t>
1839      The request includes a "max-age=0" cache-control directive, which
1840      forces each cache along the path to the origin server to
1841      revalidate its own entry, if any, with the next cache or server.
1842      The initial request includes a cache-validating conditional with
1843      the client's current validator.
1844  </t></list>
1845</t>
1846<t>
1847   Unspecified end-to-end revalidation
1848  <list><t>
1849      The request includes "max-age=0" cache-control directive, which
1850      forces each cache along the path to the origin server to
1851      revalidate its own entry, if any, with the next cache or server.
1852      The initial request does not include a cache-validating
1853      conditional; the first cache along the path (if any) that holds a
1854      cache entry for this resource includes a cache-validating
1855      conditional with its current validator.
1856  </t></list>
1857</t>
1858<t>
1859  <iref item="Cache Directives" subitem="max-age" primary="true"/>
1860  <iref item="max-age" subitem="Cache Directive" primary="true"/>
1861   max-age
1862  <list><t>
1863      When an intermediate cache is forced, by means of a max-age=0
1864      directive, to revalidate its own cache entry, and the client has
1865      supplied its own validator in the request, the supplied validator
1866      might differ from the validator currently stored with the cache
1867      entry. In this case, the cache MAY use either validator in making
1868      its own request without affecting semantic transparency.
1869  </t><t>
1870      However, the choice of validator might affect performance. The
1871      best approach is for the intermediate cache to use its own
1872      validator when making its request. If the server replies with 304
1873      (Not Modified), then the cache can return its now validated copy
1874      to the client with a 200 (OK) response. If the server replies with
1875      a new entity and cache validator, however, the intermediate cache
1876      can compare the returned validator with the one provided in the
1877      client's request, using the strong comparison function. If the
1878      client's validator is equal to the origin server's, then the
1879      intermediate cache simply returns 304 (Not Modified). Otherwise,
1880      it returns the new entity with a 200 (OK) response.
1881  </t><t>
1882      If a request includes the no-cache directive, it SHOULD NOT
1883      include min-fresh, max-stale, or max-age.
1884  </t></list>
1885</t>
1886<t>
1887  <iref item="Cache Directives" subitem="only-if-cached" primary="true"/>
1888  <iref item="only-if-cached" subitem="Cache Directive" primary="true"/>
1889   only-if-cached
1890  <list><t>
1891      In some cases, such as times of extremely poor network
1892      connectivity, a client may want a cache to return only those
1893      responses that it currently has stored, and not to reload or
1894      revalidate with the origin server. To do this, the client may
1895      include the only-if-cached directive in a request. If it receives
1896      this directive, a cache SHOULD either respond using a cached entry
1897      that is consistent with the other constraints of the request, or
1898      respond with a 504 (Gateway Timeout) status. However, if a group
1899      of caches is being operated as a unified system with good internal
1900      connectivity, such a request MAY be forwarded within that group of
1901      caches.
1902  </t></list>
1903</t>
1904<t>
1905  <iref item="Cache Directives" subitem="must-revalidate" primary="true"/>
1906  <iref item="must-revalidate" subitem="Cache Directive" primary="true"/>
1907   must-revalidate
1908  <list><t>
1909      Because a cache MAY be configured to ignore a server's specified
1910      expiration time, and because a client request MAY include a max-stale
1911      directive (which has a similar effect), the protocol also
1912      includes a mechanism for the origin server to require revalidation
1913      of a cache entry on any subsequent use. When the must-revalidate
1914      directive is present in a response received by a cache, that cache
1915      MUST NOT use the entry after it becomes stale to respond to a
1916      subsequent request without first revalidating it with the origin
1917      server. (I.e., the cache MUST do an end-to-end revalidation every
1918      time, if, based solely on the origin server's Expires or max-age
1919      value, the cached response is stale.)
1920  </t><t>
1921      The must-revalidate directive is necessary to support reliable
1922      operation for certain protocol features. In all circumstances an
1923      HTTP/1.1 cache MUST obey the must-revalidate directive; in
1924      particular, if the cache cannot reach the origin server for any
1925      reason, it MUST generate a 504 (Gateway Timeout) response.
1926  </t><t>
1927      Servers SHOULD send the must-revalidate directive if and only if
1928      failure to revalidate a request on the entity could result in
1929      incorrect operation, such as a silently unexecuted financial
1930      transaction. Recipients MUST NOT take any automated action that
1931      violates this directive, and MUST NOT automatically provide an
1932      unvalidated copy of the entity if revalidation fails.
1933  </t><t>
1934      Although this is not recommended, user agents operating under
1935      severe connectivity constraints MAY violate this directive but, if
1936      so, MUST explicitly warn the user that an unvalidated response has
1937      been provided. The warning MUST be provided on each unvalidated
1938      access, and SHOULD require explicit user confirmation.
1939  </t></list>
1940</t>
1941<t>
1942  <iref item="Cache Directives" subitem="proxy-revalidate" primary="true"/>
1943  <iref item="proxy-revalidate" subitem="Cache Directive" primary="true"/>
1944   proxy-revalidate
1945  <list><t>
1946      The proxy-revalidate directive has the same meaning as the must-revalidate
1947      directive, except that it does not apply to non-shared
1948      user agent caches. It can be used on a response to an
1949      authenticated request to permit the user's cache to store and
1950      later return the response without needing to revalidate it (since
1951      it has already been authenticated once by that user), while still
1952      requiring proxies that service many users to revalidate each time
1953      (in order to make sure that each user has been authenticated).
1954      Note that such authenticated responses also need the public cache
1955      control directive in order to allow them to be cached at all.
1956  </t></list>
1957</t>
1958</section>
1959
1960<section title="No-Transform Directive" anchor="no-transform.directive">
1961<t>
1962  <iref item="Cache Directives" subitem="no-transform" primary="true"/>
1963  <iref item="no-transform" subitem="Cache Directive" primary="true"/>
1964   no-transform
1965  <list><t>
1966      Implementors of intermediate caches (proxies) have found it useful
1967      to convert the media type of certain entity bodies. A non-transparent
1968      proxy might, for example, convert between image
1969      formats in order to save cache space or to reduce the amount of
1970      traffic on a slow link.
1971  </t><t>
1972      Serious operational problems occur, however, when these
1973      transformations are applied to entity bodies intended for certain
1974      kinds of applications. For example, applications for medical
1975      imaging, scientific data analysis and those using end-to-end
1976      authentication, all depend on receiving an entity body that is bit
1977      for bit identical to the original entity-body.
1978  </t><t>
1979      Therefore, if a message includes the no-transform directive, an
1980      intermediate cache or proxy MUST NOT change those headers that are
1981      listed in <xref target="non-modifiable.headers"/> as being subject to the no-transform
1982      directive. This implies that the cache or proxy MUST NOT change
1983      any aspect of the entity-body that is specified by these headers,
1984      including the value of the entity-body itself.
1985  </t></list>
1986</t>
1987</section>
1988
1989<section title="Cache Control Extensions" anchor="cache.control.extensions">
1990<t>
1991   The Cache-Control header field can be extended through the use of one
1992   or more cache-extension tokens, each with an optional assigned value.
1993   Informational extensions (those which do not require a change in
1994   cache behavior) MAY be added without changing the semantics of other
1995   directives. Behavioral extensions are designed to work by acting as
1996   modifiers to the existing base of cache directives. Both the new
1997   directive and the standard directive are supplied, such that
1998   applications which do not understand the new directive will default
1999   to the behavior specified by the standard directive, and those that
2000   understand the new directive will recognize it as modifying the
2001   requirements associated with the standard directive. In this way,
2002   extensions to the cache-control directives can be made without
2003   requiring changes to the base protocol.
2004</t>
2005<t>
2006   This extension mechanism depends on an HTTP cache obeying all of the
2007   cache-control directives defined for its native HTTP-version, obeying
2008   certain extensions, and ignoring all directives that it does not
2009   understand.
2010</t>
2011<t>
2012   For example, consider a hypothetical new response directive called
2013   community which acts as a modifier to the private directive. We
2014   define this new directive to mean that, in addition to any non-shared
2015   cache, any cache which is shared only by members of the community
2016   named within its value may cache the response. An origin server
2017   wishing to allow the UCI community to use an otherwise private
2018   response in their shared cache(s) could do so by including
2019</t>
2020<figure><artwork type="example"><![CDATA[
2021    Cache-Control: private, community="UCI"
2022]]></artwork></figure>
2023<t>
2024   A cache seeing this header field will act correctly even if the cache
2025   does not understand the community cache-extension, since it will also
2026   see and understand the private directive and thus default to the safe
2027   behavior.
2028</t>
2029<t>
2030   Unrecognized cache-directives MUST be ignored; it is assumed that any
2031   cache-directive likely to be unrecognized by an HTTP/1.1 cache will
2032   be combined with standard directives (or the response's default
2033   cacheability) such that the cache behavior will remain minimally
2034   correct even if the cache does not understand the extension(s).
2035</t>
2036</section>
2037</section>
2038
2039<section title="Expires" anchor="header.expires">
2040  <iref primary="true" item="Expires header"/>
2041  <iref primary="true" item="Headers" subitem="Expires"/>
2042<t>
2043   The Expires entity-header field gives the date/time after which the
2044   response is considered stale. A stale cache entry may not normally be
2045   returned by a cache (either a proxy cache or a user agent cache)
2046   unless it is first validated with the origin server (or with an
2047   intermediate cache that has a fresh copy of the entity). See <xref target="expiration.model"/>
2048   for further discussion of the expiration model.
2049</t>
2050<t>
2051   The presence of an Expires field does not imply that the original
2052   resource will change or cease to exist at, before, or after that
2053   time.
2054</t>
2055<t>
2056   The format is an absolute date and time as defined by HTTP-date in
2057   Section 3.3.1 of <xref target="Part1"/>; it MUST be sent in rfc1123-date format.
2058</t>
2059<figure><iref primary="true" item="Grammar" subitem="Expires"/><artwork type="abnf2616"><![CDATA[
2060  Expires = "Expires" ":" HTTP-date
2061]]></artwork></figure>
2062<t>
2063   An example of its use is
2064</t>
2065<figure><artwork type="example"><![CDATA[
2066   Expires: Thu, 01 Dec 1994 16:00:00 GMT
2067]]></artwork></figure>
2068<t>
2069  <list><t>
2070      Note: if a response includes a Cache-Control field with the max-age
2071      directive (see <xref target="modifications.of.the.basic.expiration.mechanism"/>), that directive overrides the
2072      Expires field.
2073  </t></list>
2074</t>
2075<t>
2076   HTTP/1.1 clients and caches MUST treat other invalid date formats,
2077   especially including the value "0", as in the past (i.e., "already
2078   expired").
2079</t>
2080<t>
2081   To mark a response as "already expired," an origin server sends an
2082   Expires date that is equal to the Date header value. (See the rules
2083   for expiration calculations in <xref target="expiration.calculations"/>.)
2084</t>
2085<t>
2086   To mark a response as "never expires," an origin server sends an
2087   Expires date approximately one year from the time the response is
2088   sent. HTTP/1.1 servers SHOULD NOT  send Expires dates more than one
2089   year in the future.
2090</t>
2091<t>
2092   The presence of an Expires header field with a date value of some
2093   time in the future on a response that otherwise would by default be
2094   non-cacheable indicates that the response is cacheable, unless
2095   indicated otherwise by a Cache-Control header field (<xref target="header.cache-control"/>).
2096</t>
2097</section>
2098
2099<section title="Pragma" anchor="header.pragma">
2100  <iref primary="true" item="Pragma header"/>
2101  <iref primary="true" item="Headers" subitem="Pragma"/>
2102<t>
2103   The Pragma general-header field is used to include implementation-specific
2104   directives that might apply to any recipient along the
2105   request/response chain. All pragma directives specify optional
2106   behavior from the viewpoint of the protocol; however, some systems
2107   MAY require that behavior be consistent with the directives.
2108</t>
2109<figure><iref primary="true" item="Grammar" subitem="Pragma"/><iref primary="true" item="Grammar" subitem="pragma-directive"/><iref primary="true" item="Grammar" subitem="extension-pragma"/><artwork type="abnf2616"><![CDATA[
2110  Pragma            = "Pragma" ":" 1#pragma-directive
2111  pragma-directive  = "no-cache" | extension-pragma
2112  extension-pragma  = token [ "=" ( token | quoted-string ) ]
2113]]></artwork></figure>
2114<t>
2115   When the no-cache directive is present in a request message, an
2116   application SHOULD forward the request toward the origin server even
2117   if it has a cached copy of what is being requested. This pragma
2118   directive has the same semantics as the no-cache cache-directive (see
2119   <xref target="header.cache-control"/>) and is defined here for backward compatibility with
2120   HTTP/1.0. Clients SHOULD include both header fields when a no-cache
2121   request is sent to a server not known to be HTTP/1.1 compliant.
2122</t>
2123<t>
2124   Pragma directives MUST be passed through by a proxy or gateway
2125   application, regardless of their significance to that application,
2126   since the directives might be applicable to all recipients along the
2127   request/response chain. It is not possible to specify a pragma for a
2128   specific recipient; however, any pragma directive not relevant to a
2129   recipient SHOULD be ignored by that recipient.
2130</t>
2131<t>
2132   HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
2133   sent "Cache-Control: no-cache". No new Pragma directives will be
2134   defined in HTTP.
2135  <list><t>
2136      Note: because the meaning of "Pragma: no-cache" as a
2137      response-header field is not actually specified, it does not provide a
2138      reliable replacement for "Cache-Control: no-cache" in a response.
2139  </t></list>
2140</t>
2141</section>
2142
2143<section title="Vary" anchor="header.vary">
2144  <iref primary="true" item="Vary header"/>
2145  <iref primary="true" item="Headers" subitem="Vary"/>
2146<t>
2147   The Vary field value indicates the set of request-header fields that
2148   fully determines, while the response is fresh, whether a cache is
2149   permitted to use the response to reply to a subsequent request
2150   without revalidation. For uncacheable or stale responses, the Vary
2151   field value advises the user agent about the criteria that were used
2152   to select the representation. A Vary field value of "*" implies that
2153   a cache cannot determine from the request headers of a subsequent
2154   request whether this response is the appropriate representation. See
2155   <xref target="caching.negotiated.responses"/> for use of the Vary header field by caches.
2156</t>
2157<figure><iref primary="true" item="Grammar" subitem="Vary"/><artwork type="abnf2616"><![CDATA[
2158  Vary  = "Vary" ":" ( "*" | 1#field-name )
2159]]></artwork></figure>
2160<t>
2161   An HTTP/1.1 server SHOULD include a Vary header field with any
2162   cacheable response that is subject to server-driven negotiation.
2163   Doing so allows a cache to properly interpret future requests on that
2164   resource and informs the user agent about the presence of negotiation
2165   on that resource. A server MAY include a Vary header field with a
2166   non-cacheable response that is subject to server-driven negotiation,
2167   since this might provide the user agent with useful information about
2168   the dimensions over which the response varies at the time of the
2169   response.
2170</t>
2171<t>
2172   A Vary field value consisting of a list of field-names signals that
2173   the representation selected for the response is based on a selection
2174   algorithm which considers ONLY the listed request-header field values
2175   in selecting the most appropriate representation. A cache MAY assume
2176   that the same selection will be made for future requests with the
2177   same values for the listed field names, for the duration of time for
2178   which the response is fresh.
2179</t>
2180<t>
2181   The field-names given are not limited to the set of standard
2182   request-header fields defined by this specification. Field names are
2183   case-insensitive.
2184</t>
2185<t>
2186   A Vary field value of "*" signals that unspecified parameters not
2187   limited to the request-headers (e.g., the network address of the
2188   client), play a role in the selection of the response representation.
2189   The "*" value MUST NOT be generated by a proxy server; it may only be
2190   generated by an origin server.
2191</t>
2192</section>
2193
2194<section title="Warning" anchor="header.warning">
2195  <iref primary="true" item="Warning header"/>
2196  <iref primary="true" item="Headers" subitem="Warning"/>
2197<t>
2198   The Warning general-header field is used to carry additional
2199   information about the status or transformation of a message which
2200   might not be reflected in the message. This information is typically
2201   used to warn about a possible lack of semantic transparency from
2202   caching operations or transformations applied to the entity body of
2203   the message.
2204</t>
2205<t>
2206   Warning headers are sent with responses using:
2207</t>
2208<figure><iref primary="true" item="Grammar" subitem="Warning"/><iref primary="true" item="Grammar" subitem="warning-value"/><iref primary="true" item="Grammar" subitem="warn-code"/><iref primary="true" item="Grammar" subitem="warn-agent"/><iref primary="true" item="Grammar" subitem="warn-text"/><iref primary="true" item="Grammar" subitem="warn-date"/><artwork type="abnf2616"><![CDATA[
2209  Warning    = "Warning" ":" 1#warning-value
2210 
2211  warning-value = warn-code SP warn-agent SP warn-text
2212                                        [SP warn-date]
2213 
2214  warn-code  = 3DIGIT
2215  warn-agent = ( uri-host [ ":" port ] ) | pseudonym
2216                  ; the name or pseudonym of the server adding
2217                  ; the Warning header, for use in debugging
2218  warn-text  = quoted-string
2219  warn-date  = DQUOTE HTTP-date DQUOTE
2220]]></artwork></figure>
2221<t>
2222   A response MAY carry more than one Warning header.
2223</t>
2224<t>
2225   The warn-text SHOULD be in a natural language and character set that
2226   is most likely to be intelligible to the human user receiving the
2227   response. This decision MAY be based on any available knowledge, such
2228   as the location of the cache or user, the Accept-Language field in a
2229   request, the Content-Language field in a response, etc. The default
2230   language is English and the default character set is ISO-8859-1 (<xref target="ISO-8859-1"/>).
2231</t>
2232<t>
2233   If a character set other than ISO-8859-1 is used, it MUST be encoded
2234   in the warn-text using the method described in <xref target="RFC2047"/>.
2235</t>
2236<t>
2237   Warning headers can in general be applied to any message, however
2238   some specific warn-codes are specific to caches and can only be
2239   applied to response messages. New Warning headers SHOULD be added
2240   after any existing Warning headers. A cache MUST NOT delete any
2241   Warning header that it received with a message. However, if a cache
2242   successfully validates a cache entry, it SHOULD remove any Warning
2243   headers previously attached to that entry except as specified for
2244   specific Warning codes. It MUST then add any Warning headers received
2245   in the validating response. In other words, Warning headers are those
2246   that would be attached to the most recent relevant response.
2247</t>
2248<t>
2249   When multiple Warning headers are attached to a response, the user
2250   agent ought to inform the user of as many of them as possible, in the
2251   order that they appear in the response. If it is not possible to
2252   inform the user of all of the warnings, the user agent SHOULD follow
2253   these heuristics:
2254  <list style="symbols">
2255    <t>Warnings that appear early in the response take priority over
2256        those appearing later in the response.</t>
2257
2258    <t>Warnings in the user's preferred character set take priority
2259        over warnings in other character sets but with identical warn-codes
2260        and warn-agents.</t>
2261  </list>
2262</t>
2263<t>
2264   Systems that generate multiple Warning headers SHOULD order them with
2265   this user agent behavior in mind.
2266</t>
2267<t>
2268   Requirements for the behavior of caches with respect to Warnings are
2269   stated in <xref target="warnings"/>.
2270</t>
2271<t>
2272   This is a list of the currently-defined warn-codes, each with a
2273   recommended warn-text in English, and a description of its meaning.
2274</t>
2275<t>
2276   110 Response is stale
2277  <list><t>
2278     MUST be included whenever the returned response is stale.
2279  </t></list>
2280</t>
2281<t>
2282   111 Revalidation failed
2283  <list><t>
2284     MUST be included if a cache returns a stale response because an
2285     attempt to revalidate the response failed, due to an inability to
2286     reach the server.
2287  </t></list>
2288</t>
2289<t>
2290   112 Disconnected operation
2291  <list><t>
2292     SHOULD be included if the cache is intentionally disconnected from
2293     the rest of the network for a period of time.
2294  </t></list>
2295</t>
2296<t>
2297   113 Heuristic expiration
2298  <list><t>
2299     MUST be included if the cache heuristically chose a freshness
2300     lifetime greater than 24 hours and the response's age is greater
2301     than 24 hours.
2302  </t></list>
2303</t>
2304<t>
2305   199 Miscellaneous warning
2306  <list><t>
2307     The warning text MAY include arbitrary information to be presented
2308     to a human user, or logged. A system receiving this warning MUST NOT
2309     take any automated action, besides presenting the warning to
2310     the user.
2311  </t></list>
2312</t>
2313<t>
2314   214 Transformation applied
2315  <list><t>
2316     MUST be added by an intermediate cache or proxy if it applies any
2317     transformation changing the content-coding (as specified in the
2318     Content-Encoding header) or media-type (as specified in the
2319     Content-Type header) of the response, or the entity-body of the
2320     response, unless this Warning code already appears in the response.
2321  </t></list>
2322</t>
2323<t>
2324   299 Miscellaneous persistent warning
2325  <list><t>
2326     The warning text MAY include arbitrary information to be presented
2327     to a human user, or logged. A system receiving this warning MUST NOT
2328     take any automated action.
2329  </t></list>
2330</t>
2331<t>
2332   If an implementation sends a message with one or more Warning headers
2333   whose version is HTTP/1.0 or lower, then the sender MUST include in
2334   each warning-value a warn-date that matches the date in the response.
2335</t>
2336<t>
2337   If an implementation receives a message with a warning-value that
2338   includes a warn-date, and that warn-date is different from the Date
2339   value in the response, then that warning-value MUST be deleted from
2340   the message before storing, forwarding, or using it. (This prevents
2341   bad consequences of naive caching of Warning header fields.) If all
2342   of the warning-values are deleted for this reason, the Warning header
2343   MUST be deleted as well.
2344</t>
2345</section>
2346
2347</section>
2348
2349<section title="IANA Considerations" anchor="IANA.considerations">
2350<t>
2351   <cref>TBD.</cref>
2352</t>
2353</section>
2354
2355<section title="Security Considerations" anchor="security.considerations">
2356<t>
2357   Caching proxies provide additional potential vulnerabilities, since
2358   the contents of the cache represent an attractive target for
2359   malicious exploitation. Because cache contents persist after an HTTP
2360   request is complete, an attack on the cache can reveal information
2361   long after a user believes that the information has been removed from
2362   the network. Therefore, cache contents should be protected as
2363   sensitive information.
2364</t>
2365</section>
2366
2367<section title="Acknowledgments" anchor="ack">
2368<t>
2369   Much of the content and presentation of the caching design is due to
2370   suggestions and comments from individuals including: Shel Kaphan,
2371   Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
2372</t>
2373</section>
2374</middle>
2375<back>
2376
2377<references title="Normative References">
2378
2379<reference anchor="ISO-8859-1">
2380  <front>
2381    <title>
2382     Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1
2383    </title>
2384    <author>
2385      <organization>International Organization for Standardization</organization>
2386    </author>
2387    <date year="1998"/>
2388  </front>
2389  <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
2390</reference>
2391
2392<reference anchor="Part1">
2393  <front>
2394    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
2395    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2396      <organization abbrev="Day Software">Day Software</organization>
2397      <address><email>fielding@gbiv.com</email></address>
2398    </author>
2399    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2400      <organization>One Laptop per Child</organization>
2401      <address><email>jg@laptop.org</email></address>
2402    </author>
2403    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2404      <organization abbrev="HP">Hewlett-Packard Company</organization>
2405      <address><email>JeffMogul@acm.org</email></address>
2406    </author>
2407    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
2408      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2409      <address><email>henrikn@microsoft.com</email></address>
2410    </author>
2411    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2412      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
2413      <address><email>LMM@acm.org</email></address>
2414    </author>
2415    <author initials="P." surname="Leach" fullname="Paul J. Leach">
2416      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2417      <address><email>paulle@microsoft.com</email></address>
2418    </author>
2419    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2420      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
2421      <address><email>timbl@w3.org</email></address>
2422    </author>
2423    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
2424      <organization abbrev="W3C">World Wide Web Consortium</organization>
2425      <address><email>ylafon@w3.org</email></address>
2426    </author>
2427    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
2428      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2429      <address><email>julian.reschke@greenbytes.de</email></address>
2430    </author>
2431    <date month="February" year="2008"/>
2432  </front>
2433  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-02"/>
2434 
2435</reference>
2436
2437<reference anchor="Part2">
2438  <front>
2439    <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title>
2440    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2441      <organization abbrev="Day Software">Day Software</organization>
2442      <address><email>fielding@gbiv.com</email></address>
2443    </author>
2444    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2445      <organization>One Laptop per Child</organization>
2446      <address><email>jg@laptop.org</email></address>
2447    </author>
2448    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2449      <organization abbrev="HP">Hewlett-Packard Company</organization>
2450      <address><email>JeffMogul@acm.org</email></address>
2451    </author>
2452    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
2453      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2454      <address><email>henrikn@microsoft.com</email></address>
2455    </author>
2456    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2457      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
2458      <address><email>LMM@acm.org</email></address>
2459    </author>
2460    <author initials="P." surname="Leach" fullname="Paul J. Leach">
2461      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2462      <address><email>paulle@microsoft.com</email></address>
2463    </author>
2464    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2465      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
2466      <address><email>timbl@w3.org</email></address>
2467    </author>
2468    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
2469      <organization abbrev="W3C">World Wide Web Consortium</organization>
2470      <address><email>ylafon@w3.org</email></address>
2471    </author>
2472    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
2473      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2474      <address><email>julian.reschke@greenbytes.de</email></address>
2475    </author>
2476    <date month="February" year="2008"/>
2477  </front>
2478  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-02"/>
2479 
2480</reference>
2481
2482<reference anchor="Part3">
2483  <front>
2484    <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
2485    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2486      <organization abbrev="Day Software">Day Software</organization>
2487      <address><email>fielding@gbiv.com</email></address>
2488    </author>
2489    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2490      <organization>One Laptop per Child</organization>
2491      <address><email>jg@laptop.org</email></address>
2492    </author>
2493    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2494      <organization abbrev="HP">Hewlett-Packard Company</organization>
2495      <address><email>JeffMogul@acm.org</email></address>
2496    </author>
2497    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
2498      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2499      <address><email>henrikn@microsoft.com</email></address>
2500    </author>
2501    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2502      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
2503      <address><email>LMM@acm.org</email></address>
2504    </author>
2505    <author initials="P." surname="Leach" fullname="Paul J. Leach">
2506      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2507      <address><email>paulle@microsoft.com</email></address>
2508    </author>
2509    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2510      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
2511      <address><email>timbl@w3.org</email></address>
2512    </author>
2513    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
2514      <organization abbrev="W3C">World Wide Web Consortium</organization>
2515      <address><email>ylafon@w3.org</email></address>
2516    </author>
2517    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
2518      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2519      <address><email>julian.reschke@greenbytes.de</email></address>
2520    </author>
2521    <date month="February" year="2008"/>
2522  </front>
2523  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-02"/>
2524 
2525</reference>
2526
2527<reference anchor="Part4">
2528  <front>
2529    <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title>
2530    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2531      <organization abbrev="Day Software">Day Software</organization>
2532      <address><email>fielding@gbiv.com</email></address>
2533    </author>
2534    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2535      <organization>One Laptop per Child</organization>
2536      <address><email>jg@laptop.org</email></address>
2537    </author>
2538    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2539      <organization abbrev="HP">Hewlett-Packard Company</organization>
2540      <address><email>JeffMogul@acm.org</email></address>
2541    </author>
2542    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
2543      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2544      <address><email>henrikn@microsoft.com</email></address>
2545    </author>
2546    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2547      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
2548      <address><email>LMM@acm.org</email></address>
2549    </author>
2550    <author initials="P." surname="Leach" fullname="Paul J. Leach">
2551      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2552      <address><email>paulle@microsoft.com</email></address>
2553    </author>
2554    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2555      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
2556      <address><email>timbl@w3.org</email></address>
2557    </author>
2558    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
2559      <organization abbrev="W3C">World Wide Web Consortium</organization>
2560      <address><email>ylafon@w3.org</email></address>
2561    </author>
2562    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
2563      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2564      <address><email>julian.reschke@greenbytes.de</email></address>
2565    </author>
2566    <date month="February" year="2008"/>
2567  </front>
2568  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-02"/>
2569 
2570</reference>
2571
2572<reference anchor="Part5">
2573  <front>
2574    <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
2575    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2576      <organization abbrev="Day Software">Day Software</organization>
2577      <address><email>fielding@gbiv.com</email></address>
2578    </author>
2579    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2580      <organization>One Laptop per Child</organization>
2581      <address><email>jg@laptop.org</email></address>
2582    </author>
2583    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2584      <organization abbrev="HP">Hewlett-Packard Company</organization>
2585      <address><email>JeffMogul@acm.org</email></address>
2586    </author>
2587    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
2588      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2589      <address><email>henrikn@microsoft.com</email></address>
2590    </author>
2591    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2592      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
2593      <address><email>LMM@acm.org</email></address>
2594    </author>
2595    <author initials="P." surname="Leach" fullname="Paul J. Leach">
2596      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2597      <address><email>paulle@microsoft.com</email></address>
2598    </author>
2599    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2600      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
2601      <address><email>timbl@w3.org</email></address>
2602    </author>
2603    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
2604      <organization abbrev="W3C">World Wide Web Consortium</organization>
2605      <address><email>ylafon@w3.org</email></address>
2606    </author>
2607    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
2608      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2609      <address><email>julian.reschke@greenbytes.de</email></address>
2610    </author>
2611    <date month="February" year="2008"/>
2612  </front>
2613  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-02"/>
2614 
2615</reference>
2616
2617<reference anchor="Part7">
2618  <front>
2619    <title abbrev="HTTP/1.1">HTTP/1.1, part 7: Authentication</title>
2620    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2621      <organization abbrev="Day Software">Day Software</organization>
2622      <address><email>fielding@gbiv.com</email></address>
2623    </author>
2624    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2625      <organization>One Laptop per Child</organization>
2626      <address><email>jg@laptop.org</email></address>
2627    </author>
2628    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2629      <organization abbrev="HP">Hewlett-Packard Company</organization>
2630      <address><email>JeffMogul@acm.org</email></address>
2631    </author>
2632    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
2633      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2634      <address><email>henrikn@microsoft.com</email></address>
2635    </author>
2636    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2637      <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
2638      <address><email>LMM@acm.org</email></address>
2639    </author>
2640    <author initials="P." surname="Leach" fullname="Paul J. Leach">
2641      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2642      <address><email>paulle@microsoft.com</email></address>
2643    </author>
2644    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2645      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
2646      <address><email>timbl@w3.org</email></address>
2647    </author>
2648    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
2649      <organization abbrev="W3C">World Wide Web Consortium</organization>
2650      <address><email>ylafon@w3.org</email></address>
2651    </author>
2652    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
2653      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2654      <address><email>julian.reschke@greenbytes.de</email></address>
2655    </author>
2656    <date month="February" year="2008"/>
2657  </front>
2658  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-02"/>
2659 
2660</reference>
2661
2662<reference anchor="RFC2047">
2663  <front>
2664    <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
2665    <author initials="K." surname="Moore" fullname="Keith Moore">
2666      <organization>University of Tennessee</organization>
2667      <address><email>moore@cs.utk.edu</email></address>
2668    </author>
2669    <date month="November" year="1996"/>
2670  </front>
2671  <seriesInfo name="RFC" value="2047"/>
2672</reference>
2673
2674<reference anchor="RFC2119">
2675  <front>
2676    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
2677    <author initials="S." surname="Bradner" fullname="Scott Bradner">
2678      <organization>Harvard University</organization>
2679      <address><email>sob@harvard.edu</email></address>
2680    </author>
2681    <date month="March" year="1997"/>
2682  </front>
2683  <seriesInfo name="BCP" value="14"/>
2684  <seriesInfo name="RFC" value="2119"/>
2685</reference>
2686
2687</references>
2688
2689<references title="Informative References">
2690
2691<reference anchor="RFC1305">
2692  <front>
2693    <title>Network Time Protocol (Version 3) Specification, Implementation</title>
2694    <author initials="D." surname="Mills" fullname="David L. Mills">
2695      <organization>University of Delaware, Electrical Engineering Department</organization>
2696      <address><email>mills@udel.edu</email></address>
2697    </author>
2698    <date month="March" year="1992"/>
2699  </front>
2700  <seriesInfo name="RFC" value="1305"/>
2701</reference>
2702
2703<reference anchor="RFC2616">
2704  <front>
2705    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
2706    <author initials="R." surname="Fielding" fullname="R. Fielding">
2707      <organization>University of California, Irvine</organization>
2708      <address><email>fielding@ics.uci.edu</email></address>
2709    </author>
2710    <author initials="J." surname="Gettys" fullname="J. Gettys">
2711      <organization>W3C</organization>
2712      <address><email>jg@w3.org</email></address>
2713    </author>
2714    <author initials="J." surname="Mogul" fullname="J. Mogul">
2715      <organization>Compaq Computer Corporation</organization>
2716      <address><email>mogul@wrl.dec.com</email></address>
2717    </author>
2718    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
2719      <organization>MIT Laboratory for Computer Science</organization>
2720      <address><email>frystyk@w3.org</email></address>
2721    </author>
2722    <author initials="L." surname="Masinter" fullname="L. Masinter">
2723      <organization>Xerox Corporation</organization>
2724      <address><email>masinter@parc.xerox.com</email></address>
2725    </author>
2726    <author initials="P." surname="Leach" fullname="P. Leach">
2727      <organization>Microsoft Corporation</organization>
2728      <address><email>paulle@microsoft.com</email></address>
2729    </author>
2730    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
2731      <organization>W3C</organization>
2732      <address><email>timbl@w3.org</email></address>
2733    </author>
2734    <date month="June" year="1999"/>
2735  </front>
2736  <seriesInfo name="RFC" value="2616"/>
2737</reference>
2738
2739</references>
2740
2741<section title="Compatibility with Previous Versions" anchor="compatibility">
2742
2743<section title="Changes from RFC 2068" anchor="changes.from.rfc.2068">
2744<t>
2745   A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
2746   was introduced to add this missing case. (Sections <xref target="response.cacheability" format="counter"/>,
2747   <xref target="header.cache-control" format="counter"/>,
2748   <xref target="modifications.of.the.basic.expiration.mechanism" format="counter"/>)
2749</t>
2750<t>
2751   Transfer-coding and message lengths all interact in ways that
2752   required fixing exactly when chunked encoding is used (to allow for
2753   transfer encoding that may not be self delimiting); it was important
2754   to straighten out exactly how message lengths are computed.
2755   (<xref target="non-modifiable.headers"/>,
2756   see also <xref target="Part1"/>, <xref target="Part3"/> and <xref target="Part5"/>)
2757</t>
2758<t>
2759   Proxies should be able to add Content-Length when appropriate.
2760   (<xref target="non-modifiable.headers"/>)
2761</t>
2762<t>
2763   Range request responses would become very verbose if all meta-data
2764   were always returned; by allowing the server to only send needed
2765   headers in a 206 response, this problem can be avoided.
2766   (<xref target="combining.headers"/>)
2767</t>
2768<t>
2769   The Cache-Control: max-age directive was not properly defined for
2770   responses. (<xref target="modifications.of.the.basic.expiration.mechanism"/>)
2771</t>
2772<t>
2773   Warnings could be cached incorrectly, or not updated appropriately.
2774   (Section <xref target="warnings" format="counter"/>, <xref target="expiration.calculations" format="counter"/>, <xref target="non-modifiable.headers" format="counter"/>,
2775   <xref target="combining.headers" format="counter"/>, <xref target="modifications.of.the.basic.expiration.mechanism" format="counter"/>,
2776   and <xref target="header.warning" format="counter"/>) Warning
2777   also needed to be a general header, as PUT or other methods may have
2778   need for it in requests.
2779</t>
2780</section>
2781
2782<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
2783<t>
2784  Clarify denial of service attack avoidance requirement.
2785  (<xref target="invalidation.after.updates.or.deletions"/>)
2786</t>
2787</section>
2788
2789</section>
2790
2791<section title="Change Log (to be removed by RFC Editor before publication)">
2792
2793<section title="Since RFC2616">
2794<t>
2795  Extracted relevant partitions from <xref target="RFC2616"/>.
2796</t>
2797</section>
2798
2799<section title="Since draft-ietf-httpbis-p6-cache-00">
2800<t>
2801  Closed issues:
2802  <list style="symbols"> 
2803    <t>
2804      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/9"/>:
2805      "Trailer"
2806      (<eref target="http://purl.org/NET/http-errata#trailer-hop"/>)
2807    </t>
2808    <t>
2809      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/12"/>:
2810      "Invalidation after Update or Delete"
2811      (<eref target="http://purl.org/NET/http-errata#invalidupd"/>)
2812    </t>
2813    <t>
2814      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
2815      "Normative and Informative references"
2816    </t>
2817    <t>
2818      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48"/>:
2819      "Date reference typo"
2820    </t>
2821    <t>
2822      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/49"/>:
2823      "Connection header text"
2824    </t>
2825    <t>
2826      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65"/>:
2827      "Informative references"
2828    </t>
2829    <t>
2830      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66"/>:
2831      "ISO-8859-1 Reference"
2832    </t>
2833    <t>
2834      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86"/>:
2835      "Normative up-to-date references"
2836    </t>
2837    <t>
2838      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/87"/>:
2839      "typo in 13.2.2"
2840    </t>
2841  </list>
2842</t>
2843<t>
2844  Other changes:
2845  <list style="symbols"> 
2846    <t>
2847      Use names of RFC4234 core rules DQUOTE and HTAB (work in progress on <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36"/>)
2848    </t>
2849  </list>
2850</t>
2851</section>
2852
2853<section title="Since draft-ietf-httpbis-p6-cache-01">
2854<t>
2855  Closed issues:
2856  <list style="symbols"> 
2857    <t>
2858      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82"/>:
2859      "rel_path not used"
2860    </t>
2861  </list>
2862</t>
2863<t>
2864  Other changes:
2865  <list style="symbols"> 
2866    <t>
2867       Get rid of duplicate BNF rule names ("host" -&gt; "uri-host")
2868       (work in progress on <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36"/>)
2869    </t>
2870    <t>
2871      Add explicit references to BNF syntax and rules imported from other parts of the specification.
2872    </t>
2873  </list>
2874</t>
2875</section>
2876
2877</section>
2878
2879</back>
2880</rfc>
Note: See TracBrowser for help on using the repository browser.