draft-ietf-httpbis-p6-cache-16.txt   draft-ietf-httpbis-p6-cache-17.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: February 25, 2012 J. Mogul Expires: May 3, 2012 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
M. Nottingham, Ed. M. Nottingham, Ed.
Rackspace
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
August 24, 2011 October 31, 2011
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-16 draft-ietf-httpbis-p6-cache-17
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 6 of the information initiative since 1990. This document is Part 6 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. "HTTP/1.1" and, taken together, obsoletes RFC 2616.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.17. The changes in this draft are summarized in Appendix C.18.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 25, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2. ABNF Rules defined in other Parts of the 1.4.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 8 Specification . . . . . . . . . . . . . . . . . . . . 8
1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9
2.2. Constructing Responses from Caches . . . . . . . . . . . . 10 2.2. Constructing Responses from Caches . . . . . . . . . . . . 10
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 16 2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17
2.6. Shared Caching of Authenticated Responses . . . . . . . . 17 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18
2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 18 2.6. Shared Caching of Authenticated Responses . . . . . . . . 18
2.8. Combining Partial Content . . . . . . . . . . . . . . . . 18 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19
2.9. Freshening Responses . . . . . . . . . . . . . . . . . . . 19 2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
3.2.2. Response Cache-Control Directives . . . . . . . . . . 23 3.2.2. Response Cache-Control Directives . . . . . . . . . . 23
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32
5.2. Header Field Registration . . . . . . . . . . . . . . . . 32 5.2. Header Field Registration . . . . . . . . . . . . . . . . 33
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 34 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 36 publication) . . . . . . . . . . . . . . . . . . . . 36
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 36 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 37 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 37 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 38
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 37 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 38
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 38 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 39
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 38 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 39
C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39 C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39
C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 39 C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 40
C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40 C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40
C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 40 C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41
C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 40 C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 41
C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 40 C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 41
C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 40 C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 41
C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 41 C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 42
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
HTTP is typically used for distributed information systems, where HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches. This performance can be improved by the use of response caches. This
document defines aspects of HTTP/1.1 related to caching and reusing document defines aspects of HTTP/1.1 related to caching and reusing
response messages. response messages.
1.1. Purpose 1.1. Purpose
skipping to change at page 7, line 13 skipping to change at page 7, line 13
equivalent copy of a representation. See Section 2.1 of [Part4]. equivalent copy of a representation. See Section 2.1 of [Part4].
strong validator strong validator
A validator that is defined by the origin server such that its A validator that is defined by the origin server such that its
current value will change if the representation body changes; current value will change if the representation body changes;
i.e., an entity-tag that is not marked as weak (Section 2.3 of i.e., an entity-tag that is not marked as weak (Section 2.3 of
[Part4]) or, if no entity-tag is provided, a Last-Modified value [Part4]) or, if no entity-tag is provided, a Last-Modified value
that is strong in the sense defined by Section 2.2.2 of [Part4]. that is strong in the sense defined by Section 2.2.2 of [Part4].
1.3. Requirements 1.3. Conformance and Error Handling
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more This document defines conformance criteria for several roles in HTTP
of the "MUST" or "REQUIRED" level requirements for the protocols it communication, including Senders, Recipients, Clients, Servers, User-
implements. An implementation that satisfies all the "MUST" or Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
"REQUIRED" level and all the "SHOULD" level requirements for its Section 2 of [Part1] for definitions of these terms.
protocols is said to be "unconditionally compliant"; one that
satisfies all the "MUST" level requirements but not all the "SHOULD" An implementation is considered conformant if it complies with all of
level requirements for its protocols is said to be "conditionally the requirements associated with its role(s). Note that SHOULD-level
compliant". requirements are relevant here, unless one of the documented
exceptions is applicable.
This document also uses ABNF to define valid protocol elements
(Section 1.4). In addition to the prose requirements placed upon
them, Senders MUST NOT generate protocol elements that are invalid.
Unless noted otherwise, Recipients MAY take steps to recover a usable
protocol element from an invalid construct. However, HTTP does not
define specific error handling mechanisms, except in cases where it
has direct impact on security. This is because different uses of the
protocol require different error handling strategies; for example, a
Web browser may wish to transparently recover from a response where
the Location header field doesn't parse according to the ABNF,
whereby in a systems control protocol using HTTP, this type of error
recovery could lead to dangerous consequences.
1.4. Syntax Notation 1.4. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the ABNF syntax defined in Section 1.2 of
[Part1] (which extends the syntax defined in [RFC5234] with a list [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix B shows the collected ABNF, with the list rule rule). Appendix B shows the collected ABNF, with the list rule
expanded. expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible USASCII character), sequence of data), SP (space), and VCHAR (any visible US-ASCII
and WSP (whitespace). character).
1.4.1. Core Rules 1.4.1. Core Rules
The core rules below are defined in [Part1]: The core rules below are defined in [Part1]:
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.3>
1.4.2. ABNF Rules defined in other Parts of the Specification 1.4.2. ABNF Rules defined in other Parts of the Specification
The ABNF rules below are defined in other parts: The ABNF rules below are defined in other parts:
field-name = <field-name, defined in [Part1], Section 3.2> field-name = <field-name, defined in [Part1], Section 3.2>
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8>
port = <port, defined in [Part1], Section 2.7> port = <port, defined in [Part1], Section 2.7>
pseudonym = <pseudonym, defined in [Part1], Section 9.9> pseudonym = <pseudonym, defined in [Part1], Section 8.8>
uri-host = <uri-host, defined in [Part1], Section 2.7> uri-host = <uri-host, defined in [Part1], Section 2.7>
1.5. Delta Seconds 1.5. Delta Seconds
The delta-seconds rule specifies a non-negative integer, representing The delta-seconds rule specifies a non-negative integer, representing
time in seconds. time in seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
If an implementation receives a delta-seconds value larger than the If an implementation receives a delta-seconds value larger than the
largest positive integer it can represent, or if any of its largest positive integer it can represent, or if any of its
subsequent calculations overflows, it MUST consider the value to be subsequent calculations overflows, it MUST consider the value to be
2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD 2147483648 (2^31). Recipients parsing a delta-seconds value MUST use
use an arithmetic type of at least 31 bits of range, and senders MUST an arithmetic type of at least 31 bits of range, and senders MUST NOT
NOT send delta-seconds with a value greater than 2147483648. send delta-seconds with a value greater than 2147483648.
2. Cache Operation 2. Cache Operation
Proper cache operation preserves the semantics of HTTP transfers Proper cache operation preserves the semantics of HTTP transfers
([Part2]) while eliminating the transfer of information already held ([Part2]) while eliminating the transfer of information already held
in the cache. Although caching is an entirely OPTIONAL feature of in the cache. Although caching is an entirely OPTIONAL feature of
HTTP, we assume that reusing the cached response is desirable and HTTP, we assume that reusing the cached response is desirable and
that such reuse is the default behavior when no requirement or that such reuse is the default behavior when no requirement or
locally-desired configuration prevents it. Therefore, HTTP cache locally-desired configuration prevents it. Therefore, HTTP cache
requirements are focused on preventing a cache from either storing a requirements are focused on preventing a cache from either storing a
skipping to change at page 11, line 17 skipping to change at page 11, line 31
Note that any of the requirements listed above can be overridden by a Note that any of the requirements listed above can be overridden by a
cache-control extension; see Section 3.2.3. cache-control extension; see Section 3.2.3.
When a stored response is used to satisfy a request without When a stored response is used to satisfy a request without
validation, a cache MUST include a single Age header field validation, a cache MUST include a single Age header field
(Section 3.1) in the response with a value equal to the stored (Section 3.1) in the response with a value equal to the stored
response's current_age; see Section 2.3.2. response's current_age; see Section 2.3.2.
A cache MUST write through requests with methods that are unsafe A cache MUST write through requests with methods that are unsafe
(Section 7.1.1 of [Part2]) to the origin server; i.e., a cache must (Section 6.1.1 of [Part2]) to the origin server; i.e., a cache must
not generate a reply to such a request before having forwarded the not generate a reply to such a request before having forwarded the
request and having received a corresponding response. request and having received a corresponding response.
Also, note that unsafe requests might invalidate already stored Also, note that unsafe requests might invalidate already stored
responses; see Section 2.5. responses; see Section 2.5.
When more than one suitable response is stored, a cache MUST use the When more than one suitable response is stored, a cache MUST use the
most recent response (as determined by the Date header field). It most recent response (as determined by the Date header field). It
can also forward a request with "Cache-Control: max-age=0" or "Cache- can also forward a request with "Cache-Control: max-age=0" or "Cache-
Control: no-cache" to disambiguate which response to use. Control: no-cache" to disambiguate which response to use.
skipping to change at page 13, line 9 skipping to change at page 13, line 22
A heuristic freshness lifetime might be applicable; see A heuristic freshness lifetime might be applicable; see
Section 2.3.1.1. Section 2.3.1.1.
Note that this calculation is not vulnerable to clock skew, since all Note that this calculation is not vulnerable to clock skew, since all
of the information comes from the origin server. of the information comes from the origin server.
2.3.1.1. Calculating Heuristic Freshness 2.3.1.1. Calculating Heuristic Freshness
If no explicit expiration time is present in a stored response that If no explicit expiration time is present in a stored response that
has a status code whose definition allows heuristic freshness to be has a status code whose definition allows heuristic freshness to be
used (including the following in Section 8 of [Part2]: 200, 203, 206, used (including the following in Section 7 of [Part2]: 200, 203, 206,
300, 301 and 410), a cache MAY calculate a heuristic expiration time. 300, 301 and 410), a cache MAY calculate a heuristic expiration time.
A cache MUST NOT use heuristics to determine freshness for responses A cache MUST NOT use heuristics to determine freshness for responses
with status codes that do not explicitly allow it. with status codes that do not explicitly allow it.
When a heuristic is used to calculate freshness lifetime, a cache When a heuristic is used to calculate freshness lifetime, a cache
SHOULD attach a Warning header field with a 113 warn-code to the SHOULD attach a Warning header field with a 113 warn-code to the
response if its current_age is more than 24 hours and such a warning response if its current_age is more than 24 hours and such a warning
is not already present. is not already present.
Also, if the response has a Last-Modified header field (Section 2.2 Also, if the response has a Last-Modified header field (Section 2.2
of [Part4]), a cache SHOULD NOT use a heuristic expiration value that of [Part4]), caches are encouraged to use a heuristic expiration
is more than some fraction of the interval since that time. A value that is no more than some fraction of the interval since that
typical setting of this fraction might be 10%. time. A typical setting of this fraction might be 10%.
Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do
not calculate heuristic freshness for URIs with query components not calculate heuristic freshness for URIs with query components
(i.e., those containing '?'). In practice, this has not been (i.e., those containing '?'). In practice, this has not been
widely implemented. Therefore, servers are encouraged to send widely implemented. Therefore, servers are encouraged to send
explicit directives (e.g., Cache-Control: no-cache) if they wish explicit directives (e.g., Cache-Control: no-cache) if they wish
to preclude caching. to preclude caching.
2.3.2. Calculating Age 2.3.2. Calculating Age
skipping to change at page 14, line 6 skipping to change at page 14, line 19
The term "age_value" denotes the value of the Age header field The term "age_value" denotes the value of the Age header field
(Section 3.1), in a form appropriate for arithmetic operation; or (Section 3.1), in a form appropriate for arithmetic operation; or
0, if not available. 0, if not available.
date_value date_value
HTTP/1.1 requires origin servers to send a Date header field, if HTTP/1.1 requires origin servers to send a Date header field, if
possible, with every response, giving the time at which the possible, with every response, giving the time at which the
response was generated. The term "date_value" denotes the value response was generated. The term "date_value" denotes the value
of the Date header field, in a form appropriate for arithmetic of the Date header field, in a form appropriate for arithmetic
operations. See Section 9.3 of [Part1] for the definition of the operations. See Section 9.2 of [Part2] for the definition of the
Date header field, and for requirements regarding responses Date header field, and for requirements regarding responses
without it. without it.
now now
The term "now" means "the current value of the clock at the host The term "now" means "the current value of the clock at the host
performing the calculation". A cache SHOULD use NTP ([RFC1305]) performing the calculation". A cache SHOULD use NTP ([RFC1305])
or some similar protocol to synchronize its clocks to a globally or some similar protocol to synchronize its clocks to a globally
accurate time standard. accurate time standard.
skipping to change at page 15, line 8 skipping to change at page 15, line 21
corrected_initial_age = max(apparent_age, corrected_age_value); corrected_initial_age = max(apparent_age, corrected_age_value);
The current_age of a stored response can then be calculated by adding The current_age of a stored response can then be calculated by adding
the amount of time (in seconds) since the stored response was last the amount of time (in seconds) since the stored response was last
validated by the origin server to the corrected_initial_age. validated by the origin server to the corrected_initial_age.
resident_time = now - response_time; resident_time = now - response_time;
current_age = corrected_initial_age + resident_time; current_age = corrected_initial_age + resident_time;
Additional rules for requirements on parsing and encoding of dates Additionally, to avoid common problems in date parsing:
and other potential problems with date encodings include:
o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
which appears to be more than 50 years in the future is in fact in which appears to be more than 50 years in the future is in fact in
the past (this helps solve the "year 2000" problem). the past (this helps solve the "year 2000" problem).
o Although all date formats are specified to be case-sensitive, o Although all date formats are specified to be case-sensitive,
recipients SHOULD match day, week and timezone names case- recipients SHOULD match day, week and timezone names case-
insensitively. insensitively.
o An HTTP/1.1 implementation MAY internally represent a parsed o An HTTP/1.1 implementation MAY internally represent a parsed
skipping to change at page 15, line 44 skipping to change at page 16, line 7
A "stale" response is one that either has explicit expiry information A "stale" response is one that either has explicit expiry information
or is allowed to have heuristic expiry calculated, but is not fresh or is allowed to have heuristic expiry calculated, but is not fresh
according to the calculations in Section 2.3. according to the calculations in Section 2.3.
A cache MUST NOT return a stale response if it is prohibited by an A cache MUST NOT return a stale response if it is prohibited by an
explicit in-protocol directive (e.g., by a "no-store" or "no-cache" explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
cache directive, a "must-revalidate" cache-response-directive, or an cache directive, a "must-revalidate" cache-response-directive, or an
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
see Section 3.2.2). see Section 3.2.2).
A cache SHOULD NOT return stale responses unless it is disconnected A cache MUST NOT return stale responses unless it is disconnected
(i.e., it cannot contact the origin server or otherwise find a (i.e., it cannot contact the origin server or otherwise find a
forward path) or doing so is explicitly allowed (e.g., by the max- forward path) or doing so is explicitly allowed (e.g., by the max-
stale request directive; see Section 3.2.1). stale request directive; see Section 3.2.1).
A cache SHOULD append a Warning header field with the 110 warn-code A cache SHOULD append a Warning header field with the 110 warn-code
(see Section 3.6) to stale responses. Likewise, a cache SHOULD add (see Section 3.6) to stale responses. Likewise, a cache SHOULD add
the 112 warn-code to stale responses if the cache is disconnected. the 112 warn-code to stale responses if the cache is disconnected.
If a cache receives a first-hand response (either an entire response, If a cache receives a first-hand response (either an entire response,
or a 304 (Not Modified) response) that it would normally forward to or a 304 (Not Modified) response) that it would normally forward to
the requesting client, and the received response is no longer fresh, the requesting client, and the received response is no longer fresh,
the cache SHOULD forward it to the requesting client without adding a the cache can forward it to the requesting client without adding a
new Warning (but without removing any existing Warning header new Warning (but without removing any existing Warning header
fields). A cache SHOULD NOT attempt to validate a response simply fields). A cache shouldn't attempt to validate a response simply
because that response became stale in transit. because that response became stale in transit.
2.4. Validation Model 2.4. Validation Model
When a cache has one or more stored responses for a requested URI, When a cache has one or more stored responses for a requested URI,
but cannot serve any of them (e.g., because they are not fresh, or but cannot serve any of them (e.g., because they are not fresh, or
one cannot be selected; see Section 2.7), it can use the conditional one cannot be selected; see Section 2.7), it can use the conditional
request mechanism [Part4] in the forwarded request to give the origin request mechanism [Part4] in the forwarded request to give the origin
server an opportunity to both select a valid stored response to be server an opportunity to both select a valid stored response to be
used, and to update it. This process is known as "validating" or used, and to update it. This process is known as "validating" or
"revalidating" the stored response. "revalidating" the stored response.
When sending such a conditional request, a cache SHOULD add an If- When sending such a conditional request, a cache adds an If-Modified-
Modified-Since header field whose value is that of the Last-Modified Since header field whose value is that of the Last-Modified header
header field from the selected (see Section 2.7) stored response, if field from the selected (see Section 2.7) stored response, if
available. available.
Additionally, a cache SHOULD add an If-None-Match header field whose Additionally, a cache can add an If-None-Match header field whose
value is that of the ETag header field(s) from all responses stored value is that of the ETag header field(s) from all responses stored
for the requested URI, if present. However, if any of the stored for the requested URI, if present. However, if any of the stored
responses contains only partial content, the cache SHOULD NOT include responses contains only partial content, the cache shouldn't include
its entity-tag in the If-None-Match header field unless the request its entity-tag in the If-None-Match header field unless the request
is for a range that would be fully satisfied by that stored response. is for a range that would be fully satisfied by that stored response.
A 304 (Not Modified) response status code indicates that the stored Cache handling of a response to a conditional request is dependent
response can be updated and reused; see Section 2.9. upon its status code:
A full response (i.e., one with a response body) indicates that none o A 304 (Not Modified) response status code indicates that the
of the stored responses nominated in the conditional request is stored response can be updated and reused; see Section 2.4.1.
suitable. Instead, a cache SHOULD use the full response to satisfy
the request and MAY replace the stored response(s).
If a cache receives a 5xx response while attempting to validate a o A full response (i.e., one with a response body) indicates that
response, it MAY either forward this response to the requesting none of the stored responses nominated in the conditional request
client, or act as if the server failed to respond. In the latter is suitable. Instead, the cache can use the full response to
case, it MAY return a previously stored response (see Section 2.3.3). satisfy the request and MAY replace the stored response(s).
o However, if a cache receives a 5xx response while attempting to
validate a response, it can either forward this response to the
requesting client, or act as if the server failed to respond. In
the latter case, it can return a previously stored response (see
Section 2.3.3).
2.4.1. Freshening Responses
When a cache receives a 304 (Not Modified) response and already has
one or more stored 200 (OK) responses for the same cache key, the
cache needs to identify which of the stored responses are updated by
this new response and then update the stored response(s) with the new
information provided in the 304 response.
o If the new response contains a strong validator, then that strong
validator identifies the selected representation. All of the
stored responses with the same strong validator are selected. If
none of the stored responses contain the same strong validator,
then this new response corresponds to a new selected
representation and MUST NOT update the existing stored responses.
o If the new response contains a weak validator and that validator
corresponds to one of the cache's stored responses, then the most
recent of those matching stored responses is selected.
o If the new response does not include any form of validator, there
is only one stored response, and that stored response also lacks a
validator, then that stored response is selected.
If a stored response is selected for update, the cache MUST:
o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 3.6);
o retain any Warning header fields in the stored response with warn-
code 2xx; and,
o use other header fields provided in the 304 response to replace
all instances of the corresponding header fields in the stored
response.
2.5. Request Methods that Invalidate 2.5. Request Methods that Invalidate
Because unsafe request methods (Section 7.1.1 of [Part2]) such as Because unsafe request methods (Section 6.1.1 of [Part2]) such as
PUT, POST or DELETE have the potential for changing state on the PUT, POST or DELETE have the potential for changing state on the
origin server, intervening caches can use them to keep their contents origin server, intervening caches can use them to keep their contents
up-to-date. up-to-date.
A cache MUST invalidate the effective Request URI (Section 4.3 of A cache MUST invalidate the effective Request URI (Section 4.3 of
[Part1]) as well as the URI(s) in the Location and Content-Location [Part1]) as well as the URI(s) in the Location and Content-Location
header fields (if present) when a non-error response to a request header fields (if present) when a non-error response to a request
with an unsafe method is received. with an unsafe method is received.
However, a cache MUST NOT invalidate a URI from a Location or However, a cache MUST NOT invalidate a URI from a Location or
Content-Location header field if the host part of that URI differs Content-Location header field if the host part of that URI differs
from the host part in the effective request URI (Section 4.3 of from the host part in the effective request URI (Section 4.3 of
[Part1]). This helps prevent denial of service attacks. [Part1]). This helps prevent denial of service attacks.
A cache SHOULD invalidate the effective request URI (Section 4.3 of A cache MUST invalidate the effective request URI (Section 4.3 of
[Part1]) when it receives a non-error response to a request with a [Part1]) when it receives a non-error response to a request with a
method whose safety is unknown. method whose safety is unknown.
Here, a "non-error response" is one with a 2xx or 3xx status code. Here, a "non-error response" is one with a 2xx or 3xx status code.
"Invalidate" means that the cache will either remove all stored "Invalidate" means that the cache will either remove all stored
responses related to the effective request URI, or will mark these as responses related to the effective request URI, or will mark these as
"invalid" and in need of a mandatory validation before they can be "invalid" and in need of a mandatory validation before they can be
returned in response to a subsequent request. returned in response to a subsequent request.
Note that this does not guarantee that all appropriate responses are Note that this does not guarantee that all appropriate responses are
skipping to change at page 18, line 44 skipping to change at page 19, line 45
subsequent requests to that resource can only be properly interpreted subsequent requests to that resource can only be properly interpreted
by the origin server. by the origin server.
The stored response with matching selecting header fields is known as The stored response with matching selecting header fields is known as
the selected response. the selected response.
If multiple selected responses are available, the most recent If multiple selected responses are available, the most recent
response (as determined by the Date header field) is used; see response (as determined by the Date header field) is used; see
Section 2.2. Section 2.2.
If no selected response is available, the cache MAY forward the If no selected response is available, the cache can forward the
presented request to the origin server in a conditional request; see presented request to the origin server in a conditional request; see
Section 2.4. Section 2.4.
2.8. Combining Partial Content 2.8. Combining Partial Content
A response might transfer only a partial representation if the A response might transfer only a partial representation if the
connection closed prematurely or if the request used one or more connection closed prematurely or if the request used one or more
Range specifiers ([Part5]). After several such transfers, a cache Range specifiers ([Part5]). After several such transfers, a cache
might have received several ranges of the same representation. A might have received several ranges of the same representation. A
cache MAY combine these ranges into a single stored response, and cache MAY combine these ranges into a single stored response, and
skipping to change at page 19, line 23 skipping to change at page 20, line 29
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 3.6); code 1xx (see Section 3.6);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with warn-
code 2xx; and, code 2xx; and,
o use other header fields provided in the new response, aside from o use other header fields provided in the new response, aside from
Content-Range, to replace all instances of the corresponding Content-Range, to replace all instances of the corresponding
header fields in the stored response. header fields in the stored response.
2.9. Freshening Responses
When a cache receives a 304 (Not Modified) response and already has
one or more stored 200 (OK) responses for the same cache key, the
cache needs to identify which of the stored responses are updated by
this new response and then update the stored response(s) with the new
information provided in the 304 response.
o If the new response contains a strong validator, then that strong
validator identifies the selected representation. All of the
stored responses with the same strong validator are selected. If
none of the stored responses contain the same strong validator,
then this new response corresponds to a new selected
representation and MUST NOT update the existing stored responses.
o If the new response contains a weak validator and that validator
corresponds to one of the cache's stored responses, then the most
recent of those matching stored responses is selected.
o If the new response does not include any form of validator, there
is only one stored response, and that stored response also lacks a
validator, then that stored response is selected.
If a stored response is selected for update, the cache MUST:
o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 3.6);
o retain any Warning header fields in the stored response with warn-
code 2xx; and,
o use other header fields provided in the 304 response to replace
all instances of the corresponding header fields in the stored
response.
3. Header Field Definitions 3. Header Field Definitions
This section defines the syntax and semantics of HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
fields related to caching. fields related to caching.
3.1. Age 3.1. Age
The "Age" header field conveys the sender's estimate of the amount of The "Age" header field conveys the sender's estimate of the amount of
time since the response was generated or successfully validated at time since the response was generated or successfully validated at
the origin server. Age values are calculated as specified in the origin server. Age values are calculated as specified in
skipping to change at page 21, line 5 skipping to change at page 21, line 25
Note: HTTP/1.0 caches might not implement Cache-Control and might Note: HTTP/1.0 caches might not implement Cache-Control and might
only implement Pragma: no-cache (see Section 3.4). only implement Pragma: no-cache (see Section 3.4).
A proxy, whether or not it implements a cache, MUST pass cache A proxy, whether or not it implements a cache, MUST pass cache
directives through in forwarded messages, regardless of their directives through in forwarded messages, regardless of their
significance to that application, since the directives might be significance to that application, since the directives might be
applicable to all recipients along the request/response chain. It is applicable to all recipients along the request/response chain. It is
not possible to target a directive to a specific cache. not possible to target a directive to a specific cache.
Cache directives are identified by a token, to be compared case-
insensitively, and have an optional argument.
Cache-Control = 1#cache-directive Cache-Control = 1#cache-directive
cache-directive = cache-request-directive cache-directive = cache-request-directive
/ cache-response-directive / cache-response-directive
cache-extension = token [ "=" ( token / quoted-string ) ] cache-extension = token [ "=" ( token / quoted-string ) ]
3.2.1. Request Cache-Control Directives 3.2.1. Request Cache-Control Directives
cache-request-directive = cache-request-directive =
skipping to change at page 24, line 48 skipping to change at page 25, line 18
become stale, a cache MUST NOT use the response to satisfy become stale, a cache MUST NOT use the response to satisfy
subsequent requests without successful validation on the origin subsequent requests without successful validation on the origin
server. server.
The must-revalidate directive is necessary to support reliable The must-revalidate directive is necessary to support reliable
operation for certain protocol features. In all circumstances a operation for certain protocol features. In all circumstances a
cache MUST obey the must-revalidate directive; in particular, if a cache MUST obey the must-revalidate directive; in particular, if a
cache cannot reach the origin server for any reason, it MUST cache cannot reach the origin server for any reason, it MUST
generate a 504 (Gateway Timeout) response. generate a 504 (Gateway Timeout) response.
A server SHOULD send the must-revalidate directive if and only if The must-revalidate directive ought to be used by servers if and
failure to validate a request on the representation could result only if failure to validate a request on the representation could
in incorrect operation, such as a silently unexecuted financial result in incorrect operation, such as a silently unexecuted
transaction. financial transaction.
proxy-revalidate proxy-revalidate
The proxy-revalidate response directive has the same meaning as The proxy-revalidate response directive has the same meaning as
the must-revalidate response directive, except that it does not the must-revalidate response directive, except that it does not
apply to private caches. apply to private caches.
max-age max-age
The max-age response directive indicates that the response is to The max-age response directive indicates that the response is to
skipping to change at page 26, line 52 skipping to change at page 27, line 26
The "Expires" header field gives the date/time after which the The "Expires" header field gives the date/time after which the
response is considered stale. See Section 2.3 for further discussion response is considered stale. See Section 2.3 for further discussion
of the freshness model. of the freshness model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The field-value is an absolute date and time as defined by HTTP-date The field-value is an absolute date and time as defined by HTTP-date
in Section 6.1 of [Part1]; a sender MUST use the rfc1123-date format. in Section 8 of [Part2]; a sender MUST use the rfc1123-date format.
Expires = HTTP-date Expires = HTTP-date
For example For example
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
A cache MUST treat other invalid date formats, especially including A cache MUST treat other invalid date formats, especially including
the value "0", as in the past (i.e., "already expired"). the value "0", as in the past (i.e., "already expired").
skipping to change at page 27, line 26 skipping to change at page 27, line 49
Expires field. Likewise, the s-maxage directive overrides Expires Expires field. Likewise, the s-maxage directive overrides Expires
in shared caches. in shared caches.
Historically, HTTP required the Expires field-value to be no more Historically, HTTP required the Expires field-value to be no more
than a year in the future. While longer freshness lifetimes are no than a year in the future. While longer freshness lifetimes are no
longer prohibited, extremely large values have been demonstrated to longer prohibited, extremely large values have been demonstrated to
cause problems (e.g., clock overflows due to use of 32-bit integers cause problems (e.g., clock overflows due to use of 32-bit integers
for time values), and most caches will evict a response far sooner for time values), and most caches will evict a response far sooner
than that. Therefore, senders ought not produce them. than that. Therefore, senders ought not produce them.
An origin server without a clock MUST NOT assign Expires values to a
response unless these values were associated with the resource by a
system or user with a reliable clock. It MAY assign an Expires value
that is known, at or before server configuration time, to be in the
past (this allows "pre-expiration" of responses without storing
separate Expires values for each resource).
3.4. Pragma 3.4. Pragma
The "Pragma" header field allows backwards compatibility with The "Pragma" header field allows backwards compatibility with
HTTP/1.0 caches, so that clients can specify a "no-cache" request HTTP/1.0 caches, so that clients can specify a "no-cache" request
that they will understand (as Cache-Control was not defined until that they will understand (as Cache-Control was not defined until
HTTP/1.1). When the Cache-Control header is also present and HTTP/1.1). When the Cache-Control header is also present and
understood in a request, Pragma is ignored. understood in a request, Pragma is ignored.
In HTTP/1.0, Pragma was defined as an extensible field for In HTTP/1.0, Pragma was defined as an extensible field for
implementation-specified directives for recipients. This implementation-specified directives for recipients. This
specification deprecates such extensions to improve interoperability. specification deprecates such extensions to improve interoperability.
Pragma = 1#pragma-directive Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ] extension-pragma = token [ "=" ( token / quoted-string ) ]
When the Cache-Control header is not present in a request, the no- When the Cache-Control header is not present in a request, the no-
cache request pragma-directive MUST have the same effect on caches as cache request pragma-directive MUST have the same effect on caches as
if "Cache-Control: no-cache" were present (see Section 3.2.1). if "Cache-Control: no-cache" were present (see Section 3.2.1).
When sending a no-cache request, a client SHOULD include both pragma When sending a no-cache request, a client ought to include both the
and cache-control directives unless Cache-Control: no-cache is pragma and cache-control directives, unless Cache-Control: no-cache
purposefully omitted to target other Cache-Control response is purposefully omitted to target other Cache-Control response
directives at HTTP/1.1 caches. For example: directives at HTTP/1.1 caches. For example:
GET / HTTP/1.1 GET / HTTP/1.1
Host: www.example.com Host: www.example.com
Cache-Control: max-age=30 Cache-Control: max-age=30
Pragma: no-cache Pragma: no-cache
will constrain HTTP/1.1 caches to serve a response no older than 30 will constrain HTTP/1.1 caches to serve a response no older than 30
seconds, while precluding implementations that do not understand seconds, while precluding implementations that do not understand
Cache-Control from serving a cached response. Cache-Control from serving a cached response.
skipping to change at page 29, line 45 skipping to change at page 30, line 25
warn-text = quoted-string warn-text = quoted-string
warn-date = DQUOTE HTTP-date DQUOTE warn-date = DQUOTE HTTP-date DQUOTE
Multiple warnings can be attached to a response (either by the origin Multiple warnings can be attached to a response (either by the origin
server or by a cache), including multiple warnings with the same code server or by a cache), including multiple warnings with the same code
number, only differing in warn-text. number, only differing in warn-text.
When this occurs, the user agent SHOULD inform the user of as many of When this occurs, the user agent SHOULD inform the user of as many of
them as possible, in the order that they appear in the response. them as possible, in the order that they appear in the response.
Systems that generate multiple Warning header fields SHOULD order Systems that generate multiple Warning header fields are encouraged
them with this user agent behavior in mind. New Warning header to order them with this user agent behavior in mind. New Warning
fields SHOULD be added after any existing Warning headers fields. header fields are added after any existing Warning headers fields.
Warnings are assigned three digit warn-codes. The first digit Warnings are assigned three digit warn-codes. The first digit
indicates whether the Warning is required to be deleted from a stored indicates whether the Warning is required to be deleted from a stored
response after validation: response after validation:
o 1xx Warnings describe the freshness or validation status of the o 1xx Warnings describe the freshness or validation status of the
response, and so MUST be deleted by a cache after validation. response, and so MUST be deleted by a cache after validation.
They can only be generated by a cache when validating a cached They can only be generated by a cache when validating a cached
entry, and MUST NOT be generated in any other situation. entry, and MUST NOT be generated in any other situation.
skipping to change at page 30, line 45 skipping to change at page 31, line 25
stale. stale.
111 Revalidation failed 111 Revalidation failed
A cache SHOULD include this when returning a stale response A cache SHOULD include this when returning a stale response
because an attempt to validate the response failed, due to an because an attempt to validate the response failed, due to an
inability to reach the server. inability to reach the server.
112 Disconnected operation 112 Disconnected operation
A cache SHOULD b include this if it is intentionally disconnected A cache SHOULD include this if it is intentionally disconnected
from the rest of the network for a period of time. from the rest of the network for a period of time.
113 Heuristic expiration 113 Heuristic expiration
A cache SHOULD include this if it heuristically chose a freshness A cache SHOULD include this if it heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater lifetime greater than 24 hours and the response's age is greater
than 24 hours. than 24 hours.
199 Miscellaneous warning 199 Miscellaneous warning
skipping to change at page 33, line 7 skipping to change at page 33, line 37
Caches expose additional potential vulnerabilities, since the Caches expose additional potential vulnerabilities, since the
contents of the cache represent an attractive target for malicious contents of the cache represent an attractive target for malicious
exploitation. Because cache contents persist after an HTTP request exploitation. Because cache contents persist after an HTTP request
is complete, an attack on the cache can reveal information long after is complete, an attack on the cache can reveal information long after
a user believes that the information has been removed from the a user believes that the information has been removed from the
network. Therefore, cache contents need to be protected as sensitive network. Therefore, cache contents need to be protected as sensitive
information. information.
7. Acknowledgments 7. Acknowledgments
See Section 12 of [Part1]. See Section 11 of [Part1].
8. References 8. References
8.1. Normative References 8.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-16 and Message Parsing", draft-ietf-httpbis-p1-messaging-17
(work in progress), August 2011. (work in progress), October 2011.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-16 (work in Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
progress), August 2011. progress), October 2011.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-16 (work in Requests", draft-ietf-httpbis-p4-conditional-17 (work in
progress), August 2011. progress), October 2011.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-16 (work Partial Responses", draft-ietf-httpbis-p5-range-17 (work
in progress), August 2011. in progress), October 2011.
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
draft-ietf-httpbis-p7-auth-16 (work in progress), draft-ietf-httpbis-p7-auth-17 (work in progress),
August 2011. October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
8.2. Informative References 8.2. Informative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
skipping to change at page 34, line 48 skipping to change at page 35, line 33
Appendix B. Collected ABNF Appendix B. Collected ABNF
Age = delta-seconds Age = delta-seconds
Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] ) cache-directive ] )
Expires = HTTP-date Expires = HTTP-date
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] ) pragma-directive ] )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) ) ) )
Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
) )
cache-directive = cache-request-directive / cache-response-directive cache-directive = cache-request-directive / cache-response-directive
skipping to change at page 35, line 34 skipping to change at page 36, line 20
) / ( "s-maxage=" delta-seconds ) / cache-extension ) / ( "s-maxage=" delta-seconds ) / cache-extension
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
extension-pragma = token [ "=" ( token / quoted-string ) ] extension-pragma = token [ "=" ( token / quoted-string ) ]
field-name = <field-name, defined in [Part1], Section 3.2> field-name = <field-name, defined in [Part1], Section 3.2>
port = <port, defined in [Part1], Section 2.7> port = <port, defined in [Part1], Section 2.7>
pragma-directive = "no-cache" / extension-pragma pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, defined in [Part1], Section 9.9> pseudonym = <pseudonym, defined in [Part1], Section 8.8>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
token = <token, defined in [Part1], Section 3.2.3> token = <token, defined in [Part1], Section 3.2.3>
uri-host = <uri-host, defined in [Part1], Section 2.7> uri-host = <uri-host, defined in [Part1], Section 2.7>
warn-agent = ( uri-host [ ":" port ] ) / pseudonym warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE warn-date = DQUOTE HTTP-date DQUOTE
skipping to change at page 41, line 25 skipping to change at page 42, line 12
o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma" o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma"
C.17. Since draft-ietf-httpbis-p6-cache-15 C.17. Since draft-ietf-httpbis-p6-cache-15
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one- o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one-
year limit for Expires" year limit for Expires"
C.18. Since draft-ietf-httpbis-p6-cache-16
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/317>: "Cache-Control
directive case sensitivity"
Index Index
A A
age 6 age 6
Age header field 20 Age header field 20
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 21, 25 max-age 22, 25
max-stale 22 max-stale 22
min-fresh 22 min-fresh 22
must-revalidate 24 must-revalidate 25
no-cache 21, 23 no-cache 21, 24
no-store 21, 24 no-store 22, 24
no-transform 22, 25 no-transform 23, 25
only-if-cached 22 only-if-cached 23
private 23 private 23
proxy-revalidate 25 proxy-revalidate 25
public 23 public 23
s-maxage 25 s-maxage 25
cache entry 8 cache entry 8
cache key 8 cache key 8
Cache-Control header field 20 Cache-Control header field 21
cacheable 5 cacheable 5
E E
Expires header field 26 Expires header field 27
explicit expiration time 6 explicit expiration time 6
F F
first-hand 6 first-hand 6
fresh 6 fresh 6
freshness lifetime 6 freshness lifetime 6
G G
Grammar Grammar
Age 20 Age 20
Cache-Control 21 Cache-Control 21
cache-extension 21 cache-extension 21
cache-request-directive 21 cache-request-directive 21
cache-response-directive 23 cache-response-directive 23
delta-seconds 8 delta-seconds 8
Expires 27 Expires 27
extension-pragma 27 extension-pragma 28
Pragma 27 Pragma 28
pragma-directive 27 pragma-directive 28
Vary 28 Vary 29
warn-agent 29 warn-agent 30
warn-code 29 warn-code 30
warn-date 29 warn-date 30
warn-text 29 warn-text 30
Warning 29 Warning 30
warning-value 29 warning-value 30
H H
Header Fields Header Fields
Age 20 Age 20
Cache-Control 20 Cache-Control 21
Expires 26 Expires 27
Pragma 27 Pragma 28
Vary 28 Vary 28
Warning 29 Warning 29
heuristic expiration time 6 heuristic expiration time 6
M M
max-age max-age
Cache Directive 21, 25 Cache Directive 22, 25
max-stale max-stale
Cache Directive 22 Cache Directive 22
min-fresh min-fresh
Cache Directive 22 Cache Directive 22
must-revalidate must-revalidate
Cache Directive 24 Cache Directive 25
N N
no-cache no-cache
Cache Directive 21, 23
no-store
Cache Directive 21, 24 Cache Directive 21, 24
no-store
Cache Directive 22, 24
no-transform no-transform
Cache Directive 22, 25 Cache Directive 23, 25
O O
only-if-cached only-if-cached
Cache Directive 22 Cache Directive 23
P P
Pragma header field 27 Pragma header field 28
private private
Cache Directive 23 Cache Directive 23
private cache 5 private cache 5
proxy-revalidate proxy-revalidate
Cache Directive 25 Cache Directive 25
public public
Cache Directive 23 Cache Directive 23
S S
s-maxage s-maxage
skipping to change at page 45, line 26 skipping to change at page 46, line 26
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
EMail: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Mark Nottingham (editor) Mark Nottingham (editor)
Rackspace
EMail: mnot@mnot.net EMail: mnot@mnot.net
URI: http://www.mnot.net/ URI: http://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
 End of changes. 73 change blocks. 
171 lines changed or deleted 212 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/