source: draft-ietf-httpbis/22/draft-ietf-httpbis-p6-cache-22.txt @ 2190

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

prepare -22 for release

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