< draft-ietf-httpbis-p6-cache-17.txt   draft-ietf-httpbis-p6-cache-18.txt >
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: May 3, 2012 J. Mogul Expires: July 7, 2012 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
M. Nottingham, Ed. M. Nottingham, Ed.
Rackspace Rackspace
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
October 31, 2011 January 4, 2012
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-17 draft-ietf-httpbis-p6-cache-18
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 6 of the information initiative since 1990. This document is Part 6 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. "HTTP/1.1" and, taken together, obsoletes RFC 2616.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.18. The changes in this draft are summarized in Appendix C.19.
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 May 3, 2012. This Internet-Draft will expire on July 7, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7 1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8
1.4.2. ABNF Rules defined in other Parts of the 1.4.2. ABNF Rules defined in other Parts of the
Specification . . . . . . . . . . . . . . . . . . . . 8 Specification . . . . . . . . . . . . . . . . . . . . 8
1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8 1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9
2.2. Constructing Responses from Caches . . . . . . . . . . . . 10 2.2. Constructing Responses from Caches . . . . . . . . . . . . 10
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 13
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 14
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 16
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16
2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17 2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18
2.6. Shared Caching of Authenticated Responses . . . . . . . . 18 2.6. Shared Caching of Authenticated Responses . . . . . . . . 18
2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19 2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19
2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20 2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
3.2.2. Response Cache-Control Directives . . . . . . . . . . 23 3.2.2. Response Cache-Control Directives . . . . . . . . . . 23
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32 3.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 3.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 31
5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32 3.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 31
5.2. Header Field Registration . . . . . . . . . . . . . . . . 33 3.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 3.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 31
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 3.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . . 33 3.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 34 3.7. History Lists . . . . . . . . . . . . . . . . . . . . . . 32
3.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 32
3.8.1. Cache Directive Registry . . . . . . . . . . . . . . . 32
3.8.2. Warn Code Registry . . . . . . . . . . . . . . . . . . 33
3.9. Header Field Registration . . . . . . . . . . . . . . . . 33
4. Security Considerations . . . . . . . . . . . . . . . . . . . 34
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1. Normative References . . . . . . . . . . . . . . . . . . . 34
6.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 35 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 36 publication) . . . . . . . . . . . . . . . . . . . . 37
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 38
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 38 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 39
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 38 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 39
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 39
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 39 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 40
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 39 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 40
C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39 C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 40
C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 40 C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 41
C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40 C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 41
C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41 C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41
C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 41 C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 42
C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 41 C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 42
C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 41 C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 42
C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42 C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42
C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 42 C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 43
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 C.19. Since draft-ietf-httpbis-p6-cache-17 . . . . . . . . . . . 43
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
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 11, line 11 skipping to change at page 11, line 11
o The presented effective request URI (Section 4.3 of [Part1]) and o The presented effective request URI (Section 4.3 of [Part1]) and
that of the stored response match, and that of the stored response match, and
o the request method associated with the stored response allows it o the request method associated with the stored response allows it
to be used for the presented request, and to be used for the presented request, and
o selecting header fields nominated by the stored response (if any) o selecting header fields nominated by the stored response (if any)
match those presented (see Section 2.7), and match those presented (see Section 2.7), and
o the presented request and stored response are free from directives o the presented request does not contain the no-cache pragma
that would prevent its use (see Section 3.2 and Section 3.4), and (Section 3.4), nor the no-cache cache directive (Section 3.2.1),
unless the stored response is successfully validated
(Section 2.4), and
o the stored response does not contain the no-cache cache directive
(Section 3.2.2), unless it is successfully validated
(Section 2.4), and
o the stored response is either: o the stored response is either:
* fresh (see Section 2.3), or * fresh (see Section 2.3), or
* allowed to be served stale (see Section 2.3.3), or * allowed to be served stale (see Section 2.3.3), or
* successfully validated (see Section 2.4). * successfully validated (see Section 2.4).
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
skipping to change at page 12, line 34 skipping to change at page 12, line 40
expiration time. This specification does not provide specific expiration time. This specification does not provide specific
algorithms, but does impose worst-case constraints on their results. algorithms, but does impose worst-case constraints on their results.
The calculation to determine if a response is fresh is: The calculation to determine if a response is fresh is:
response_is_fresh = (freshness_lifetime > current_age) response_is_fresh = (freshness_lifetime > current_age)
The freshness_lifetime is defined in Section 2.3.1; the current_age The freshness_lifetime is defined in Section 2.3.1; the current_age
is defined in Section 2.3.2. is defined in Section 2.3.2.
Additionally, clients might need to influence freshness calculation. Additionally, clients can influence freshness calculation -- either
They can do this using several request cache directives, with the constraining it relaxing it -- by using the max-age and min-fresh
effect of either increasing or loosening constraints on freshness. request cache directives. See Section 3.2.1 for details.
See Section 3.2.1.
Note that freshness applies only to cache operation; it cannot be Note that freshness applies only to cache operation; it cannot be
used to force a user agent to refresh its display or reload a used to force a user agent to refresh its display or reload a
resource. See Section 4 for an explanation of the difference between resource. See Section 3.7 for an explanation of the difference
caches and history mechanisms. between caches and history mechanisms.
2.3.1. Calculating Freshness Lifetime 2.3.1. Calculating Freshness Lifetime
A cache can calculate the freshness lifetime (denoted as A cache can calculate the freshness lifetime (denoted as
freshness_lifetime) of a response by using the first match of: freshness_lifetime) of a response by using the first match of:
o If the cache is shared and the s-maxage response cache directive o If the cache is shared and the s-maxage response cache directive
(Section 3.2.2) is present, use its value, or (Section 3.2.2) is present, use its value, or
o If the max-age response cache directive (Section 3.2.2) is o If the max-age response cache directive (Section 3.2.2) is
skipping to change at page 15, line 10 skipping to change at page 15, line 20
2. the "corrected_age_value", if all of the caches along the 2. the "corrected_age_value", if all of the caches along the
response path implement HTTP/1.1. A cache MUST interpret this response path implement HTTP/1.1. A cache MUST interpret this
value relative to the time the request was initiated, not the value relative to the time the request was initiated, not the
time that the response was received. time that the response was received.
apparent_age = max(0, response_time - date_value); apparent_age = max(0, response_time - date_value);
response_delay = response_time - request_time; response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay; corrected_age_value = age_value + response_delay;
These are combined as These SHOULD be combined as
corrected_initial_age = max(apparent_age, corrected_age_value); corrected_initial_age = max(apparent_age, corrected_age_value);
unless the cache is confident in the value of the Age header (e.g.,
because there are no HTTP/1.0 hops in the Via header), in which case
the corrected_age_value MAY be used as the corrected_initial_age.
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 HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
skipping to change at page 31, line 12 skipping to change at page 31, line 12
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.
110 Response is stale 3.6.1. 110 Response is Stale
A cache SHOULD include this whenever the returned response is A cache SHOULD include this whenever the returned response is stale.
stale.
111 Revalidation failed 3.6.2. 111 Revalidation Failed
A cache SHOULD include this when returning a stale response A cache SHOULD include this when returning a stale response because
because an attempt to validate the response failed, due to an an attempt to validate the response failed, due to an inability to
inability to reach the server. reach the server.
112 Disconnected operation 3.6.3. 112 Disconnected Operation
A cache SHOULD include this if it is intentionally disconnected A cache SHOULD include this if it is intentionally disconnected from
from the rest of the network for a period of time. the rest of the network for a period of time.
113 Heuristic expiration 3.6.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 lifetime greater than 24 hours and the response's age is greater than
than 24 hours. 24 hours.
199 Miscellaneous warning 3.6.5. 199 Miscellaneous Warning
The warning text can include arbitrary information to be presented The warning text can include arbitrary information to be presented to
to a human user, or logged. A system receiving this warning MUST a human user, or logged. A system receiving this warning MUST NOT
NOT take any automated action, besides presenting the warning to take any automated action, besides presenting the warning to the
the user. user.
214 Transformation applied 3.6.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, representation, such as changing the content-coding, media-type, or
or modifying the representation data, unless this Warning code modifying the representation data, unless this Warning code already
already appears in the response. appears in the response.
299 Miscellaneous persistent warning 3.6.7. 299 Miscellaneous Persistent Warning
The warning text can include arbitrary information to be presented The warning text can include arbitrary information to be presented to
to a human user, or logged. A system receiving this warning MUST a human user, or logged. A system receiving this warning MUST NOT
NOT take any automated action. take any automated action.
4. History Lists 3.6.8. Warn Code Extensions
The HTTP Warn Code Registry defines the name space for warn codes.
A registration MUST include the following fields:
o Warn Code (3 digits)
o Short Description
o Pointer to specification text
Values to be added to this name space are subject to IETF review
([RFC5226], Section 4.1).
The registry itself is maintained at
<http://www.iana.org/assignments/http-warn-codes>.
3.7. History Lists
User agents often have history mechanisms, such as "Back" buttons and User agents often have history mechanisms, such as "Back" buttons and
history lists, that can be used to redisplay a representation history lists, that can be used to redisplay a representation
retrieved earlier in a session. retrieved earlier in a session.
The freshness model (Section 2.3) does not necessarily apply to The freshness model (Section 2.3) does not necessarily apply to
history mechanisms. I.e., a history mechanism can display a previous history mechanisms. I.e., a history mechanism can display a previous
representation even if it has expired. representation even if it has expired.
This does not prohibit the history mechanism from telling the user This does not prohibit the history mechanism from telling the user
that a view might be stale, or from honoring cache directives (e.g., that a view might be stale, or from honoring cache directives (e.g.,
Cache-Control: no-store). Cache-Control: no-store).
5. IANA Considerations 3.8. IANA Considerations
5.1. Cache Directive Registry 3.8.1. Cache Directive Registry
The registration procedure for HTTP Cache Directives is defined by The registration procedure for HTTP Cache Directives is defined by
Section 3.2.3 of this document. Section 3.2.3 of this document.
The HTTP Cache Directive Registry shall be created at The HTTP Cache Directive 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:
+------------------------+------------------------------+ +------------------------+------------------------------+
| Cache Directive | Reference | | Cache Directive | Reference |
skipping to change at page 33, line 5 skipping to change at page 33, line 24
| no-transform | Section 3.2.1, Section 3.2.2 | | no-transform | Section 3.2.1, Section 3.2.2 |
| only-if-cached | Section 3.2.1 | | only-if-cached | Section 3.2.1 |
| private | Section 3.2.2 | | private | Section 3.2.2 |
| proxy-revalidate | Section 3.2.2 | | proxy-revalidate | Section 3.2.2 |
| public | Section 3.2.2 | | public | Section 3.2.2 |
| s-maxage | Section 3.2.2 | | s-maxage | Section 3.2.2 |
| stale-if-error | [RFC5861], Section 4 | | stale-if-error | [RFC5861], Section 4 |
| stale-while-revalidate | [RFC5861], Section 3 | | stale-while-revalidate | [RFC5861], Section 3 |
+------------------------+------------------------------+ +------------------------+------------------------------+
5.2. Header Field Registration 3.8.2. Warn Code Registry
The registration procedure for HTTP Warn Codes is defined by
Section 3.6.8 of this document.
The HTTP Warn Code Registry shall be created at
<http://www.iana.org/assignments/http-cache-directives> and be
populated with the registrations below:
+-----------+----------------------------------+---------------+
| Warn Code | Short Description | Reference |
+-----------+----------------------------------+---------------+
| 110 | Response is Stale | Section 3.6.1 |
| 111 | Revalidation Failed | Section 3.6.2 |
| 112 | Disconnected Operation | Section 3.6.3 |
| 113 | Heuristic Expiration | Section 3.6.4 |
| 199 | Miscellaneous Warning | Section 3.6.5 |
| 214 | Transformation Applied | Section 3.6.6 |
| 299 | Miscellaneous Persistent Warning | Section 3.6.7 |
+-----------+----------------------------------+---------------+
3.9. 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 3.1 | | Age | http | standard | Section 3.1 |
| Cache-Control | http | standard | Section 3.2 | | Cache-Control | http | standard | Section 3.2 |
| Expires | http | standard | Section 3.3 | | Expires | http | standard | Section 3.3 |
| Pragma | http | standard | Section 3.4 | | Pragma | http | standard | Section 3.4 |
| Vary | http | standard | Section 3.5 | | Vary | http | standard | Section 3.5 |
| Warning | http | standard | Section 3.6 | | Warning | http | standard | Section 3.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".
6. Security Considerations 4. 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.
7. Acknowledgments 5. Acknowledgments
See Section 11 of [Part1]. See Section 11 of [Part1].
8. References 6. References
8.1. Normative References 6.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-17 and Message Parsing", draft-ietf-httpbis-p1-messaging-18
(work in progress), October 2011. (work in progress), January 2012.
[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-17 (work in Semantics", draft-ietf-httpbis-p2-semantics-18 (work in
progress), October 2011. progress), January 2012.
[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-17 (work in Requests", draft-ietf-httpbis-p4-conditional-18 (work in
progress), October 2011. progress), January 2012.
[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-17 (work Partial Responses", draft-ietf-httpbis-p5-range-18 (work
in progress), October 2011. in progress), January 2012.
[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-17 (work in progress), draft-ietf-httpbis-p7-auth-18 (work in progress),
October 2011. January 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.
8.2. Informative References 6.2. Informative References
[RFC1305] Mills, D., "Network Time Protocol (Version 3) [RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992. Specification, Implementation", RFC 1305, March 1992.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
skipping to change at page 42, line 22 skipping to change at page 43, line 15
C.18. Since draft-ietf-httpbis-p6-cache-16 C.18. Since draft-ietf-httpbis-p6-cache-16
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy" HTTP's error-handling philosophy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/317>: "Cache-Control o <http://tools.ietf.org/wg/httpbis/trac/ticket/317>: "Cache-Control
directive case sensitivity" directive case sensitivity"
C.19. Since draft-ietf-httpbis-p6-cache-17
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/293>: "Interaction
of request and response Cache-Control"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/212>: "Refining age
for 1.1 proxy chains"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/274>: "warn-code
registry"
Index Index
1
110 Response is Stale (warn code) 31
111 Revalidation Failed (warn code) 31
112 Disconnected Operation (warn code) 31
113 Heuristic Expiration (warn code) 31
199 Miscellaneous Warning (warn code) 31
2
214 Transformation Applied (warn code) 31
299 Miscellaneous Persistent Warning (warn code) 31
A A
age 6 age 6
Age header field 20 Age header field 20
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 22, 25 max-age 22, 25
max-stale 22 max-stale 22
min-fresh 22 min-fresh 22
must-revalidate 25 must-revalidate 25
no-cache 21, 24 no-cache 22, 24
no-store 22, 24 no-store 22, 24
no-transform 23, 25 no-transform 23, 25
only-if-cached 23 only-if-cached 23
private 23 private 23
proxy-revalidate 25 proxy-revalidate 25
public 23 public 23
s-maxage 25 s-maxage 25
cache entry 8 cache entry 8
cache key 8 cache key 8
Cache-Control header field 21 Cache-Control header field 21
skipping to change at page 43, line 50 skipping to change at page 45, line 19
Cache Directive 22, 25 Cache Directive 22, 25
max-stale max-stale
Cache Directive 22 Cache Directive 22
min-fresh min-fresh
Cache Directive 22 Cache Directive 22
must-revalidate must-revalidate
Cache Directive 25 Cache Directive 25
N N
no-cache no-cache
Cache Directive 21, 24 Cache Directive 22, 24
no-store no-store
Cache Directive 22, 24 Cache Directive 22, 24
no-transform no-transform
Cache Directive 23, 25 Cache Directive 23, 25
O O
only-if-cached only-if-cached
Cache Directive 23 Cache Directive 23
P P
skipping to change at page 44, line 35 skipping to change at page 46, line 4
shared cache 5 shared cache 5
stale 6 stale 6
strong validator 7 strong validator 7
V V
validator 6 validator 6
strong 7 strong 7
Vary header field 28 Vary header field 28
W W
Warn Codes
110 Response is Stale 31
111 Revalidation Failed 31
112 Disconnected Operation 31
113 Heuristic Expiration 31
199 Miscellaneous Warning 31
214 Transformation Applied 31
299 Miscellaneous Persistent Warning 31
Warning header field 29 Warning header field 29
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
 End of changes. 52 change blocks. 
92 lines changed or deleted 181 lines changed or added

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