source: draft-ietf-httpbis/26/draft-ietf-httpbis-p6-cache-26.xml @ 2616

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

prepare publication of -26

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