draft-ietf-httpbis-p6-cache-08.txt   draft-ietf-httpbis-p6-cache-09.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: April 29, 2010 J. Mogul Expires: September 9, 2010 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
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
October 26, 2009 March 8, 2010
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-08 draft-ietf-httpbis-p6-cache-09
Status of this Memo Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. This document is Part 6 of the seven-part specification
that defines the protocol referred to as "HTTP/1.1" and, taken
together, obsoletes RFC 2616. 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)
Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.10.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The Hypertext Transfer Protocol (HTTP) is an application-level described in the BSD License.
protocol for distributed, collaborative, hypermedia information
systems. This document is Part 6 of the seven-part specification
that defines the protocol referred to as "HTTP/1.1" and, taken
together, obsoletes RFC 2616. 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)
Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.9. This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
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 . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 7
2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7
2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8
2.2. Constructing Responses from Caches . . . . . . . . . . . . 8 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14
2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15
2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18
3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5.1. Message Header Registration . . . . . . . . . . . . . . . 28 5.1. Message Header Registration . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Compatibility with Previous Versions . . . . . . . . 30 Appendix A. Compatibility with Previous Versions . . . . . . . . 30
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 30
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 30
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 33 publication) . . . . . . . . . . . . . . . . . . . . 32
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 32
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 32
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 33
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 33
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 34
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35
C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 35
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
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.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
port = <port, defined in [Part1], Section 2.6> port = <port, defined in [Part1], Section 2.6>
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.6> uri-host = <uri-host, defined in [Part1], Section 2.6>
2. Cache Operation 2. Cache Operation
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 defined as being cacheable, and o The request method is understood by the cache and defined as being
cacheable, 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
in request or response headers, and in request or response headers, and
o the "private" cache response directive (see Section 3.2 does not o the "private" cache response directive (see Section 3.2.2 does not
appear in the response, if the cache is shared, and appear in the response, if the cache is shared, and
o the "Authorization" header (see Section 3.1 of [Part7]) does not o the "Authorization" header (see Section 3.1 of [Part7]) does not
appear in the request, if the cache is shared (unless the "public" appear in the request, if the cache is shared (unless the "public"
directive is present; see Section 3.2), and directive is present; see Section 3.2), and
o the cache understands partial responses, if the response is o the response either:
partial or incomplete (see Section 2.1.1).
* contains an Expires header (see Section 3.3), or
* contains a max-age response cache directive (see
Section 3.2.2), or
* contains a s-maxage response cache directive and the cache is
shared, or
* contains a Cache Control Extension (see Section 3.2.3) that
allows it to be cached, or
* has a status code that can be served with heuristic freshness
(see Section 2.3.1.1).
In this context, a cache has "understood" a request method or a
response status code if it recognises it and implements any cache-
specific behaviour. In particular, 206 Partial Content responses
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 2.1.1. Storing Partial and Incomplete Responses
A cache that receives an incomplete response (for example, with fewer A cache that receives an incomplete response (for example, with fewer
bytes of data than specified in a Content-Length header) can store bytes of data than specified in a Content-Length header) can store
skipping to change at page 9, line 25 skipping to change at page 9, line 47
* allowed to be served stale (see Section 2.3.3), or * allowed to be served stale (see Section 2.3.3), or
* successfully validated (see Section 2.4). * successfully validated (see Section 2.4).
[[TODO-method-cacheability: define method cacheability for GET, HEAD [[TODO-method-cacheability: define method cacheability for GET, HEAD
and POST in p2-semantics.]] and POST in p2-semantics.]]
When a stored response is used to satisfy a request, caches MUST When a stored response is used to satisfy a request, caches MUST
include a single Age header field (Section 3.1) in the response with include a single Age header field (Section 3.1) in the response with
a value equal to the stored response's current_age; see a value equal to the stored response's current_age; see
Section 2.3.2. [[anchor1: DISCUSS: this currently includes Section 2.3.2. [[DISCUSS-includes-validated: this currently includes
successfully validated responses.]] successfully validated responses.]]
Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST
be written through the cache to the origin server; i.e., A cache must be written through the cache to the origin server; i.e., a cache must
not reply to such a request before having forwarded the request and not reply to such a request before having forwarded the request and
having received a corresponding response. 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.
Caches MUST use the most recent response (as determined by the Date Caches MUST use the most recent response (as determined by the Date
header) when more than one suitable response is stored. They can header) when more than one suitable response is stored. They can
also forward a request with "Cache-Control: max-age=0" or "Cache- 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 10, line 12 skipping to change at page 10, line 34
server to provide an explicit expiration time in the future, using server to provide an explicit expiration time in the future, using
either the Expires header (Section 3.3) or the max-age response cache either the Expires header (Section 3.3) or the max-age response cache
directive (Section 3.2.2). Generally, origin servers will assign directive (Section 3.2.2). Generally, origin servers will assign
future explicit expiration times to responses in the belief that the future explicit expiration times to responses in the belief that the
entity is not likely to change in a semantically significant way entity is not likely to change in a semantically significant way
before the expiration time is reached. before the expiration time is reached.
If an origin server wishes to force a cache to validate every If an origin server wishes to force a cache to validate every
request, it can assign an explicit expiration time in the past. This request, it can assign an explicit expiration time in the past. This
means that the response is always stale, so that caches should means that the response is always stale, so that caches should
validate it before using it for subsequent requests. [[anchor2: This validate it before using it for subsequent requests. [[TODO-
wording may cause confusion, because the response may still be served response-stale: This wording may cause confusion, because the
stale.]] response may still be served stale.]]
Since origin servers do not always provide explicit expiration times, Since origin servers do not always provide explicit expiration times,
HTTP caches may also assign heuristic expiration times when they are HTTP caches may also assign heuristic expiration times when they are
not specified, employing algorithms that use other header values not specified, employing algorithms that use other header values
(such as the Last-Modified time) to estimate a plausible expiration (such as the Last-Modified time) to estimate a plausible expiration
time. The HTTP/1.1 specification does not provide specific time. The HTTP/1.1 specification does not provide specific
algorithms, but does impose worst-case constraints on their results. algorithms, but does impose worst-case constraints on their results.
The calculation to determine if a response is fresh is: The calculation to determine if a response is fresh is:
response_is_fresh = (freshness_lifetime > current_age) response_is_fresh = (freshness_lifetime > current_age)
The freshness_lifetime is defined in Section 2.3.1; the current_age The freshness_lifetime is defined in Section 2.3.1; the current_age
is defined in Section 2.3.2. is defined in Section 2.3.2.
Additionally, clients may need to influence freshness calculation. Additionally, clients may need to influence freshness calculation.
They can do this using several request cache directives, with the They can do this using several request cache directives, with the
effect of either increasing or loosening constraints on freshness. effect of either increasing or loosening constraints on freshness.
See Section 3.2.1. See Section 3.2.1.
[[anchor3: ISSUE: there are not requirements directly applying to [[ISSUE-no-req-for-directives: there are not requirements directly
cache-request-directives and freshness.]] applying to cache-request-directives and freshness.]]
Note that freshness applies only to cache operation; it cannot be Note that freshness applies only to cache operation; it cannot be
used to force a user agent to refresh its display or reload a used to force a user agent to refresh its display or reload a
resource. See Section 4 for an explanation of the difference between resource. See Section 4 for an explanation of the difference between
caches and history mechanisms. caches and history mechanisms.
2.3.1. Calculating Freshness Lifetime 2.3.1. Calculating Freshness Lifetime
A cache can calculate the freshness lifetime (denoted as A cache can calculate the freshness lifetime (denoted as
freshness_lifetime) of a response by using the first match of: freshness_lifetime) of a response by using the first match of:
skipping to change at page 11, line 34 skipping to change at page 12, line 6
When a heuristic is used to calculate freshness lifetime, the cache When a heuristic is used to calculate freshness lifetime, the cache
SHOULD attach a Warning header with a 113 warn-code to the response SHOULD attach a Warning header with a 113 warn-code to the response
if its current_age is more than 24 hours and such a warning is not if its current_age is more than 24 hours and such a warning is not
already present. already present.
Also, if the response has a Last-Modified header (Section 6.6 of Also, if the response has a Last-Modified header (Section 6.6 of
[Part4]), the heuristic expiration value SHOULD be no more than some [Part4]), the heuristic expiration value SHOULD be no more than some
fraction of the interval since that time. A typical setting of this fraction of the interval since that time. A typical setting of this
fraction might be 10%. fraction might be 10%.
[[anchor4: REVIEW: took away HTTP/1.0 query string heuristic [[REVIEW-query-string-heuristics: took away HTTP/1.0 query string
uncacheability.]] heuristic uncacheability.]]
2.3.2. Calculating Age 2.3.2. Calculating Age
HTTP/1.1 uses the Age response-header to convey the estimated age of HTTP/1.1 uses the Age response-header to convey the estimated age of
the response message when obtained from a cache. The Age field value the response message when obtained from a cache. The Age field value
is the cache's estimate of the amount of time since the response was is the cache's estimate of the amount of time since the response was
generated or validated by the origin server. In essence, the Age generated or validated by the origin server. In essence, the Age
value is the sum of the time that the response has been resident in value is the sum of the time that the response has been resident in
each of the caches along the path from the origin server, plus the each of the caches along the path from the origin server, plus the
amount of time it has been in transit along network paths. amount of time it has been in transit along network paths.
skipping to change at page 14, line 26 skipping to change at page 14, line 37
contains only partial content, its entity-tag SHOULD NOT be included contains only partial content, its entity-tag SHOULD NOT be included
in the If-None-Match header field unless the request is for a range in the If-None-Match header field unless the request is for a range
that would be fully satisfied by that stored response. 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.7. response can be updated and reused; see Section 2.7.
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, the full response is used both to satisfy the suitable. Instead, the full response is used both to satisfy the
request and replace the stored response. [[anchor5: Should there be a request and replace the stored response. [[TODO-req-missing: Should
requirement here?]] there be a requirement here?]]
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 methods (Section 7.1.1 of [Part2]) have the potential Because unsafe methods (Section 7.1.1 of [Part2]) have the potential
for changing state on the origin server, intervening caches can use for changing state on the origin server, intervening caches can use
skipping to change at page 15, line 7 skipping to change at page 15, line 18
o DELETE o DELETE
o POST o POST
An invalidation based on a URI from a Location or Content-Location An invalidation based on a URI from a Location or Content-Location
header MUST NOT be performed if the host part of that URI differs header MUST NOT be performed if the host part of that URI differs
from the host part in the Request-URI. This helps prevent denial of from the host part in the Request-URI. This helps prevent denial of
service attacks. service attacks.
[[anchor6: TODO: "host part" needs to be specified better.]] [[TODO-def-host-part: "host part" needs to be specified better.]]
A cache that passes through requests for methods it does not A cache that passes through requests for methods it does not
understand SHOULD invalidate the Request-URI. understand SHOULD invalidate the Request-URI.
Here, "invalidate" means that the cache will either remove all stored Here, "invalidate" means that the cache will either remove all stored
responses related to the Request-URI, or will mark these as "invalid" responses related to the Request-URI, or will mark these as "invalid"
and in need of a mandatory validation before they can be returned in and in need of a mandatory validation before they can be returned in
response to a subsequent request. 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
invalidated. For example, the request that caused the change at the invalidated. For example, the request that caused the change at the
origin server might not have gone through the cache where a response origin server might not have gone through the cache where a response
is stored. is stored.
[[anchor7: TODO: specify that only successful (2xx, 3xx?) responses [[TODO-spec-success-invalidate: specify that only successful (2xx,
invalidate.]] 3xx?) responses invalidate.]]
2.6. Caching Negotiated Responses 2.6. Caching Negotiated Responses
When a cache receives a request that can be satisfied by a stored When a cache receives a request that can be satisfied by a stored
response that has a Vary header field (Section 3.5), it MUST NOT use response that has a Vary header field (Section 3.5), it MUST NOT use
that response unless all of the selecting request-headers nominated that response unless all of the selecting request-headers nominated
by the Vary header match in both the original request (i.e., that by the Vary header match in both the original request (i.e., that
associated with the stored response), and the presented request. associated with the stored response), and the presented request.
The selecting request-headers from two requests are defined to match The selecting request-headers from two requests are defined to match
if and only if the selecting request-headers in the first request can if and only if those in the first request can be transformed to those
be transformed to the selecting request-headers in the second request in the second request by applying any of the following:
by adding or removing linear white space [[anchor8: [ref]]] at places
where this is allowed by the corresponding ABNF, and/or combining
multiple message-header fields with the same field name following the
rules about header fields in Section 3.2 of [Part1].
If a header field is absent from a request, it can only match another o adding or removing whitespace, where allowed in the header's
request if it is also absent there. syntax
o combining multiple message-header fields with the same field name
(see Section 3.2 of [Part1])
o normalizing both header values in a way that is known to have
identical semantics, according to the header's specification
(e.g., re-ordering field values when order is not significant;
case-normalization, where values are defined to be case-
insensitive)
If (after any normalisation that may take place) a header field is
absent from a request, it can only match another request if it is
also absent there.
A Vary header field-value of "*" always fails to match, and A Vary header field-value of "*" always fails to match, and
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 request-headers is known The stored response with matching selecting request-headers is known
as the selected response. as the selected response.
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
skipping to change at page 16, line 16 skipping to change at page 16, line 38
2.7. Combining Responses 2.7. Combining Responses
When a cache receives a 304 (Not Modified) response or a 206 (Partial When a cache receives a 304 (Not Modified) response or a 206 (Partial
Content) response (in this section, the "new" response"), it needs to Content) response (in this section, the "new" response"), it needs to
created an updated response by combining the stored response with the created an updated response by combining the stored response with the
new one, so that the updated response can be used to satisfy the new one, so that the updated response can be used to satisfy the
request. request.
If the new response contains an ETag, it identifies the stored If the new response contains an ETag, it identifies the stored
response to use. [[anchor9: may need language about Content-Location response to use. [[TODO-mention-CL: may need language about Content-
here]][[anchor10: cover case where INM with multiple etags was sent]] Location here]][[TODO-inm-mult-etags: cover case where INM with
multiple etags was sent]]
If the status code is 206 (partial content), both the stored and new If the status code is 206 (partial content), both the stored and new
responses MUST have validators, and those validators MUST match using responses MUST have validators, and those validators MUST match using
the strong comparison function (see Section 4 of [Part4]). the strong comparison function (see Section 4 of [Part4]).
Otherwise, the responses MUST NOT be combined. Otherwise, the responses MUST NOT be combined.
The stored response headers are used as those of the updated The stored response headers are used as those of the updated
response, except that response, except that
o any stored Warning headers with warn-code 1xx (see Section 3.6) o any stored Warning headers with warn-code 1xx (see Section 3.6)
skipping to change at page 16, line 40 skipping to change at page 17, line 15
o any stored Warning headers with warn-code 2xx MUST be retained in o any stored Warning headers with warn-code 2xx MUST be retained in
the stored response and the updated response. the stored response and the updated response.
o any headers provided in the new response MUST replace the o any headers provided in the new response MUST replace the
corresponding headers from the stored response. corresponding headers from the stored response.
If a header field-name in the new response matches more than one If a header field-name in the new response matches more than one
header in the stored response, all such stored headers MUST be header in the stored response, all such stored headers MUST be
replaced. replaced.
The updated response can [[[[anchor11: requirement?]]]] be used to The updated response can [[TODO-is-req: requirement?]] be used to
replace the stored response in cache. In the case of a 206 response, replace the stored response in cache. In the case of a 206 response,
the combined entity-body MAY be stored. the combined entity-body MAY be stored.
[[anchor12: ISSUE: discuss how to handle HEAD updates]] [[ISSUE-how-head: discuss how to handle HEAD updates]]
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.
For entity-header fields, both sender and recipient refer to either For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the the client or the server, depending on who sends and who receives the
entity. entity.
skipping to change at page 19, line 13 skipping to change at page 19, line 32
client is not willing to accept a stale response. client is not willing to accept a stale response.
max-stale max-stale
The max-stale request directive indicates that the client is The max-stale request directive indicates that the client is
willing to accept a response that has exceeded its expiration willing to accept a response that has exceeded its expiration
time. If max-stale is assigned a value, then the client is time. If max-stale is assigned a value, then the client is
willing to accept a response that has exceeded its expiration time willing to accept a response that has exceeded its expiration time
by no more than the specified number of seconds. If no value is by no more than the specified number of seconds. If no value is
assigned to max-stale, then the client is willing to accept a assigned to max-stale, then the client is willing to accept a
stale response of any age. [[anchor13: of any staleness? --mnot]] stale response of any age. [[TODO-staleness: of any staleness?
--mnot]]
min-fresh min-fresh
The min-fresh request directive indicates that the client is The min-fresh request directive indicates that the client is
willing to accept a response whose freshness lifetime is no less willing to accept a response whose freshness lifetime is no less
than its current age plus the specified time in seconds. That is, than its current age plus the specified time in seconds. That is,
the client wants a response that will still be fresh for at least the client wants a response that will still be fresh for at least
the specified number of seconds. the specified number of seconds.
no-transform no-transform
skipping to change at page 20, line 42 skipping to change at page 20, line 50
If the private response directive specifies one or more field- If the private response directive specifies one or more field-
names, this requirement is limited to the field-values associated names, this requirement is limited to the field-values associated
with the listed response headers. That is, the specified field- with the listed response headers. That is, the specified field-
names(s) MUST NOT be stored by a shared cache, whereas the names(s) MUST NOT be stored by a shared cache, whereas the
remainder of the response message MAY be. remainder of the response message MAY be.
Note: This usage of the word private only controls where the Note: This usage of the word private only controls where the
response may be stored, and cannot ensure the privacy of the response may be stored, and cannot ensure the privacy of the
message content. Also, private response directives with field- message content. Also, private response directives with field-
names are often handled by implementations as if an unqualified names are often handled by implementations as if an unqualified
private directive was recieved; i.e., the special handling for the private directive was received; i.e., the special handling for the
qualified form is not widely implemented. qualified form is not widely implemented.
no-cache no-cache
The no-cache response directive indicates that the response MUST The no-cache response directive indicates that the response MUST
NOT be used to satisfy a subsequent request without successful NOT be used to satisfy a subsequent request without successful
validation on the origin server. This allows an origin server to validation on the origin server. This allows an origin server to
prevent caching even by caches that have been configured to return prevent caching even by caches that have been configured to return
stale responses. stale responses.
skipping to change at page 21, line 17 skipping to change at page 21, line 25
with the listed response headers. That is, the specified field- with the listed response headers. That is, the specified field-
name(s) MUST NOT be sent in the response to a subsequent request name(s) MUST NOT be sent in the response to a subsequent request
without successful validation on the origin server. This allows without successful validation on the origin server. This allows
an origin server to prevent the re-use of certain header fields in an origin server to prevent the re-use of certain header fields in
a response, while still allowing caching of the rest of the a response, while still allowing caching of the rest of the
response. response.
Note: Most HTTP/1.0 caches will not recognize or obey this Note: Most HTTP/1.0 caches will not recognize or obey this
directive. Also, no-cache response directives with field-names directive. Also, no-cache response directives with field-names
are often handled by implementations as if an unqualified no-cache are often handled by implementations as if an unqualified no-cache
directive was recieved; i.e., the special handling for the directive was received; i.e., the special handling for the
qualified form is not widely implemented. qualified form is not widely implemented.
no-store no-store
The no-store response directive indicates that a cache MUST NOT The no-store response directive indicates that a cache MUST NOT
store any part of either the immediate request or response. This store any part of either the immediate request or response. This
directive applies to both non-shared and shared caches. "MUST NOT directive applies to both non-shared and shared caches. "MUST NOT
store" in this context means that the cache MUST NOT intentionally store" in this context means that the cache MUST NOT intentionally
store the information in non-volatile storage, and MUST make a store the information in non-volatile storage, and MUST make a
best-effort attempt to remove the information from volatile best-effort attempt to remove the information from volatile
skipping to change at page 23, line 41 skipping to change at page 24, line 4
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]; it MUST be sent in rfc1123-date format. in Section 6.1 of [Part1]; it MUST be sent in rfc1123-date format.
Expires = "Expires" ":" OWS Expires-v Expires = "Expires" ":" OWS Expires-v
Expires-v = HTTP-date Expires-v = HTTP-date
For example For example
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
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.
HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in
the future. the future.
HTTP/1.1 clients and caches MUST treat other invalid date formats, HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already especially including the value "0", as in the past (i.e., "already
expired"). expired").
skipping to change at page 24, line 29 skipping to change at page 24, line 39
When the no-cache directive is present in a request message, an When the no-cache directive is present in a request message, an
application SHOULD forward the request toward the origin server even application SHOULD forward the request toward the origin server even
if it has a cached copy of what is being requested. This pragma if it has a cached copy of what is being requested. This pragma
directive has the same semantics as the no-cache response directive directive has the same semantics as the no-cache response directive
(see Section 3.2.2) and is defined here for backward compatibility (see Section 3.2.2) and is defined here for backward compatibility
with HTTP/1.0. Clients SHOULD include both header fields when a no- with HTTP/1.0. Clients SHOULD include both header fields when a no-
cache request is sent to a server not known to be HTTP/1.1 compliant. cache request is sent to a server not known to be HTTP/1.1 compliant.
HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
sent "Cache-Control: no-cache". sent "Cache-Control: no-cache".
Note: because the meaning of "Pragma: no-cache" as a response- Note: Because the meaning of "Pragma: no-cache" as a response-
header field is not actually specified, it does not provide a header field is not actually specified, it does not provide a
reliable replacement for "Cache-Control: no-cache" in a response. reliable replacement for "Cache-Control: no-cache" in a response.
This mechanism is deprecated; no new Pragma directives will be This mechanism is deprecated; no new Pragma directives will be
defined in HTTP. defined in HTTP.
3.5. Vary 3.5. Vary
The "Vary" response-header field conveys the set of request-header The "Vary" response-header field conveys the set of request-header
fields that were used to select the representation. fields that were used to select the representation.
Caches use this information, in part, to determine whether a stored Caches use this information, in part, to determine whether a stored
response can be used to satisdy a given request; see Section 2.6. response can be used to satisfy a given request; see Section 2.6.
determines, while the response is fresh, whether a cache is permitted determines, while the response is fresh, whether a cache is permitted
to use the response to reply to a subsequent request without to use the response to reply to a subsequent request without
validation; see Section 2.6. validation; see Section 2.6.
In uncacheable or stale responses, the Vary field value advises the In uncacheable or stale responses, the Vary field value advises the
user agent about the criteria that were used to select the user agent about the criteria that were used to select the
representation. representation.
Vary = "Vary" ":" OWS Vary-v Vary = "Vary" ":" OWS Vary-v
Vary-v = "*" / 1#field-name Vary-v = "*" / 1#field-name
skipping to change at page 25, line 41 skipping to change at page 25, line 51
The "Warning" general-header field is used to carry additional The "Warning" general-header field is used to carry additional
information about the status or transformation of a message that information about the status or transformation of a message that
might not be reflected in the message. This information is typically might not be reflected in the message. This information is typically
used to warn about possible incorrectness introduced by caching used to warn about possible incorrectness introduced by caching
operations or transformations applied to the entity body of the operations or transformations applied to the entity body of the
message. message.
Warnings can be used for other purposes, both cache-related and Warnings can be used for other purposes, both cache-related and
otherwise. The use of a warning, rather than an error status code, otherwise. The use of a warning, rather than an error status code,
distinguish these responses from true failures. distinguishes these responses from true failures.
Warning headers can in general be applied to any message, however Warning headers can in general be applied to any message, however
some warn-codes are specific to caches and can only be applied to some warn-codes are specific to caches and can only be applied to
response messages. response messages.
Warning = "Warning" ":" OWS Warning-v Warning = "Warning" ":" OWS Warning-v
Warning-v = 1#warning-value Warning-v = 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date] [SP warn-date]
skipping to change at page 28, line 12 skipping to change at page 28, line 17
The warning text can include arbitrary information to be presented The warning text can include arbitrary information to be presented
to a human user, or logged. A system receiving this warning MUST to a human user, or logged. A system receiving this warning MUST
NOT take any automated action. NOT take any automated action.
4. History Lists 4. History Lists
User agents often have history mechanisms, such as "Back" buttons and User agents often have history mechanisms, such as "Back" buttons and
history lists, that can be used to redisplay an entity retrieved history lists, that can be used to redisplay an entity retrieved
earlier in a session. earlier in a session.
History mechanisms and caches are different. In particular history The freshness model (Section 2.3) does not necessarily apply to
mechanisms SHOULD NOT try to show a correct view of the current state history mechanisms. I.e., a history mechanism can display a previous
of a resource. Rather, a history mechanism is meant to show exactly representation even if it has expired.
what the user saw at the time when the resource was retrieved.
By default, an expiration time does not apply to history mechanisms.
If the entity is still in storage, a history mechanism SHOULD display
it even if the entity has expired, unless the user has specifically
configured the agent to refresh expired history documents.
This is not to be construed to prohibit the history mechanism from
telling the user that a view might be stale.
Note: if history list mechanisms unnecessarily prevent users from This does not prohibit the history mechanism from telling the user
viewing stale resources, this will tend to force service authors that a view might be stale, or from honoring cache directives (e.g.,
to avoid using HTTP expiration controls and cache controls when Cache-Control: no-store).
they would otherwise like to. Service authors may consider it
important that users not be presented with error messages or
warning messages when they use navigation controls (such as BACK)
to view previously fetched resources. Even though sometimes such
resources ought not be cached, or ought to expire quickly, user
interface considerations may force service authors to resort to
other means of preventing caching (e.g. "once-only" URLs) in order
not to suffer the effects of improperly functioning history
mechanisms.
5. IANA Considerations 5. IANA Considerations
5.1. Message Header Registration 5.1. Message Header Registration
The Message Header Registry located at <http://www.iana.org/ The Message Header Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> should be assignments/message-headers/message-header-index.html> should be
updated with the permanent registrations below (see [RFC3864]): updated with the permanent registrations below (see [RFC3864]):
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
skipping to change at page 29, line 42 skipping to change at page 29, line 24
suggestions and comments from individuals including: Shel Kaphan, suggestions and comments from individuals including: Shel Kaphan,
Paul Leach, Koen Holtman, David Morris, and Larry Masinter. 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-08 and Message Parsing", draft-ietf-httpbis-p1-messaging-09
(work in progress), October 2009. (work in progress), March 2010.
[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-08 (work in Semantics", draft-ietf-httpbis-p2-semantics-09 (work in
progress), October 2009. progress), March 2010.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-08
(work in progress), October 2009.
[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-08 (work in Requests", draft-ietf-httpbis-p4-conditional-09 (work in
progress), October 2009. progress), March 2010.
[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-08 (work Partial Responses", draft-ietf-httpbis-p5-range-09 (work
in progress), October 2009. in progress), March 2010.
[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-08 (work in progress), draft-ietf-httpbis-p7-auth-09 (work in progress),
October 2009. March 2010.
[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 31, line 4 skipping to change at page 30, line 25
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
Appendix A. Compatibility with Previous Versions Appendix A. Compatibility with Previous Versions
A.1. Changes from RFC 2068 A.1. Changes from RFC 2068
A case was missed in the Cache-Control model of HTTP/1.1; s-maxage A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
was introduced to add this missing case. (Sections 2.1, 3.2). was introduced to add this missing case. (Sections 2.1, 3.2).
Transfer-coding and message lengths all interact in ways that
required fixing exactly when chunked encoding is used (to allow for
transfer encoding that may not be self delimiting); it was important
to straighten out exactly how message lengths are computed. (see also
[Part1], [Part3] and [Part5]) [[anchor16: This used to refer to the
text about non-modifiable headers, and will have to be updated later
on. --jre]]
Proxies should be able to add Content-Length when appropriate.
[[anchor17: This used to refer to the text about non-modifiable
headers, and will have to be updated later on. --jre]]
Range request responses would become very verbose if all meta-data Range request responses would become very verbose if all meta-data
were always returned; by allowing the server to only send needed were always returned; by allowing the server to only send needed
headers in a 206 response, this problem can be avoided. headers in a 206 response, this problem can be avoided.
(Section 2.7) (Section 2.7)
The Cache-Control: max-age directive was not properly defined for The Cache-Control: max-age directive was not properly defined for
responses. (Section 3.2.2) responses. (Section 3.2.2)
Warnings could be cached incorrectly, or not updated appropriately. Warnings could be cached incorrectly, or not updated appropriately.
(Section 2.3, 2.7, 3.2, and 3.6) Warning also needed to be a general (Section 2.3, 2.7, 3.2, and 3.6) Warning also needed to be a general
skipping to change at page 36, line 21 skipping to change at page 35, line 33
o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content-
Location on 304 responses" Location on 304 responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and
no-cache CC directives with headers" no-cache CC directives with headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and
warn-text" warn-text"
C.10. Since draft-ietf-httpbis-p6-cache-08
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/147>: "serving
negotiated responses from cache: header-specific canonicalization"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/197>: "Effect of CC
directives on history lists"
Affected issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes
and caching
Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
13.5.1 and 13.5.2"
Index Index
A A
age 6 age 6
Age header 17 Age header 17
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 18, 22 max-age 19, 22
max-stale 19 max-stale 19
min-fresh 19 min-fresh 19
must-revalidate 21 must-revalidate 21
no-cache 18, 20 no-cache 18, 21
no-store 18, 21 no-store 18, 21
no-transform 19, 22 no-transform 19, 22
only-if-cached 19 only-if-cached 19
private 20 private 20
proxy-revalidate 21 proxy-revalidate 22
public 20 public 20
s-maxage 22 s-maxage 22
Cache-Control header 17 Cache-Control header 18
cacheable 5 cacheable 5
E E
Expires header 23 Expires header 23
explicit expiration time 5 explicit expiration time 5
F F
first-hand 6 first-hand 6
fresh 6 fresh 6
freshness lifetime 6 freshness lifetime 6
skipping to change at page 37, line 22 skipping to change at page 37, line 5
cache-extension 18 cache-extension 18
cache-request-directive 18 cache-request-directive 18
cache-response-directive 20 cache-response-directive 20
delta-seconds 17 delta-seconds 17
Expires 23 Expires 23
Expires-v 23 Expires-v 23
extension-pragma 24 extension-pragma 24
Pragma 24 Pragma 24
pragma-directive 24 pragma-directive 24
Pragma-v 24 Pragma-v 24
Vary 24 Vary 25
Vary-v 24 Vary-v 25
warn-agent 26 warn-agent 26
warn-code 26 warn-code 26
warn-date 26 warn-date 26
warn-text 26 warn-text 26
Warning 26 Warning 26
Warning-v 26 Warning-v 26
warning-value 26 warning-value 26
H H
Headers Headers
Age 17 Age 17
Cache-Control 17 Cache-Control 18
Expires 23 Expires 23
Pragma 24 Pragma 24
Vary 24 Vary 24
Warning 25 Warning 25
heuristic expiration time 5 heuristic expiration time 5
M M
max-age max-age
Cache Directive 18, 22 Cache Directive 19, 22
max-stale max-stale
Cache Directive 19 Cache Directive 19
min-fresh min-fresh
Cache Directive 19 Cache Directive 19
must-revalidate must-revalidate
Cache Directive 21 Cache Directive 21
N N
no-cache no-cache
Cache Directive 18, 20 Cache Directive 18, 21
no-store no-store
Cache Directive 18, 21 Cache Directive 18, 21
no-transform no-transform
Cache Directive 19, 22 Cache Directive 19, 22
O O
only-if-cached only-if-cached
Cache Directive 19 Cache Directive 19
P P
Pragma header 24 Pragma header 24
private private
Cache Directive 20 Cache Directive 20
proxy-revalidate proxy-revalidate
Cache Directive 21 Cache Directive 22
public public
Cache Directive 20 Cache Directive 20
S S
s-maxage s-maxage
Cache Directive 22 Cache Directive 22
stale 6 stale 6
V V
validator 6 validator 6
 End of changes. 61 change blocks. 
158 lines changed or deleted 181 lines changed or added

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