draft-ietf-httpbis-p6-cache-07.txt   draft-ietf-httpbis-p6-cache-08.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: January 14, 2010 J. Mogul Expires: April 29, 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
July 13, 2009 October 26, 2009
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-07 draft-ietf-httpbis-p6-cache-08
Status of this Memo 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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 January 14, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 44 skipping to change at page 2, line 44
or indicate cacheable response messages. 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). The current issues list is 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 at <http://tools.ietf.org/wg/httpbis/trac/report/11> 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.8. The changes in this draft are summarized in Appendix C.9.
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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 . . . . . . . . . . . . 8
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . 17 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . 31 Appendix A. Compatibility with Previous Versions . . . . . . . . 30
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31
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) . . . . . . . . . . . . . . . . . . . . 33
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34
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 . . . . . . . . . . . 35
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35
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
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 7, line 38 skipping to change at page 7, line 38
The core rules below are defined in Section 1.2.2 of [Part1]: The core rules below are defined in Section 1.2.2 of [Part1]:
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
token = <token, 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>
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 4.2> field-name = <field-name, defined in [Part1], Section 3.2>
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
port = <port, defined in [Part1], Section 2.1> port = <port, defined in [Part1], Section 2.6>
pseudonym = <pseudonym, defined in [Part1], Section 8.9> pseudonym = <pseudonym, defined in [Part1], Section 9.9>
uri-host = <uri-host, defined in [Part1], Section 2.1> 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 defined as being cacheable, 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 8, line 47 skipping to change at page 8, line 47
MUST NOT store incomplete or partial responses. MUST NOT store incomplete or partial responses.
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 Request-URI and that of the stored response match o The presented Request-URI and that of the stored response match
([[TODO-Request-URI: Need to find a new term for this, as Part 1 ([[TODO-Request-URI: Need to find a new term for this, as Part 1
doesn't define Request-URI anymore; the new term request-target doesn't define Request-URI anymore; the new term request-target
does not work for this.]]), and does not work for this. (see
<http://tools.ietf.org/wg/httpbis/trac/ticket/196>)]]), and
o the request method associated with the stored response allows it o the request method associated with the stored response allows it
to be used for the presented request, and to be used for the presented request, and
o selecting request-headers nominated by the stored response (if o selecting request-headers nominated by the stored response (if
any) match those presented (see Section 2.6), and any) match those presented (see Section 2.6), and
o the presented request and stored response are free from directives o the presented request and stored response are free from directives
that would prevent its use (see Section 3.2 and Section 3.4), and that would prevent its use (see Section 3.2 and Section 3.4), and
o the stored response is either: o the stored response is either:
skipping to change at page 11, line 51 skipping to change at page 11, line 51
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.
The term "age_value" denotes the value of the Age header, in a form The term "age_value" denotes the value of the Age header, in a form
appropriate for arithmetic operations. appropriate for arithmetic operations.
HTTP/1.1 requires origin servers to send a Date header, if possible, HTTP/1.1 requires origin servers to send a Date header, if possible,
with every response, giving the time at which the response was with every response, giving the time at which the response was
generated (see Section 8.3 of [Part1]). The term "date_value" generated (see Section 9.3 of [Part1]). The term "date_value"
denotes the value of the Date header, in a form appropriate for denotes the value of the Date header, in a form appropriate for
arithmetic operations. arithmetic operations.
The term "now" means "the current value of the clock at the host The term "now" means "the current value of the clock at the host
performing the calculation." Hosts that use HTTP, but especially performing the calculation." Hosts that use HTTP, but especially
hosts running origin servers and caches, SHOULD use NTP [RFC1305] or hosts running origin servers and caches, SHOULD use NTP [RFC1305] or
some similar protocol to synchronize their clocks to a globally some similar protocol to synchronize their clocks to a globally
accurate time standard. accurate time standard.
A response's age can be calculated in two entirely independent ways: A response's age can be calculated in two entirely independent ways:
skipping to change at page 14, line 34 skipping to change at page 14, line 34
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. [[anchor5: Should there be a
requirement here?]] 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).
If a cache receives a successful response whose Content-Location
field matches that of an existing stored response for the same
Request-URI, whose entity-tag differs from that of the existing
stored response, and whose Date is more recent than that of the
existing response, the existing response SHOULD NOT be returned in
response to future requests and SHOULD be deleted from the cache.
[[anchor6: DISCUSS: Not sure if this is necessary.]]
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
them to keep their contents up-to-date. them to keep their contents up-to-date.
The following HTTP methods MUST cause a cache to invalidate the The following HTTP methods MUST cause a cache to invalidate the
Request-URI as well as the URI(s) in the Location and Content- Request-URI as well as the URI(s) in the Location and Content-
Location headers (if present): Location headers (if present):
skipping to change at page 15, line 16 skipping to change at page 15, line 7
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.
[[anchor7: TODO: "host part" needs to be specified better.]] [[anchor6: TODO: "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.
[[anchor8: TODO: specify that only successful (2xx, 3xx?) responses [[anchor7: TODO: specify that only successful (2xx, 3xx?) responses
invalidate.]] 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 the selecting request-headers in the first request can
be transformed to the selecting request-headers in the second request be transformed to the selecting request-headers in the second request
by adding or removing linear white space [[anchor9: [ref]]] at places by adding or removing linear white space [[anchor8: [ref]]] at places
where this is allowed by the corresponding ABNF, and/or combining where this is allowed by the corresponding ABNF, and/or combining
multiple message-header fields with the same field name following the multiple message-header fields with the same field name following the
rules about message headers in Section 4.2 of [Part1]. rules about header fields in Section 3.2 of [Part1].
If a header field is absent from a request, it can only match another If a header field is absent from a request, it can only match another
request if it is also absent there. 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.
skipping to change at page 16, line 25 skipping to change at page 16, line 16
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. [[anchor10: may need language about Content-Location response to use. [[anchor9: may need language about Content-Location
here]][[anchor11: cover case where INM with multiple etags was sent]] here]][[anchor10: 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 ETags, and those ETags MUST match using the responses MUST have validators, and those validators MUST match using
strong comparison function (see Section 4 of [Part4]). Otherwise, the strong comparison function (see Section 4 of [Part4]).
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)
MUST be deleted from the stored response and the updated response. MUST be deleted from the stored response and the updated response.
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 [[[[anchor12: requirement?]]]] be used to The updated response can [[[[anchor11: 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.
[[anchor13: ISSUE: discuss how to handle HEAD updates]] [[anchor12: ISSUE: 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.
3.1. Age 3.1. Age
The response-header field "Age" conveys the sender's estimate of the The "Age" response-header field conveys the sender's estimate of the
amount of time since the response (or its validation) was generated amount of time since the response was generated or successfully
at the origin server. Age values are calculated as specified in validated at the origin server. Age values are calculated as
Section 2.3.2. specified in Section 2.3.2.
Age = "Age" ":" OWS Age-v Age = "Age" ":" OWS Age-v
Age-v = delta-seconds Age-v = delta-seconds
Age field-values are non-negative integers, representing time in Age field-values are non-negative integers, representing time in
seconds. seconds.
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
If a cache receives a value larger than the largest positive integer If a cache receives a value larger than the largest positive integer
it can represent, or if any of its age calculations overflows, it it can represent, or if any of its age calculations overflows, it
MUST transmit an Age header with a field-value of 2147483648 (2^31). MUST transmit an Age header with a field-value of 2147483648 (2^31).
Caches SHOULD use an arithmetic type of at least 31 bits of range. Caches SHOULD use an arithmetic type of at least 31 bits of range.
The presence of an Age header field in a response implies that a The presence of an Age header field in a response implies that a
response is not first-hand. However, the converse is not true, since response is not first-hand. However, the converse is not true, since
HTTP/1.0 caches may not implement the Age header field. HTTP/1.0 caches may not implement the Age header field.
3.2. Cache-Control 3.2. Cache-Control
The general-header field "Cache-Control" is used to specify The "Cache-Control" general-header field is used to specify
directives that MUST be obeyed by all caches along the request/ directives that MUST be obeyed by all caches along the request/
response chain. The directives specify behavior intended to prevent response chain. Such cache directives are unidirectional in that the
caches from adversely interfering with the request or response. presence of a directive in a request does not imply that the same
Cache directives are unidirectional in that the presence of a directive is to be given in the response.
directive in a request does not imply that the same directive is to
be given in the response.
Note that HTTP/1.0 caches might not implement Cache-Control and Note that HTTP/1.0 caches might not implement Cache-Control and
might only implement Pragma: no-cache (see Section 3.4). might only implement Pragma: no-cache (see Section 3.4).
Cache directives MUST be passed through by a proxy or gateway Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives might be applicable to all recipients along the since the directives might be applicable to all recipients along the
request/response chain. It is not possible to target a directive to request/response chain. It is not possible to target a directive to
a specific cache. a specific cache.
skipping to change at page 19, line 21 skipping to change at page 19, line 13
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. [[anchor14: of any staleness? --mnot]] stale response of any age. [[anchor13: 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 40 skipping to change at page 20, line 40
cache. A private (non-shared) cache MAY store the response. cache. A private (non-shared) cache MAY store the response.
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. message content. Also, private response directives with field-
names are often handled by implementations as if an unqualified
private directive was recieved; i.e., the special handling for the
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.
If the no-cache response directive specifies one or more field- If the no-cache 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-
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. directive. Also, no-cache response directives with field-names
are often handled by implementations as if an unqualified no-cache
directive was recieved; i.e., the special handling for the
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
storage as promptly as possible after forwarding it. storage as promptly as possible after forwarding it.
skipping to change at page 23, line 17 skipping to change at page 23, line 24
behavior. behavior.
Unrecognized cache directives MUST be ignored; it is assumed that any Unrecognized cache directives MUST be ignored; it is assumed that any
cache directive likely to be unrecognized by an HTTP/1.1 cache will cache directive likely to be unrecognized by an HTTP/1.1 cache will
be combined with standard directives (or the response's default be combined with standard directives (or the response's default
cacheability) such that the cache behavior will remain minimally cacheability) such that the cache behavior will remain minimally
correct even if the cache does not understand the extension(s). correct even if the cache does not understand the extension(s).
3.3. Expires 3.3. Expires
The entity-header field "Expires" gives the date/time after which the The "Expires" entity-header field gives the date/time after which the
response is considered stale. See Section 2.3 for further discussion response is considered stale. See Section 2.3 for further discussion
of the freshness model. of the freshness model.
The presence of an Expires field does not imply that the original The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that resource will change or cease to exist at, before, or after that
time. time.
The field-value is an absolute date and time as defined by HTTP-date The field-value is an absolute date and time as defined by HTTP-date
in Section 3.2 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
skipping to change at page 23, line 49 skipping to change at page 24, line 8
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").
3.4. Pragma 3.4. Pragma
The general-header field "Pragma" is used to include implementation- The "Pragma" general-header field is used to include implementation-
specific directives that might apply to any recipient along the specific directives that might apply to any recipient along the
request/response chain. All pragma directives specify optional request/response chain. All pragma directives specify optional
behavior from the viewpoint of the protocol; however, some systems behavior from the viewpoint of the protocol; however, some systems
MAY require that behavior be consistent with the directives. MAY require that behavior be consistent with the directives.
Pragma = "Pragma" ":" OWS Pragma-v Pragma = "Pragma" ":" OWS Pragma-v
Pragma-v = 1#pragma-directive Pragma-v = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ] extension-pragma = token [ "=" ( token / quoted-string ) ]
skipping to change at page 24, line 31 skipping to change at page 24, line 38
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's value indicates the set of The "Vary" response-header field conveys the set of request-header
request-header fields that determines, while the response is fresh, fields that were used to select the representation.
whether a cache is permitted to use the response to reply to a
subsequent request without validation; see Section 2.6. Caches use this information, in part, to determine whether a stored
response can be used to satisdy a given request; see Section 2.6.
determines, while the response is fresh, whether a cache is permitted
to use the response to reply to a subsequent request without
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
The set of header fields named by the Vary field value is known as The set of header fields named by the Vary field value is known as
the selecting request-headers. the selecting request-headers.
skipping to change at page 25, line 21 skipping to change at page 25, line 32
therefore, a cache cannot determine whether this response is therefore, a cache cannot determine whether this response is
appropriate. The "*" value MUST NOT be generated by a proxy server; appropriate. The "*" value MUST NOT be generated by a proxy server;
it may only be generated by an origin server. it may only be generated by an origin server.
The field-names given are not limited to the set of standard request- The field-names given are not limited to the set of standard request-
header fields defined by this specification. Field names are case- header fields defined by this specification. Field names are case-
insensitive. insensitive.
3.6. Warning 3.6. Warning
The general-header field "Warning" 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. distinguish these responses from true failures.
skipping to change at page 25, line 51 skipping to change at page 26, line 20
warn-code = 3DIGIT warn-code = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym warn-agent = ( uri-host [ ":" port ] ) / pseudonym
; the name or pseudonym of the server adding ; the name or pseudonym of the server adding
; the Warning header, for use in debugging ; the Warning header, for use in debugging
warn-text = quoted-string warn-text = quoted-string
warn-date = DQUOTE HTTP-date DQUOTE warn-date = DQUOTE HTTP-date DQUOTE
Multiple warnings can be attached to a response (either by the origin Multiple warnings can be attached to a response (either by the origin
server or by a cache), including multiple warnings with the same code server or by a cache), including multiple warnings with the same code
number. For example, a server might provide the same warning with number, only differing in warn-text.
texts in both English and Basque.
When this occurs, the user agent SHOULD inform the user of as many of When this occurs, the user agent SHOULD inform the user of as many of
them as possible, in the order that they appear in the response. If them as possible, in the order that they appear in the response.
it is not possible to inform the user of all of the warnings, the
user agent SHOULD follow these heuristics:
o Warnings that appear early in the response take priority over
those appearing later in the response.
o Warnings in the user's preferred character set take priority over
warnings in other character sets but with identical warn-codes and
warn-agents.
Systems that generate multiple Warning headers SHOULD order them with Systems that generate multiple Warning headers SHOULD order them with
this user agent behavior in mind. New Warning headers SHOULD be this user agent behavior in mind. New Warning headers SHOULD be
added after any existing Warning headers. added after any existing Warning headers.
Warnings are assigned three digit warn-codes. The first digit Warnings are assigned three digit warn-codes. The first digit
indicates whether the Warning is required to be deleted from a stored indicates whether the Warning is required to be deleted from a stored
response after validation: response after validation:
o 1xx Warnings that describe the freshness or validation status of o 1xx Warnings describe the freshness or validation status of the
the response, and so MUST be deleted by caches after validation. response, and so MUST be deleted by caches after validation. They
They MUST NOT be generated by a cache except when validating a can only be generated by a cache when validating a cached entry,
cached entry, and MUST NOT be generated by clients. and MUST NOT be generated in any other situation.
o 2xx Warnings that describe some aspect of the entity body or o 2xx Warnings describe some aspect of the entity body or entity
entity headers that is not rectified by a validation (for example, headers that is not rectified by a validation (for example, a
a lossy compression of the entity bodies) and MUST NOT be deleted lossy compression of the entity bodies) and MUST NOT be deleted by
by caches after validation, unless a full response is returned, in caches after validation, unless a full response is returned, in
which case they MUST be. which case they MUST be.
The warn-text SHOULD be in a natural language and character set that
is most likely to be intelligible to the human user receiving the
response. This decision can be based on any available knowledge,
such as the location of the cache or user, the Accept-Language field
in a request, the Content-Language field in a response, etc. The
default language is English and the default character set is ISO-
8859-1 ([ISO-8859-1]).
If a character set other than ISO-8859-1 is used, it MUST be encoded
in the warn-text using the method described in [RFC2047].
If an implementation sends a message with one or more Warning headers If an implementation sends a message with one or more Warning headers
to a receiver whose version is HTTP/1.0 or lower, then the sender to a receiver whose version is HTTP/1.0 or lower, then the sender
MUST include in each warning-value a warn-date that matches the Date MUST include in each warning-value a warn-date that matches the Date
header in the message. header in the message.
If an implementation receives a message with a warning-value that If an implementation receives a message with a warning-value that
includes a warn-date, and that warn-date is different from the Date includes a warn-date, and that warn-date is different from the Date
value in the response, then that warning-value MUST be deleted from value in the response, then that warning-value MUST be deleted from
the message before storing, forwarding, or using it. (preventing the the message before storing, forwarding, or using it. (preventing the
consequences of naive caching of Warning header fields.) If all of consequences of naive caching of Warning header fields.) If all of
skipping to change at page 29, line 39 skipping to change at page 29, line 39
7. Acknowledgments 7. Acknowledgments
Much of the content and presentation of the caching design is due to Much of the content and presentation of the caching design is due to
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
[ISO-8859-1]
International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998.
[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-07 and Message Parsing", draft-ietf-httpbis-p1-messaging-08
(work in progress), July 2009. (work in progress), October 2009.
[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-07 (work in Semantics", draft-ietf-httpbis-p2-semantics-08 (work in
progress), July 2009. progress), October 2009.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] 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 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-07 and Content Negotiation", draft-ietf-httpbis-p3-payload-08
(work in progress), July 2009. (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-07 (work in Requests", draft-ietf-httpbis-p4-conditional-08 (work in
progress), July 2009. progress), October 2009.
[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-07 (work Partial Responses", draft-ietf-httpbis-p5-range-08 (work
in progress), July 2009. in progress), October 2009.
[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-07 (work in progress), draft-ietf-httpbis-p7-auth-08 (work in progress),
July 2009. October 2009.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[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 20 skipping to change at page 31, line 14
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 Transfer-coding and message lengths all interact in ways that
required fixing exactly when chunked encoding is used (to allow for required fixing exactly when chunked encoding is used (to allow for
transfer encoding that may not be self delimiting); it was important transfer encoding that may not be self delimiting); it was important
to straighten out exactly how message lengths are computed. (see also to straighten out exactly how message lengths are computed. (see also
[Part1], [Part3] and [Part5]) [[anchor17: This used to refer to the [Part1], [Part3] and [Part5]) [[anchor16: This used to refer to the
text about non-modifiable headers, and will have to be updated later text about non-modifiable headers, and will have to be updated later
on. --jre]] on. --jre]]
Proxies should be able to add Content-Length when appropriate. Proxies should be able to add Content-Length when appropriate.
[[anchor18: This used to refer to the text about non-modifiable [[anchor17: This used to refer to the text about non-modifiable
headers, and will have to be updated later on. --jre]] 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
header, as PUT or other methods may have need for it in requests. header, as PUT or other methods may have need for it in requests.
A.2. Changes from RFC 2616 A.2. Changes from RFC 2616
Remove requirement to consider Content-Location in successful
responses in order to determine the appropriate response to use.
(Section 2.4)
Clarify denial of service attack avoidance requirement. Clarify denial of service attack avoidance requirement.
(Section 2.5) (Section 2.5)
Do not mention RFC 2047 encoding and multiple languages in Warning
headers anymore, as these aspects never were implemented.
(Section 3.6)
Appendix B. Collected ABNF Appendix B. Collected ABNF
Age = "Age:" OWS Age-v Age = "Age:" OWS Age-v
Age-v = delta-seconds Age-v = delta-seconds
Cache-Control = "Cache-Control:" OWS Cache-Control-v Cache-Control = "Cache-Control:" OWS Cache-Control-v
Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] ) cache-directive ] )
Expires = "Expires:" OWS Expires-v Expires = "Expires:" OWS Expires-v
Expires-v = HTTP-date Expires-v = HTTP-date
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 1.2.2>
Pragma = "Pragma:" OWS Pragma-v Pragma = "Pragma:" OWS Pragma-v
Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] ) pragma-directive ] )
Vary = "Vary:" OWS Vary-v Vary = "Vary:" OWS Vary-v
Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name
] ) ) ] ) )
skipping to change at page 32, line 43 skipping to change at page 32, line 44
OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / (
"no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS
field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" /
"must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds
) / ( "s-maxage=" delta-seconds ) / cache-extension ) / ( "s-maxage=" delta-seconds ) / cache-extension
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
extension-pragma = token [ "=" ( token / quoted-string ) ] extension-pragma = token [ "=" ( token / quoted-string ) ]
field-name = <field-name, defined in [Part1], Section 4.2> field-name = <field-name, defined in [Part1], Section 3.2>
port = <port, defined in [Part1], Section 2.1> port = <port, defined in [Part1], Section 2.6>
pragma-directive = "no-cache" / extension-pragma pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, defined in [Part1], Section 8.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 1.2.2>
token = <token, defined in [Part1], Section 1.2.2> token = <token, defined in [Part1], Section 1.2.2>
uri-host = <uri-host, defined in [Part1], Section 2.1>
uri-host = <uri-host, defined in [Part1], Section 2.6>
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
] ]
ABNF diagnostics: ABNF diagnostics:
skipping to change at page 36, line 5 skipping to change at page 36, line 5
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
numeric protocol elements" numeric protocol elements"
Affected issues: Affected issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non- o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non-
existant headers existant headers
C.9. Since draft-ietf-httpbis-p6-cache-07
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of
1xx Warn-Codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content-
Location on 304 responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and
no-cache CC directives with headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and
warn-text"
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 19, 21 max-age 18, 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, 20
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 21
public 20 public 20
skipping to change at page 37, line 7 skipping to change at page 37, line 24
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 24
Vary-v 24 Vary-v 24
warn-agent 25 warn-agent 26
warn-code 25 warn-code 26
warn-date 25 warn-date 26
warn-text 25 warn-text 26
Warning 25 Warning 26
Warning-v 25 Warning-v 26
warning-value 25 warning-value 26
H H
Headers Headers
Age 17 Age 17
Cache-Control 17 Cache-Control 17
Expires 23 Expires 23
Pragma 23 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 19, 21 Cache Directive 18, 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, 20
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
skipping to change at page 37, line 48 skipping to change at page 38, line 17
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 23 Pragma header 24
private private
Cache Directive 20 Cache Directive 20
proxy-revalidate proxy-revalidate
Cache Directive 21 Cache Directive 21
public public
Cache Directive 20 Cache Directive 20
S S
s-maxage s-maxage
Cache Directive 22 Cache Directive 22
 End of changes. 62 change blocks. 
129 lines changed or deleted 122 lines changed or added

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