< draft-ietf-httpbis-p6-cache-20.txt   draft-ietf-httpbis-p6-cache-21.txt >
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) Y. Lafon, Ed. Obsoletes: 2616 (if approved) M. Nottingham, Ed.
Intended status: Standards Track W3C Intended status: Standards Track Akamai
Expires: January 17, 2013 M. Nottingham, Ed. Expires: April 7, 2013 J. Reschke, Ed.
Rackspace
J. Reschke, Ed.
greenbytes greenbytes
July 16, 2012 October 4, 2012
HTTP/1.1, part 6: Caching Hypertext Transfer Protocol (HTTP/1.1): Caching
draft-ietf-httpbis-p6-cache-20 draft-ietf-httpbis-p6-cache-21
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. This document defines requirements on HTTP caches and the systems. This document defines requirements on HTTP caches and the
associated header fields that control cache behavior or indicate associated header fields that control cache behavior or indicate
cacheable response messages. cacheable response messages.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix D.1. The changes in this draft are summarized in Appendix D.2.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 7, 2013.
This Internet-Draft will expire on January 17, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 39
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Conformance and Error Handling . . . . . . . . . . . . . . 6 1.3. Conformance and Error Handling . . . . . . . . . . . . . . 6
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 7 1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 6
2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 7 2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6
3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 8 3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7
3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 9 3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 8
3.2. Storing Responses to Authenticated Requests . . . . . . . 9 3.2. Storing Responses to Authenticated Requests . . . . . . . 8
4. Constructing Responses from Caches . . . . . . . . . . . . . . 10 4. Constructing Responses from Caches . . . . . . . . . . . . . . 9
4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11 4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 4.1.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11
4.1.2. Calculating Heuristic Freshness . . . . . . . . . . . 12 4.1.2. Calculating Heuristic Freshness . . . . . . . . . . . 12
4.1.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13 4.1.3. Calculating Age . . . . . . . . . . . . . . . . . . . 12
4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 15 4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 14
4.2. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 4.2. Validation Model . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Freshening Responses with 304 Not Modified . . . . . . 16 4.2.1. Freshening Responses with 304 Not Modified . . . . . . 16
4.3. Using Negotiated Responses . . . . . . . . . . . . . . . . 17 4.3. Using Negotiated Responses . . . . . . . . . . . . . . . . 16
4.4. Combining Partial Content . . . . . . . . . . . . . . . . 18 4.4. Combining Partial Content . . . . . . . . . . . . . . . . 17
5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 19 5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 18
6. Request Methods that Invalidate . . . . . . . . . . . . . . . 19 6. Request Methods that Invalidate . . . . . . . . . . . . . . . 18
7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 19
7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 7.2.1. Request Cache-Control Directives . . . . . . . . . . . 20
7.2.2. Response Cache-Control Directives . . . . . . . . . . 23 7.2.2. Response Cache-Control Directives . . . . . . . . . . 22
7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25
7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.5.1. 110 Response is Stale . . . . . . . . . . . . . . . . 30
7.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31 7.5.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 30
7.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 32 7.5.3. 112 Disconnected Operation . . . . . . . . . . . . . . 30
7.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 32 7.5.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 30
7.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 32 7.5.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 30
7.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 32 7.5.6. 214 Transformation Applied . . . . . . . . . . . . . . 30
7.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 32 7.5.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31
7.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 32 7.5.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 31
7.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32 8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31
8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 33 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31
9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 33 9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 32
9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 34 9.3. Header Field Registration . . . . . . . . . . . . . . . . 33
9.3. Header Field Registration . . . . . . . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12.1. Normative References . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . . 35 12.2. Informative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . . 36 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 37 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 37
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 39 publication) . . . . . . . . . . . . . . . . . . . . 38
D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 39 D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 38
D.2. Since draft-ietf-httpbis-p6-cache-20 . . . . . . . . . . . 38
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
HTTP is typically used for distributed information systems, where HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches. This performance can be improved by the use of response caches. This
document defines aspects of HTTP/1.1 related to caching and reusing document defines aspects of HTTP/1.1 related to caching and reusing
response messages. response messages.
1.1. Purpose 1.1. Purpose
skipping to change at page 6, line 8 skipping to change at page 6, line 8
validator validator
A protocol element (e.g., an entity-tag or a Last-Modified time) A protocol element (e.g., an entity-tag or a Last-Modified time)
that is used to find out whether a stored response is an that is used to find out whether a stored response is an
equivalent copy of a representation. See Section 2.1 of [Part4]. equivalent copy of a representation. See Section 2.1 of [Part4].
strong validator strong validator
A validator that is defined by the origin server such that its A validator that is defined by the origin server such that its
current value will change if the representation body changes; current value will change if the representation data changes;
i.e., an entity-tag that is not marked as weak (Section 2.3 of i.e., an entity-tag that is not marked as weak (Section 2.3 of
[Part4]) or, if no entity-tag is provided, a Last-Modified value [Part4]) or, if no entity-tag is provided, a Last-Modified value
that is strong in the sense defined by Section 2.2.2 of [Part4]. that is strong in the sense defined by Section 2.2.2 of [Part4].
1.3. Conformance and Error Handling 1.3. Conformance and Error Handling
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification targets conformance criteria according to the role Conformance criteria and considerations regarding error handling are
of a participant in HTTP communication. Hence, HTTP requirements are defined in Section 2.5 of [Part1].
placed on senders, recipients, clients, servers, user agents,
intermediaries, origin servers, proxies, gateways, or caches,
depending on what behavior is being constrained by the requirement.
See Section 2 of [Part1] for definitions of these terms.
The verb "generate" is used instead of "send" where a requirement
differentiates between creating a protocol element and merely
forwarding a received element downstream.
An implementation is considered conformant if it complies with all of
the requirements associated with the roles it partakes in HTTP. Note
that SHOULD-level requirements are relevant here, unless one of the
documented exceptions is applicable.
This document also uses ABNF to define valid protocol elements
(Section 1.4). In addition to the prose requirements placed upon
them, senders MUST NOT generate protocol elements that do not match
the grammar defined by the ABNF rules for those protocol elements
that are applicable to the sender's role. If a received protocol
element is processed, the recipient MUST be able to parse any value
that would match the ABNF rules for that protocol element, excluding
only those rules not applicable to the recipient's role.
Unless noted otherwise, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to
be dangerous.
1.4. Syntax Notation 1.4. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with the list rule extension defined in Section notation of [RFC5234] with the list rule extension defined in Section
1.2 of [Part1]. Appendix B describes rules imported from other 1.2 of [Part1]. Appendix B describes rules imported from other
documents. Appendix C shows the collected ABNF with the list rule documents. Appendix C shows the collected ABNF with the list rule
expanded. expanded.
1.4.1. Delta Seconds 1.4.1. Delta Seconds
skipping to change at page 10, line 45 skipping to change at page 10, line 11
Note that any of the requirements listed above can be overridden by a Note that any of the requirements listed above can be overridden by a
cache-control extension; see Section 7.2.3. cache-control extension; see Section 7.2.3.
When a stored response is used to satisfy a request without When a stored response is used to satisfy a request without
validation, a cache MUST include a single Age header field validation, a cache MUST include a single Age header field
(Section 7.1) in the response with a value equal to the stored (Section 7.1) in the response with a value equal to the stored
response's current_age; see Section 4.1.3. response's current_age; see Section 4.1.3.
A cache MUST write through requests with methods that are unsafe A cache MUST write through requests with methods that are unsafe
(Section 2.1.1 of [Part2]) to the origin server; i.e., a cache is not (Section 5.2.1 of [Part2]) to the origin server; i.e., a cache is not
allowed to generate a reply to such a request before having forwarded allowed to generate a reply to such a request before having forwarded
the request and having received a corresponding response. the request and having received a corresponding response.
Also, note that unsafe requests might invalidate already stored Also, note that unsafe requests might invalidate already stored
responses; see Section 6. responses; see Section 6.
When more than one suitable response is stored, a cache MUST use the When more than one suitable response is stored, a cache MUST use the
most recent response (as determined by the Date header field). It most recent response (as determined by the Date header field). It
can also forward a request with "Cache-Control: max-age=0" or "Cache- can also forward a request with "Cache-Control: max-age=0" or "Cache-
Control: no-cache" to disambiguate which response to use. Control: no-cache" to disambiguate which response to use.
skipping to change at page 12, line 41 skipping to change at page 12, line 9
When there is more than one value present for a given directive When there is more than one value present for a given directive
(e.g., two Expires header fields, multiple Cache-Control: max-age (e.g., two Expires header fields, multiple Cache-Control: max-age
directives), it is considered invalid. Caches are encouraged to directives), it is considered invalid. Caches are encouraged to
consider responses that have invalid freshness information to be consider responses that have invalid freshness information to be
stale. stale.
4.1.2. Calculating Heuristic Freshness 4.1.2. Calculating Heuristic Freshness
If no explicit expiration time is present in a stored response that If no explicit expiration time is present in a stored response that
has a status code whose definition allows heuristic freshness to be has a status code whose definition allows heuristic freshness to be
used (including the following in Section 4 of [Part2]: 200 (OK), 203 used (including the following in Section 7 of [Part2]: 200 (OK), 203
(Non-Authoritative Information), 206 (Partial Content), 300 (Multiple (Non-Authoritative Information), 206 (Partial Content), 300 (Multiple
Choices), 301 (Moved Permanently) and 410 (Gone)), a cache MAY Choices), 301 (Moved Permanently) and 410 (Gone)), a cache MAY
calculate a heuristic expiration time. A cache MUST NOT use calculate a heuristic expiration time. A cache MUST NOT use
heuristics to determine freshness for responses with status codes heuristics to determine freshness for responses with status codes
that do not explicitly allow it. that do not explicitly allow it.
When a heuristic is used to calculate freshness lifetime, a cache When a heuristic is used to calculate freshness lifetime, a cache
SHOULD attach a Warning header field with a 113 warn-code to the SHOULD attach a Warning header field with a 113 warn-code to the
response if its current_age is more than 24 hours and such a warning response if its current_age is more than 24 hours and such a warning
is not already present. is not already present.
skipping to change at page 13, line 41 skipping to change at page 13, line 11
The term "age_value" denotes the value of the Age header field The term "age_value" denotes the value of the Age header field
(Section 7.1), in a form appropriate for arithmetic operation; or (Section 7.1), in a form appropriate for arithmetic operation; or
0, if not available. 0, if not available.
date_value date_value
HTTP/1.1 requires origin servers to send a Date header field, if HTTP/1.1 requires origin servers to send a Date header field, if
possible, with every response, giving the time at which the possible, with every response, giving the time at which the
response was generated. The term "date_value" denotes the value response was generated. The term "date_value" denotes the value
of the Date header field, in a form appropriate for arithmetic of the Date header field, in a form appropriate for arithmetic
operations. See Section 9.10 of [Part2] for the definition of the operations. See Section 8.1.1.2 of [Part2] for the definition of
Date header field, and for requirements regarding responses the Date header field, and for requirements regarding responses
without it. without it.
now now
The term "now" means "the current value of the clock at the host The term "now" means "the current value of the clock at the host
performing the calculation". A cache SHOULD use NTP ([RFC1305]) performing the calculation". A cache SHOULD use NTP ([RFC1305])
or some similar protocol to synchronize its clocks to a globally or some similar protocol to synchronize its clocks to a globally
accurate time standard. accurate time standard.
request_time request_time
skipping to change at page 15, line 5 skipping to change at page 14, line 23
The current_age of a stored response can then be calculated by adding The current_age of a stored response can then be calculated by adding
the amount of time (in seconds) since the stored response was last the amount of time (in seconds) since the stored response was last
validated by the origin server to the corrected_initial_age. validated by the origin server to the corrected_initial_age.
resident_time = now - response_time; resident_time = now - response_time;
current_age = corrected_initial_age + resident_time; current_age = corrected_initial_age + resident_time;
Additionally, to avoid common problems in date parsing: Additionally, to avoid common problems in date parsing:
o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date o Recipients SHOULD assume that an RFC-850 date which appears to be
which appears to be more than 50 years in the future is in fact in more than 50 years in the future is in fact in the past (this
the past (this helps solve the "year 2000" problem). helps solve the "year 2000" problem).
o Although all date formats are specified to be case-sensitive, o Although all date formats are specified to be case-sensitive,
recipients SHOULD match day, week and timezone names case- recipients SHOULD match day, week and timezone names case-
insensitively. insensitively.
o An HTTP/1.1 implementation MAY internally represent a parsed o An implementation MAY internally represent a parsed Expires date
Expires date as earlier than the proper value, but MUST NOT as earlier than the proper value, but MUST NOT internally
internally represent a parsed Expires date as later than the represent a parsed Expires date as later than the proper value.
proper value.
o All expiration-related calculations MUST be done in GMT. The o Recipients MUST perform all expiration-related calculations in
local time zone MUST NOT influence the calculation or comparison GMT. The local time zone MUST NOT influence the calculation or
of an age or expiration time. comparison of an age or expiration time.
o If an HTTP header field incorrectly carries a date value with a o Caches SHOULD consider dates with time zones other than "GMT"
time zone other than GMT, it MUST be converted into GMT using the invalid.
most conservative possible conversion.
4.1.4. Serving Stale Responses 4.1.4. Serving Stale Responses
A "stale" response is one that either has explicit expiry information A "stale" response is one that either has explicit expiry information
or is allowed to have heuristic expiry calculated, but is not fresh or is allowed to have heuristic expiry calculated, but is not fresh
according to the calculations in Section 4.1. according to the calculations in Section 4.1.
A cache MUST NOT return a stale response if it is prohibited by an A cache MUST NOT return a stale response if it is prohibited by an
explicit in-protocol directive (e.g., by a "no-store" or "no-cache" explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
cache directive, a "must-revalidate" cache-response-directive, or an cache directive, a "must-revalidate" cache-response-directive, or an
applicable "s-maxage" or "proxy-revalidate" cache-response-directive; applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
see Section 7.2.2). see Section 7.2.2).
A cache MUST NOT return stale responses unless it is disconnected A cache MUST NOT return stale responses unless it is disconnected
(i.e., it cannot contact the origin server or otherwise find a (i.e., it cannot contact the origin server or otherwise find a
forward path) or doing so is explicitly allowed (e.g., by the max- forward path) or doing so is explicitly allowed (e.g., by the max-
stale request directive; see Section 7.2.1). stale request directive; see Section 7.2.1).
A cache SHOULD append a Warning header field with the 110 warn-code A cache SHOULD append a Warning header field with the 110 warn-code
(see Section 7.6) to stale responses. Likewise, a cache SHOULD add (see Section 7.5) to stale responses. Likewise, a cache SHOULD add
the 112 warn-code to stale responses if the cache is disconnected. the 112 warn-code to stale responses if the cache is disconnected.
If a cache receives a first-hand response (either an entire response, If a cache receives a first-hand response (either an entire response,
or a 304 (Not Modified) response) that it would normally forward to or a 304 (Not Modified) response) that it would normally forward to
the requesting client, and the received response is no longer fresh, the requesting client, and the received response is no longer fresh,
the cache can forward it to the requesting client without adding a the cache can forward it to the requesting client without adding a
new Warning (but without removing any existing Warning header new Warning (but without removing any existing Warning header
fields). A cache shouldn't attempt to validate a response simply fields). A cache shouldn't attempt to validate a response simply
because that response became stale in transit. because that response became stale in transit.
skipping to change at page 16, line 34 skipping to change at page 15, line 50
responses contains only partial content, the cache shouldn't include responses contains only partial content, the cache shouldn't include
its entity-tag in the If-None-Match header field unless the request its entity-tag in the If-None-Match header field unless the request
is for a range that would be fully satisfied by that stored response. is for a range that would be fully satisfied by that stored response.
Cache handling of a response to a conditional request is dependent Cache handling of a response to a conditional request is dependent
upon its status code: upon its status code:
o A 304 (Not Modified) response status code indicates that the o A 304 (Not Modified) response status code indicates that the
stored response can be updated and reused; see Section 4.2.1. stored response can be updated and reused; see Section 4.2.1.
o A full response (i.e., one with a response body) indicates that o A full response (i.e., one with a payload body) indicates that
none of the stored responses nominated in the conditional request none of the stored responses nominated in the conditional request
is suitable. Instead, the cache can use the full response to is suitable. Instead, the cache can use the full response to
satisfy the request and MAY replace the stored response(s). satisfy the request and MAY replace the stored response(s).
o However, if a cache receives a 5xx (Server Error) response while o However, if a cache receives a 5xx (Server Error) response while
attempting to validate a response, it can either forward this attempting to validate a response, it can either forward this
response to the requesting client, or act as if the server failed response to the requesting client, or act as if the server failed
to respond. In the latter case, it can return a previously stored to respond. In the latter case, it can return a previously stored
response (see Section 4.1.4). response (see Section 4.1.4).
skipping to change at page 17, line 23 skipping to change at page 16, line 38
corresponds to one of the cache's stored responses, then the most corresponds to one of the cache's stored responses, then the most
recent of those matching stored responses is selected. recent of those matching stored responses is selected.
o If the new response does not include any form of validator, there o If the new response does not include any form of validator, there
is only one stored response, and that stored response also lacks a is only one stored response, and that stored response also lacks a
validator, then that stored response is selected. validator, then that stored response is selected.
If a stored response is selected for update, the cache MUST: If a stored response is selected for update, the cache MUST:
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 7.6); code 1xx (see Section 7.5);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with warn-
code 2xx; and, code 2xx; and,
o use other header fields provided in the 304 (Not Modified) o use other header fields provided in the 304 (Not Modified)
response to replace all instances of the corresponding header response to replace all instances of the corresponding header
fields in the stored response. fields in the stored response.
4.3. Using Negotiated Responses 4.3. Using 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 7.5), it MUST NOT use response that has a Vary header field (Section 8.2.1 of [Part2]), it
that response unless all of the selecting header fields nominated by MUST NOT use that response unless all of the selecting header fields
the Vary header field match in both the original request (i.e., that nominated by the Vary header field match in both the original request
associated with the stored response), and the presented request. (i.e., that associated with the stored response), and the presented
request.
The selecting header fields from two requests are defined to match if The selecting header fields from two requests are defined to match if
and only if those in the first request can be transformed to those in and only if those in the first request can be transformed to those in
the second request by applying any of the following: the second request by applying any of the following:
o adding or removing whitespace, where allowed in the header field's o adding or removing whitespace, where allowed in the header field's
syntax syntax
o combining multiple header fields with the same field name (see o combining multiple header fields with the same field name (see
Section 3.2 of [Part1]) Section 3.2 of [Part1])
skipping to change at page 18, line 41 skipping to change at page 18, line 10
might have received several ranges of the same representation. A might have received several ranges of the same representation. A
cache MAY combine these ranges into a single stored response, and cache MAY combine these ranges into a single stored response, and
reuse that response to satisfy later requests, if they all share the reuse that response to satisfy later requests, if they all share the
same strong validator and the cache complies with the client same strong validator and the cache complies with the client
requirements in Section 4.2 of [Part5]. requirements in Section 4.2 of [Part5].
When combining the new response with one or more stored responses, a When combining the new response with one or more stored responses, a
cache MUST: cache MUST:
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 7.6); code 1xx (see Section 7.5);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with warn-
code 2xx; and, code 2xx; and,
o use other header fields provided in the new response, aside from o use other header fields provided in the new response, aside from
Content-Range, to replace all instances of the corresponding Content-Range, to replace all instances of the corresponding
header fields in the stored response. header fields in the stored response.
5. Updating Caches with HEAD Responses 5. Updating Caches with HEAD Responses
skipping to change at page 19, line 24 skipping to change at page 18, line 38
Last-Modified value of a HEAD response differs from that in a Last-Modified value of a HEAD response differs from that in a
selected GET response, the cache MUST consider that selected response selected GET response, the cache MUST consider that selected response
to be stale. to be stale.
If the Content-Length, ETag and Last-Modified values of a HEAD If the Content-Length, ETag and Last-Modified values of a HEAD
response (when present) are the same as that in a selected GET response (when present) are the same as that in a selected GET
response (as per Section 4.3), the cache SHOULD update the remaining response (as per Section 4.3), the cache SHOULD update the remaining
header fields in the stored response using the following rules: header fields in the stored response using the following rules:
o delete any Warning header fields in the stored response with warn- o delete any Warning header fields in the stored response with warn-
code 1xx (see Section 7.6); code 1xx (see Section 7.5);
o retain any Warning header fields in the stored response with warn- o retain any Warning header fields in the stored response with warn-
code 2xx; and, code 2xx; and,
o use other header fields provided in the response to replace all o use other header fields provided in the response to replace all
instances of the corresponding header fields in the stored instances of the corresponding header fields in the stored
response. response.
6. Request Methods that Invalidate 6. Request Methods that Invalidate
Because unsafe request methods (Section 2.1.1 of [Part2]) such as Because unsafe request methods (Section 5.2.1 of [Part2]) such as
PUT, POST or DELETE have the potential for changing state on the PUT, POST or DELETE have the potential for changing state on the
origin server, intervening caches can use them to keep their contents origin server, intervening caches can use them to keep their contents
up-to-date. up-to-date.
A cache MUST invalidate the effective Request URI (Section 5.5 of A cache MUST invalidate the effective Request URI (Section 5.5 of
[Part1]) as well as the URI(s) in the Location and Content-Location [Part1]) as well as the URI(s) in the Location and Content-Location
response header fields (if present) when a non-error response to a response header fields (if present) when a non-error response to a
request with an unsafe method is received. request with an unsafe method is received.
However, a cache MUST NOT invalidate a URI from a Location or However, a cache MUST NOT invalidate a URI from a Location or
skipping to change at page 28, line 16 skipping to change at page 27, line 26
The "Expires" header field gives the date/time after which the The "Expires" header field gives the date/time after which the
response is considered stale. See Section 4.1 for further discussion response is considered stale. See Section 4.1 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 5.1 of [Part2]; a sender MUST use the rfc1123-date format. in Section 8.1.1.1 of [Part2]; a sender MUST use the rfc1123-date
format.
Expires = HTTP-date Expires = HTTP-date
For example For example
Expires: Thu, 01 Dec 1994 16:00:00 GMT Expires: Thu, 01 Dec 1994 16:00:00 GMT
A cache MUST treat other invalid date formats, especially including A cache MUST treat other invalid date formats, especially including
the value "0", as in the past (i.e., "already expired"). the value "0", as in the past (i.e., "already expired").
skipping to change at page 29, line 35 skipping to change at page 28, line 46
Pragma: no-cache Pragma: no-cache
will constrain HTTP/1.1 caches to serve a response no older than 30 will constrain HTTP/1.1 caches to serve a response no older than 30
seconds, while precluding implementations that do not understand seconds, while precluding implementations that do not understand
Cache-Control from serving a cached response. Cache-Control from serving a cached response.
Note: Because the meaning of "Pragma: no-cache" in responses is Note: Because the meaning of "Pragma: no-cache" in responses is
not specified, it does not provide a reliable replacement for not specified, it does not provide a reliable replacement for
"Cache-Control: no-cache" in them. "Cache-Control: no-cache" in them.
7.5. Vary 7.5. Warning
The "Vary" header field conveys the set of header fields that were
used to select the representation.
Caches use this information, in part, to determine whether a stored
response can be used to satisfy a given request; see Section 4.3.
In uncacheable or stale responses, the Vary field value advises the
user agent about the criteria that were used to select the
representation.
Vary = "*" / 1#field-name
The set of header fields named by the Vary field value is known as
the selecting header fields.
A server SHOULD include a Vary header field with any cacheable
response that is subject to server-driven negotiation. Doing so
allows a cache to properly interpret future requests on that resource
and informs the user agent about the presence of negotiation on that
resource. A server MAY include a Vary header field with a non-
cacheable response that is subject to server-driven negotiation,
since this might provide the user agent with useful information about
the dimensions over which the response varies at the time of the
response.
A Vary field value of "*" signals that unspecified parameters not
limited to the header fields (e.g., the network address of the
client), play a role in the selection of the response representation;
therefore, a cache cannot determine whether this response is
appropriate. A proxy MUST NOT generate the "*" value.
The field-names given are not limited to the set of standard header
fields defined by this specification. Field names are case-
insensitive.
7.6. Warning
The "Warning" header field is used to carry additional information The "Warning" header field is used to carry additional information
about the status or transformation of a message that might not be about the status or transformation of a message that might not be
reflected in the message. This information is typically used to warn reflected in the message. This information is typically used to warn
about possible incorrectness introduced by caching operations or about possible incorrectness introduced by caching operations or
transformations applied to the payload of the message. transformations applied to the payload of the 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,
distinguishes these responses from true failures. distinguishes these responses from true failures.
skipping to change at page 31, line 47 skipping to change at page 30, line 21
warn-date, and that warn-date is different from the Date value in the warn-date, and that warn-date is different from the Date value in the
response, then that warning-value MUST be deleted from the message response, then that warning-value MUST be deleted from the message
before storing, forwarding, or using it. (preventing the consequences before storing, forwarding, or using it. (preventing the consequences
of naive caching of Warning header fields.) If all of the warning- of naive caching of Warning header fields.) If all of the warning-
values are deleted for this reason, the Warning header field MUST be values are deleted for this reason, the Warning header field MUST be
deleted as well. deleted as well.
The following warn-codes are defined by this specification, each with The following warn-codes are defined by this specification, each with
a recommended warn-text in English, and a description of its meaning. a recommended warn-text in English, and a description of its meaning.
7.6.1. 110 Response is Stale 7.5.1. 110 Response is Stale
A cache SHOULD include this whenever the returned response is stale. A cache SHOULD include this whenever the returned response is stale.
7.6.2. 111 Revalidation Failed 7.5.2. 111 Revalidation Failed
A cache SHOULD include this when returning a stale response because A cache SHOULD include this when returning a stale response because
an attempt to validate the response failed, due to an inability to an attempt to validate the response failed, due to an inability to
reach the server. reach the server.
7.6.3. 112 Disconnected Operation 7.5.3. 112 Disconnected Operation
A cache SHOULD include this if it is intentionally disconnected from A cache SHOULD include this if it is intentionally disconnected from
the rest of the network for a period of time. the rest of the network for a period of time.
7.6.4. 113 Heuristic Expiration 7.5.4. 113 Heuristic Expiration
A cache SHOULD include this if it heuristically chose a freshness A cache SHOULD include this if it heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater than lifetime greater than 24 hours and the response's age is greater than
24 hours. 24 hours.
7.6.5. 199 Miscellaneous Warning 7.5.5. 199 Miscellaneous Warning
The warning text can include arbitrary information to be presented to The warning text can include arbitrary information to be presented to
a human user, or logged. A system receiving this warning MUST NOT a human user, or logged. A system receiving this warning MUST NOT
take any automated action, besides presenting the warning to the take any automated action, besides presenting the warning to the
user. user.
7.6.6. 214 Transformation Applied 7.5.6. 214 Transformation Applied
MUST be added by a proxy if it applies any transformation to the MUST be added by a proxy if it applies any transformation to the
representation, such as changing the content-coding, media-type, or representation, such as changing the content-coding, media-type, or
modifying the representation data, unless this Warning code already modifying the representation data, unless this Warning code already
appears in the response. appears in the response.
7.6.7. 299 Miscellaneous Persistent Warning 7.5.7. 299 Miscellaneous Persistent Warning
The warning text can include arbitrary information to be presented to The warning text can include arbitrary information to be presented to
a human user, or logged. A system receiving this warning MUST NOT a human user, or logged. A system receiving this warning MUST NOT
take any automated action. take any automated action.
7.6.8. Warn Code Extensions 7.5.8. Warn Code Extensions
The HTTP Warn Code Registry defines the name space for warn codes. The HTTP Warn Code Registry defines the name space for warn codes.
A registration MUST include the following fields: A registration MUST include the following fields:
o Warn Code (3 digits) o Warn Code (3 digits)
o Short Description o Short Description
o Pointer to specification text o Pointer to specification text
Values to be added to this name space require IETF Review (see Values to be added to this name space require IETF Review (see
[RFC5226], Section 4.1). [RFC5226], Section 4.1).
The registry itself is maintained at The registry itself is maintained at
<http://www.iana.org/assignments/http-warn-codes>. <http://www.iana.org/assignments/http-warn-codes>.
8. History Lists 8. History Lists
skipping to change at page 34, line 27 skipping to change at page 32, line 31
| proxy-revalidate | Section 7.2.2.6 | | proxy-revalidate | Section 7.2.2.6 |
| public | Section 7.2.2.1 | | public | Section 7.2.2.1 |
| s-maxage | Section 7.2.2.8 | | s-maxage | Section 7.2.2.8 |
| stale-if-error | [RFC5861], Section 4 | | stale-if-error | [RFC5861], Section 4 |
| stale-while-revalidate | [RFC5861], Section 3 | | stale-while-revalidate | [RFC5861], Section 3 |
+------------------------+----------------------------------+ +------------------------+----------------------------------+
9.2. Warn Code Registry 9.2. Warn Code Registry
The registration procedure for HTTP Warn Codes is defined by The registration procedure for HTTP Warn Codes is defined by
Section 7.6.8 of this document. Section 7.5.8 of this document.
The HTTP Warn Code Registry shall be created at The HTTP Warn Code Registry shall be created at
<http://www.iana.org/assignments/http-cache-directives> and be <http://www.iana.org/assignments/http-cache-directives> and be
populated with the registrations below: populated with the registrations below:
+-----------+----------------------------------+---------------+ +-----------+----------------------------------+---------------+
| Warn Code | Short Description | Reference | | Warn Code | Short Description | Reference |
+-----------+----------------------------------+---------------+ +-----------+----------------------------------+---------------+
| 110 | Response is Stale | Section 7.6.1 | | 110 | Response is Stale | Section 7.5.1 |
| 111 | Revalidation Failed | Section 7.6.2 | | 111 | Revalidation Failed | Section 7.5.2 |
| 112 | Disconnected Operation | Section 7.6.3 | | 112 | Disconnected Operation | Section 7.5.3 |
| 113 | Heuristic Expiration | Section 7.6.4 | | 113 | Heuristic Expiration | Section 7.5.4 |
| 199 | Miscellaneous Warning | Section 7.6.5 | | 199 | Miscellaneous Warning | Section 7.5.5 |
| 214 | Transformation Applied | Section 7.6.6 | | 214 | Transformation Applied | Section 7.5.6 |
| 299 | Miscellaneous Persistent Warning | Section 7.6.7 | | 299 | Miscellaneous Persistent Warning | Section 7.5.7 |
+-----------+----------------------------------+---------------+ +-----------+----------------------------------+---------------+
9.3. Header Field Registration 9.3. Header Field Registration
The Message Header Field Registry located at <http://www.iana.org/ The Message Header Field Registry located at <http://www.iana.org/
assignments/message-headers/message-header-index.html> shall be assignments/message-headers/message-header-index.html> shall be
updated with the permanent registrations below (see [RFC3864]): updated with the permanent registrations below (see [RFC3864]):
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
| Age | http | standard | Section 7.1 | | Age | http | standard | Section 7.1 |
| Cache-Control | http | standard | Section 7.2 | | Cache-Control | http | standard | Section 7.2 |
| Expires | http | standard | Section 7.3 | | Expires | http | standard | Section 7.3 |
| Pragma | http | standard | Section 7.4 | | Pragma | http | standard | Section 7.4 |
| Vary | http | standard | Section 7.5 | | Warning | http | standard | Section 7.5 |
| Warning | http | standard | Section 7.6 |
+-------------------+----------+----------+-------------+ +-------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
10. Security Considerations 10. Security Considerations
Caches expose additional potential vulnerabilities, since the Caches expose additional potential vulnerabilities, since the
contents of the cache represent an attractive target for malicious contents of the cache represent an attractive target for malicious
exploitation. Because cache contents persist after an HTTP request exploitation. Because cache contents persist after an HTTP request
is complete, an attack on the cache can reveal information long after is complete, an attack on the cache can reveal information long after
a user believes that the information has been removed from the a user believes that the information has been removed from the
network. Therefore, cache contents need to be protected as sensitive network. Therefore, cache contents need to be protected as sensitive
information. information.
Implementation flaws might allow attackers to insert content into a
cache ("cache poisoning"), leading to compromise of clients that
trust that content. Because of their nature, these attacks are
difficult to mitigate.
Likewise, implementation flaws (as well as misunderstanding of cache
operation) might lead to caching of sensitive information (e.g.,
authentication credentials) that is thought to be private, exposing
it to unauthorised parties.
Note that the Set-Cookie response header [RFC6265] does not inhibit
caching; a cacheable response with a Set-Cookie header can be (and
often is) used to satisfy subsequent requests to caches. Servers who
wish to control caching of these responses are encouraged to emit
appropriate Cache-Control response headers.
11. Acknowledgments 11. Acknowledgments
See Section 9 of [Part1]. See Section 9 of [Part1].
12. References 12. References
12.1. Normative References 12.1. Normative References
[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 1: Message Routing and Syntax"", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-20 (work in progress), draft-ietf-httpbis-p1-messaging-21 (work in progress),
July 2012. October 2012.
[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 2: Semantics and Payloads", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-20 (work in progress), draft-ietf-httpbis-p2-semantics-21 (work in progress),
July 2012. October 2012.
[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 4: Conditional Requests", Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-20 (work in progress), draft-ietf-httpbis-p4-conditional-21 (work in progress),
July 2012. October 2012.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 5: Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
draft-ietf-httpbis-p5-range-20 (work in progress), draft-ietf-httpbis-p5-range-21 (work in progress),
July 2012. October 2012.
[Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 7: Authentication", Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-20 (work in progress), draft-ietf-httpbis-p7-auth-21 (work in progress),
July 2012. October 2012.
[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.
12.2. Informative References 12.2. Informative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
skipping to change at page 36, line 39 skipping to change at page 35, line 16
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, April 2010. Content", RFC 5861, April 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
Appendix A. Changes from RFC 2616 Appendix A. Changes from RFC 2616
Make the specified age calculation algorithm less conservative. Make the specified age calculation algorithm less conservative.
(Section 4.1.3) (Section 4.1.3)
Remove requirement to consider Content-Location in successful Remove requirement to consider "Content-Location" in successful
responses in order to determine the appropriate response to use. responses in order to determine the appropriate response to use.
(Section 4.2) (Section 4.2)
Clarify denial of service attack avoidance requirement. (Section 6) Clarify denial of service attack avoidance requirement. (Section 6)
Change ABNF productions for header fields to only define the field Do not mention RFC 2047 encoding and multiple languages in "Warning"
value. (Section 7)
Do not mention RFC 2047 encoding and multiple languages in Warning
header fields anymore, as these aspects never were implemented. header fields anymore, as these aspects never were implemented.
(Section 7.6) (Section 7.5)
Introduce Cache Directive and Warn Code Registries. (Section 7.2.3 Introduce Cache Directive and Warn Code Registries. (Section 7.2.3
and Section 7.6.8) and Section 7.5.8)
Appendix B. Imported ABNF Appendix B. Imported ABNF
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character). character).
The rules below are defined in [Part1]: The rules below are defined in [Part1]:
OWS = <OWS, defined in [Part1], Section 3.2.1> OWS = <OWS, defined in [Part1], Section 3.2.1>
field-name = <field-name, defined in [Part1], Section 3.2> field-name = <field-name, defined in [Part1], Section 3.2>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
token = <token, defined in [Part1], Section 3.2.4> token = <token, defined in [Part1], Section 3.2.4>
port = <port, defined in [Part1], Section 2.8> port = <port, defined in [Part1], Section 2.7>
pseudonym = <pseudonym, defined in [Part1], Section 6.2> pseudonym = <pseudonym, defined in [Part1], Section 5.7>
uri-host = <uri-host, defined in [Part1], Section 2.8> uri-host = <uri-host, defined in [Part1], Section 2.7>
The rules below are defined in other parts: The rules below are defined in other parts:
HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1>
Appendix C. Collected ABNF Appendix C. Collected ABNF
Age = delta-seconds Age = delta-seconds
Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] ) cache-directive ] )
Expires = HTTP-date Expires = HTTP-date
HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1>
OWS = <OWS, defined in [Part1], Section 3.2.1> OWS = <OWS, defined in [Part1], Section 3.2.1>
Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] ) pragma-directive ] )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) )
Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
) )
cache-directive = token [ "=" ( token / quoted-string ) ] cache-directive = token [ "=" ( token / quoted-string ) ]
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
extension-pragma = token [ "=" ( token / quoted-string ) ] extension-pragma = token [ "=" ( token / quoted-string ) ]
field-name = <field-name, defined in [Part1], Section 3.2> field-name = <field-name, defined in [Part1], Section 3.2>
port = <port, defined in [Part1], Section 2.8> port = <port, defined in [Part1], Section 2.7>
pragma-directive = "no-cache" / extension-pragma pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, defined in [Part1], Section 6.2> pseudonym = <pseudonym, defined in [Part1], Section 5.7>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
token = <token, defined in [Part1], Section 3.2.4> token = <token, defined in [Part1], Section 3.2.4>
uri-host = <uri-host, defined in [Part1], Section 2.8> uri-host = <uri-host, defined in [Part1], Section 2.7>
warn-agent = ( uri-host [ ":" port ] ) / pseudonym warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
] ]
Appendix D. Change Log (to be removed by RFC Editor before publication) Appendix D. Change Log (to be removed by RFC Editor before publication)
skipping to change at page 39, line 36 skipping to change at page 38, line 36
o <http://tools.ietf.org/wg/httpbis/trac/ticket/360>: "enhance o <http://tools.ietf.org/wg/httpbis/trac/ticket/360>: "enhance
considerations for new cache control directives" considerations for new cache control directives"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
requirements for recipients" requirements for recipients"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
introduction of new IANA registries as normative changes" introduction of new IANA registries as normative changes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/373>: "broken prose
in description of 'Vary'"
D.2. Since draft-ietf-httpbis-p6-cache-20
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/375>: "'Most
Conservative'"
Other changes:
o Conformance criteria and considerations regarding error handling
are now defined in Part 1.
o Move definition of "Vary" header field into Part 2.
o Add security considerations with respect to cache poisoning and
the "Set-Cookie" header field.
Index Index
1 1
110 Response is Stale (warn code) 31 110 Response is Stale (warn code) 30
111 Revalidation Failed (warn code) 32 111 Revalidation Failed (warn code) 30
112 Disconnected Operation (warn code) 32 112 Disconnected Operation (warn code) 30
113 Heuristic Expiration (warn code) 32 113 Heuristic Expiration (warn code) 30
199 Miscellaneous Warning (warn code) 32 199 Miscellaneous Warning (warn code) 30
2 2
214 Transformation Applied (warn code) 32 214 Transformation Applied (warn code) 30
299 Miscellaneous Persistent Warning (warn code) 32 299 Miscellaneous Persistent Warning (warn code) 31
A A
age 5 age 5
Age header field 20 Age header field 19
C C
cache 4 cache 4
Cache Directives cache entry 6
max-age 22, 25 cache key 6
max-stale 22
min-fresh 22
must-revalidate 25
no-cache 21, 24
no-store 21, 25
no-transform 23, 26
only-if-cached 23
private 23
proxy-revalidate 25
public 23
s-maxage 26
cache entry 7
cache key 7
Cache-Control header field 20 Cache-Control header field 20
cacheable 4 cacheable 4
E E
Expires header field 28 Expires header field 27
explicit expiration time 5 explicit expiration time 5
F F
first-hand 5 first-hand 5
fresh 5 fresh 5
freshness lifetime 5 freshness lifetime 5
G G
Grammar Grammar
Age 20 Age 19
Cache-Control 21
cache-directive 21
delta-seconds 7
Expires 28
extension-pragma 29
Pragma 29
pragma-directive 29
Vary 29
warn-agent 30
warn-code 30
warn-date 30
warn-text 30
Warning 30
warning-value 30
H
Header Fields
Age 20
Cache-Control 20 Cache-Control 20
Expires 28 cache-directive 20
delta-seconds 6
Expires 27
extension-pragma 28
Pragma 28 Pragma 28
Vary 29 pragma-directive 28
Warning 30 warn-agent 29
warn-code 29
warn-date 29
warn-text 29
Warning 29
warning-value 29
H
heuristic expiration time 5 heuristic expiration time 5
M M
max-age max-age (cache directive) 21, 25
Cache Directive 22, 25 max-stale (cache directive) 21
max-stale min-fresh (cache directive) 22
Cache Directive 22 must-revalidate (cache directive) 24
min-fresh
Cache Directive 22
must-revalidate
Cache Directive 25
N N
no-cache no-cache (cache directive) 20, 23
Cache Directive 21, 24 no-store (cache directive) 20, 24
no-store no-transform (cache directive) 22, 25
Cache Directive 21, 25
no-transform
Cache Directive 23, 26
O O
only-if-cached only-if-cached (cache directive) 22
Cache Directive 23
P P
Pragma header field 28 Pragma header field 28
private private (cache directive) 22
Cache Directive 23
private cache 4 private cache 4
proxy-revalidate proxy-revalidate (cache directive) 24
Cache Directive 25 public (cache directive) 22
public
Cache Directive 23
S S
s-maxage s-maxage (cache directive) 25
Cache Directive 26
shared cache 4 shared cache 4
stale 5 stale 5
strong validator 6 strong validator 6
V V
validator 5 validator 5
strong 6 strong 6
Vary header field 29
W W
Warn Codes Warning header field 28
110 Response is Stale 31
111 Revalidation Failed 32
112 Disconnected Operation 32
113 Heuristic Expiration 32
199 Miscellaneous Warning 32
214 Transformation Applied 32
299 Miscellaneous Persistent Warning 32
Warning header field 30
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Yves Lafon (editor)
World Wide Web Consortium
W3C / ERCIM
2004, rte des Lucioles
Sophia-Antipolis, AM 06902
France
EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/
Mark Nottingham (editor) Mark Nottingham (editor)
Rackspace Akamai
EMail: mnot@mnot.net EMail: mnot@mnot.net
URI: http://www.mnot.net/ URI: http://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 79 change blocks. 
304 lines changed or deleted 215 lines changed or added

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