draft-ietf-httpbis-p6-cache-15.txt   draft-ietf-httpbis-p6-cache-16.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: January 12, 2012 J. Mogul Expires: February 25, 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.
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
July 11, 2011 August 24, 2011
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-15 draft-ietf-httpbis-p6-cache-16
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypertext information
systems. This document is Part 6 of the seven-part specification systems. HTTP has been in use by the World Wide Web global
that defines the protocol referred to as "HTTP/1.1" and, taken information initiative since 1990. This document is Part 6 of the
together, obsoletes RFC 2616. Part 6 defines requirements on HTTP seven-part specification that defines the protocol referred to as
caches and the associated header fields that control cache behavior "HTTP/1.1" and, taken together, obsoletes RFC 2616.
or indicate cacheable response messages.
Part 6 defines requirements on HTTP caches and the associated header
fields that control cache behavior or indicate cacheable response
messages.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
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.16. The changes in this draft are summarized in Appendix C.17.
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 January 12, 2012. This Internet-Draft will expire on February 25, 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 9 skipping to change at page 3, line 14
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. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. ABNF Rules defined in other Parts of the 1.4.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 7 Specification . . . . . . . . . . . . . . . . . . . . 8
1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 8 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9
2.1.1. Storing Partial and Incomplete Responses . . . . . . . 9 2.2. Constructing Responses from Caches . . . . . . . . . . . . 10
2.2. Constructing Responses from Caches . . . . . . . . . . . . 9 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 14 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 16
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 15 2.6. Shared Caching of Authenticated Responses . . . . . . . . 17
2.6. Shared Caching of Authenticated Responses . . . . . . . . 16 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 18
2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16 2.8. Combining Partial Content . . . . . . . . . . . . . . . . 18
2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 17 2.9. Freshening Responses . . . . . . . . . . . . . . . . . . . 19
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 18 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
3.2.2. Response Cache-Control Directives . . . . . . . . . . 21 3.2.2. Response Cache-Control Directives . . . . . . . . . . 23
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31
5.2. Header Field Registration . . . . . . . . . . . . . . . . 30 5.2. Header Field Registration . . . . . . . . . . . . . . . . 32
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 32 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 34
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 34 publication) . . . . . . . . . . . . . . . . . . . . 36
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 34 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 36
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 35 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 35 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 37
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 37
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 37
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 38
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 38
C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37 C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39
C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37 C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 39
C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 38 C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40
C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38 C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 40
C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38 C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 40
C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 38 C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 40
C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 38 C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 41
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
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
An HTTP cache is a local store of response messages and the subsystem An HTTP cache is a local store of response messages and the subsystem
that controls its message storage, retrieval, and deletion. A cache that controls its message storage, retrieval, and deletion. A cache
stores cacheable responses in order to reduce the response time and stores cacheable responses in order to reduce the response time and
network bandwidth consumption on future, equivalent requests. Any network bandwidth consumption on future, equivalent requests. Any
client or server MAY employ a cache, though a cache cannot be used by client or server MAY employ a cache, though a cache cannot be used by
a server that is acting as a tunnel. a server that is acting as a tunnel.
Caching would be useless if it did not significantly improve The goal of caching in HTTP/1.1 is to significantly improve
performance. The goal of caching in HTTP/1.1 is to reuse a prior performance by reusing a prior response message to satisfy a current
response message to satisfy a current request. In some cases, a request. A stored response is considered "fresh", as defined in
stored response can be reused without the need for a network request, Section 2.3, if the response can be reused without "validation"
reducing latency and network round-trips; a "freshness" mechanism is (checking with the origin server to see if the cached response
used for this purpose (see Section 2.3). Even when a new request is remains valid for this request). A fresh cache response can
required, it is often possible to reuse all or parts of the payload therefore reduce both latency and network transfers each time it is
of a prior response to satisfy the request, thereby reducing network reused. When a cached response is not fresh, it might still be
bandwidth usage; a "validation" mechanism is used for this purpose reusable if it can be freshened by validation (Section 2.4) or if the
(see Section 2.4). origin is unavailable.
1.2. Terminology 1.2. Terminology
This specification uses a number of terms to refer to the roles This specification uses a number of terms to refer to the roles
played by participants in, and objects of, HTTP caching. played by participants in, and objects of, HTTP caching.
cache cache
A conformant implementation of a HTTP cache. Note that this A conformant implementation of a HTTP cache. Note that this
implies an HTTP/1.1 cache; this specification does not define implies an HTTP/1.1 cache; this specification does not define
conformance for HTTP/1.0 caches. conformance for HTTP/1.0 caches.
shared cache shared cache
A cache that is accessible to more than one user; usually (but not A cache that stores responses to be reused by more than one user;
always) deployed as part of an intermediary. usually (but not always) deployed as part of an intermediary.
private cache private cache
A cache that is dedicated to a single user. A cache that is dedicated to a single user.
cacheable cacheable
A response is cacheable if a cache is allowed to store a copy of A response is cacheable if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. the response message for use in answering subsequent requests.
Even when a response is cacheable, there might be additional Even when a response is cacheable, there might be additional
skipping to change at page 6, line 52 skipping to change at page 6, line 52
stale stale
A response is stale if its age has passed its freshness lifetime A response is stale if its age has passed its freshness lifetime
(either explicit or heuristic). (either explicit or heuristic).
validator validator
A protocol element (e.g., an entity-tag or a Last-Modified time) A protocol element (e.g., an entity-tag or a Last-Modified time)
that is used to find out whether a stored response is an that is used to find out whether a stored response is an
equivalent copy of a representation. equivalent copy of a representation. See Section 2.1 of [Part4].
strong validator
A validator that is defined by the origin server such that its
current value will change if the representation body changes;
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
that is strong in the sense defined by Section 2.2.2 of [Part4].
1.3. Requirements 1.3. Requirements
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 An implementation is not compliant if it fails to satisfy one or more
of the "MUST" or "REQUIRED" level requirements for the protocols it of the "MUST" or "REQUIRED" level requirements for the protocols it
implements. An implementation that satisfies all the "MUST" or implements. An implementation that satisfies all the "MUST" or
skipping to change at page 7, line 36 skipping to change at page 7, line 44
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), VCHAR (any visible USASCII character),
and WSP (whitespace). and WSP (whitespace).
1.4.1. Core Rules 1.4.1. Core Rules
The core rules below are defined in Section 1.2.2 of [Part1]: The core rules below are defined in [Part1]:
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
token = <token, defined in [Part1], Section 1.2.2>
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>
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 [Part1], Section 6.1>
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 9.9>
uri-host = <uri-host, defined in [Part1], Section 2.7> uri-host = <uri-host, defined in [Part1], Section 2.7>
skipping to change at page 8, line 21 skipping to change at page 8, line 31
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 SHOULD
use an arithmetic type of at least 31 bits of range, and senders MUST use an arithmetic type of at least 31 bits of range, and senders MUST
NOT send delta-seconds with a value greater than 2147483648. NOT send delta-seconds with a value greater than 2147483648.
2. Cache Operation 2. Cache Operation
Proper cache operation preserves the semantics of HTTP transfers
([Part2]) while eliminating the transfer of information already held
in the cache. Although caching is an entirely OPTIONAL feature of
HTTP, we assume that reusing the cached response is desirable and
that such reuse is the default behavior when no requirement or
locally-desired configuration prevents it. Therefore, HTTP cache
requirements are focused on preventing a cache from either storing a
non-reusable response or reusing a stored response inappropriately.
Each cache entry consists of a cache key and one or more HTTP
responses corresponding to prior requests that used the same key.
The most common form of cache entry is a successful result of a
retrieval request: i.e., a 200 (OK) response containing a
representation of the resource identified by the request target.
However, it is also possible to cache negative results (e.g., 404 not
found), incomplete results (e.g., 206 partial content), and responses
to safe methods other than GET if the method's definition allows such
caching and defines something suitable for use as a cache key.
The default cache key consists of the request method and target URI.
However, since HTTP caches in common use today are typically limited
to caching responses to GET, most implementations simply decline
other methods and use only the URI as the key.
If a request target is subject to content negotiation, its cache
entry might consist of multiple stored responses, each differentiated
by a secondary key for the values of the original request's selecting
header fields (Section 2.7).
2.1. Response Cacheability 2.1. Response Cacheability
A cache MUST NOT store a response to any request, unless: A cache MUST NOT store a response to any request, unless:
o The request method is understood by the cache and defined as being o The request method is understood by the cache and defined as being
cacheable, and cacheable, and
o the response status code is understood by the cache, and o the response status code is understood by the cache, and
o the "no-store" cache directive (see Section 3.2) does not appear o the "no-store" cache directive (see Section 3.2) does not appear
skipping to change at page 9, line 12 skipping to change at page 9, line 50
* contains a Cache Control Extension (see Section 3.2.3) that * contains a Cache Control Extension (see Section 3.2.3) that
allows it to be cached, or allows it to be cached, or
* has a status code that can be served with heuristic freshness * has a status code that can be served with heuristic freshness
(see Section 2.3.1.1). (see Section 2.3.1.1).
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.
In this context, a cache has "understood" a request method or a In this context, a cache has "understood" a request method or a
response status code if it recognises it and implements any cache- response status code if it recognizes it and implements any cache-
specific behavior. In particular, 206 Partial Content responses specific behavior.
cannot be cached by an implementation that does not handle partial
content (see Section 2.1.1).
Note that in normal operation, most caches will not store a response Note that, in normal operation, most caches will not store a response
that has neither a cache validator nor an explicit expiration time, that has neither a cache validator nor an explicit expiration time,
as such responses are not usually useful to store. However, caches as such responses are not usually useful to store. However, caches
are not prohibited from storing such responses. are not prohibited from storing such responses.
2.1.1. Storing Partial and Incomplete Responses A response message is considered complete when all of the octets
indicated by the message framing ([Part1]) are received prior to the
A cache that receives an incomplete response (for example, with fewer connection being closed. If the request is GET, the response status
bytes of data than specified in a Content-Length header field) can is 200 (OK), and the entire response header block has been received,
store the response, but MUST treat it as a partial response [Part5]. a cache MAY store an incomplete response message-body if the cache
Partial responses can be combined as described in Section 4 of entry is recorded as incomplete. Likewise, a 206 (Partial Content)
[Part5]; the result might be a full response or might still be response MAY be stored as if it were an incomplete 200 (OK) cache
partial. A cache MUST NOT return a partial response to a client entry. However, a cache MUST NOT store incomplete or partial content
without explicitly marking it as such using the 206 (Partial Content) responses if it does not support the Range and Content-Range header
status code. fields or if it does not understand the range units used in those
fields.
A cache that does not support the Range and Content-Range header A cache MAY complete a stored incomplete response by making a
fields MUST NOT store incomplete or partial responses. subsequent range request ([Part5]) and combining the successful
response with the stored entry, as defined in Section 2.8. A cache
MUST NOT use an incomplete response to answer requests unless the
response has been made complete or the request is partial and
specifies a range that is wholly within the incomplete response. A
cache MUST NOT send a partial response to a client without explicitly
marking it as such using the 206 (Partial Content) status code.
2.2. Constructing Responses from Caches 2.2. Constructing Responses from Caches
For a presented request, a cache MUST NOT return a stored response, For a presented request, a cache MUST NOT return a stored response,
unless: unless:
o The presented effective request URI (Section 4.3 of [Part1]) and o The presented effective request URI (Section 4.3 of [Part1]) and
that of the stored response match, and that of the stored response match, and
o the request method associated with the stored response allows it o the request method associated with the stored response allows it
skipping to change at page 12, line 22 skipping to change at page 13, line 19
used (including the following in Section 8 of [Part2]: 200, 203, 206, used (including the following in Section 8 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.1 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]), a cache SHOULD NOT use a heuristic expiration value that
is more than some fraction of the interval since that time. A is more than some fraction of the interval since that time. A
typical setting of this fraction might be 10%. 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.
skipping to change at page 14, line 16 skipping to change at page 15, line 8
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
and other potential problems with date encodings include:
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
the past (this helps solve the "year 2000" problem).
o Although all date formats are specified to be case-sensitive,
recipients SHOULD match day, week and timezone names case-
insensitively.
o An HTTP/1.1 implementation MAY internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the
proper value.
o All expiration-related calculations MUST be done in GMT. The
local time zone MUST NOT influence the calculation or comparison
of an age or expiration time.
o If an HTTP header field incorrectly carries a date value with a
time zone other than GMT, it MUST be converted into GMT using the
most conservative possible conversion.
2.3.3. Serving Stale Responses 2.3.3. Serving Stale Responses
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;
skipping to change at page 15, line 19 skipping to change at page 16, line 36
available. available.
Additionally, a cache SHOULD add an If-None-Match header field whose Additionally, a cache SHOULD 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 SHOULD NOT 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 A 304 (Not Modified) response status code indicates that the stored
response can be updated and reused; see Section 2.8. response can be updated and reused; see Section 2.9.
A full response (i.e., one with a response body) indicates that none A full response (i.e., one with a response body) indicates that none
of the stored responses nominated in the conditional request is of the stored responses nominated in the conditional request is
suitable. Instead, a cache SHOULD use the full response to satisfy suitable. Instead, a cache SHOULD use the full response to satisfy
the request and MAY replace the stored response. the request and MAY replace the stored response(s).
If a cache receives a 5xx response while attempting to validate a If a cache receives a 5xx response while attempting to validate a
response, it MAY either forward this response to the requesting response, it MAY either forward this response to the requesting
client, or act as if the server failed to respond. In the latter client, or act as if the server failed to respond. In the latter
case, it MAY return a previously stored response (see Section 2.3.3). case, it MAY return a previously stored response (see Section 2.3.3).
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 7.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
skipping to change at page 17, line 30 skipping to change at page 18, line 48
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 MAY 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 Responses 2.8. Combining Partial Content
When a cache receives a 304 (Not Modified) response or a 206 (Partial A response might transfer only a partial representation if the
Content) response (in this section, the "new" response"), it needs to connection closed prematurely or if the request used one or more
create an updated response by combining the stored response with the Range specifiers ([Part5]). After several such transfers, a cache
new one, so that the updated response can be used to satisfy the might have received several ranges of the same representation. A
request, and potentially update the cached response. cache MAY combine these ranges into a single stored response, and
reuse that response to satisfy later requests, if they all share the
same strong validator and the cache complies with the client
requirements in Section 4 of [Part5].
If the new response contains an ETag, it identifies the stored When combining the new response with one or more stored responses, a
response to use. [[TODO-mention-CL: might need language about cache MUST:
Content-Location here]][[TODO-select-for-combine: Shouldn't this be
the selected response?]]
When the new response's status code is 206 (partial content), a cache o delete any Warning header fields in the stored response with warn-
MUST NOT combine it with the old response if either response does not code 1xx (see Section 3.6);
have a validator, and MUST NOT combine it with the old response when
those validators do not match with the strong comparison function
(see Section 2.2.2 of [Part4]).
The stored response header fields are used as those of the updated o retain any Warning header fields in the stored response with warn-
response, except that code 2xx; and,
o a cache MUST delete any stored Warning header fields with warn-
code 1xx (see Section 3.6).
o a cache MUST retain any stored Warning header fields with warn- o use other header fields provided in the new response, aside from
code 2xx. Content-Range, to replace all instances of the corresponding
header fields in the stored response.
o a cache MUST use other header fields provided in the new response 2.9. Freshening Responses
to replace all instances of the corresponding header fields from
the stored response.
A cache MUST use the updated response header fields to replace those When a cache receives a 304 (Not Modified) response and already has
of the stored response (unless the stored response is removed). In one or more stored 200 (OK) responses for the same cache key, the
the case of a 206 response, a cache MAY store the combined cache needs to identify which of the stored responses are updated by
representation. 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
skipping to change at page 25, line 11 skipping to change at page 27, line 11
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 6.1 of [Part1]; 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
the value "0", as in the past (i.e., "already expired").
Note: If a response includes a Cache-Control field with the max- Note: If a response includes a Cache-Control field with the max-
age directive (see Section 3.2.2), that directive overrides the age directive (see Section 3.2.2), that directive overrides the
Expires field. Likewise, the s-maxage directive overrides Expires Expires field. Likewise, the s-maxage directive overrides Expires
in shared caches. in shared caches.
A server SHOULD NOT send Expires dates more than one year in the Historically, HTTP required the Expires field-value to be no more
future. than a year in the future. While longer freshness lifetimes are no
longer prohibited, extremely large values have been demonstrated to
A cache MUST treat other invalid date formats, especially including cause problems (e.g., clock overflows due to use of 32-bit integers
the value "0", as in the past (i.e., "already expired"). for time values), and most caches will evict a response far sooner
than that. Therefore, senders ought not produce them.
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
skipping to change at page 31, line 7 skipping to change at page 33, line 7
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
Much of the content and presentation of the caching design is due to See Section 12 of [Part1].
suggestions and comments from individuals including: Shel Kaphan,
Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
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-15 and Message Parsing", draft-ietf-httpbis-p1-messaging-16
(work in progress), July 2011. (work in progress), August 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-15 (work in Semantics", draft-ietf-httpbis-p2-semantics-16 (work in
progress), July 2011. progress), August 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-15 (work in Requests", draft-ietf-httpbis-p4-conditional-16 (work in
progress), July 2011. progress), August 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-15 (work Partial Responses", draft-ietf-httpbis-p5-range-16 (work
in progress), July 2011. in progress), August 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-15 (work in progress), draft-ietf-httpbis-p7-auth-16 (work in progress),
July 2011. August 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 33, line 40 skipping to change at page 35, line 36
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 9.9>
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
token = <token, defined in [Part1], Section 1.2.2> 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
warn-text = quoted-string warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
] ]
skipping to change at page 39, line 13 skipping to change at page 41, line 13
o <http://tools.ietf.org/wg/httpbis/trac/ticket/38>: "Mismatch Vary" o <http://tools.ietf.org/wg/httpbis/trac/ticket/38>: "Mismatch Vary"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/235>: "Cache o <http://tools.ietf.org/wg/httpbis/trac/ticket/235>: "Cache
Invalidation only happens upon successful responses" Invalidation only happens upon successful responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
minimum sizes for protocol elements" minimum sizes for protocol elements"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/289>: "Proxies don't o <http://tools.ietf.org/wg/httpbis/trac/ticket/289>: "Proxies don't
'understand' methods" 'understand' methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/291>: "Cache
Extensions can override no-store, etc."
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
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one-
year limit for Expires"
Index Index
A A
age 6 age 6
Age header field 18 Age header field 20
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 20, 23 max-age 21, 25
max-stale 20 max-stale 22
min-fresh 20 min-fresh 22
must-revalidate 22 must-revalidate 24
no-cache 19, 21 no-cache 21, 23
no-store 19, 22 no-store 21, 24
no-transform 20, 23 no-transform 22, 25
only-if-cached 20 only-if-cached 22
private 21 private 23
proxy-revalidate 23 proxy-revalidate 25
public 21 public 23
s-maxage 23 s-maxage 25
Cache-Control header field 18 cache entry 8
cache key 8
Cache-Control header field 20
cacheable 5 cacheable 5
E E
Expires header field 24 Expires header field 26
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 18 Age 20
Cache-Control 19 Cache-Control 21
cache-extension 19 cache-extension 21
cache-request-directive 19 cache-request-directive 21
cache-response-directive 21 cache-response-directive 23
delta-seconds 8 delta-seconds 8
Expires 25 Expires 27
extension-pragma 25 extension-pragma 27
Pragma 25 Pragma 27
pragma-directive 25 pragma-directive 27
Vary 26 Vary 28
warn-agent 27 warn-agent 29
warn-code 27 warn-code 29
warn-date 27 warn-date 29
warn-text 27 warn-text 29
Warning 27 Warning 29
warning-value 27 warning-value 29
H H
Header Fields Header Fields
Age 18 Age 20
Cache-Control 18 Cache-Control 20
Expires 24 Expires 26
Pragma 25 Pragma 27
Vary 26 Vary 28
Warning 27 Warning 29
heuristic expiration time 6 heuristic expiration time 6
M M
max-age max-age
Cache Directive 20, 23 Cache Directive 21, 25
max-stale max-stale
Cache Directive 20 Cache Directive 22
min-fresh min-fresh
Cache Directive 20
must-revalidate
Cache Directive 22 Cache Directive 22
must-revalidate
Cache Directive 24
N N
no-cache no-cache
Cache Directive 19, 21 Cache Directive 21, 23
no-store no-store
Cache Directive 19, 22 Cache Directive 21, 24
no-transform no-transform
Cache Directive 20, 23 Cache Directive 22, 25
O O
only-if-cached only-if-cached
Cache Directive 20 Cache Directive 22
P P
Pragma header field 25 Pragma header field 27
private private
Cache Directive 21 Cache Directive 23
private cache 5 private cache 5
proxy-revalidate proxy-revalidate
Cache Directive 23 Cache Directive 25
public public
Cache Directive 21 Cache Directive 23
S S
s-maxage s-maxage
Cache Directive 23 Cache Directive 25
shared cache 5 shared cache 5
stale 6 stale 6
strong validator 7
V V
validator 6 validator 6
Vary header field 26 strong 7
Vary header field 28
W W
Warning header field 27 Warning header field 29
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
 End of changes. 66 change blocks. 
199 lines changed or deleted 308 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/