draft-ietf-httpbis-p6-cache-09.txt   draft-ietf-httpbis-p6-cache-latest.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: September 9, 2010 J. Mogul Expires: September 18, 2010 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
M. Nottingham, Ed. M. Nottingham, Ed.
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
March 8, 2010 March 17, 2010
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-09 draft-ietf-httpbis-p6-cache-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. This document is Part 6 of the seven-part specification systems. This document is Part 6 of the seven-part specification
that defines the protocol referred to as "HTTP/1.1" and, taken that defines the protocol referred to as "HTTP/1.1" and, taken
together, obsoletes RFC 2616. Part 6 defines requirements on HTTP together, obsoletes RFC 2616. Part 6 defines requirements on HTTP
caches and the associated header fields that control cache behavior caches and the associated header fields that control cache behavior
or indicate cacheable response messages. or indicate cacheable response messages.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix C.10. The changes in this draft are summarized in Appendix C.11.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010. This Internet-Draft will expire on September 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 24 skipping to change at page 3, line 24
Specification . . . . . . . . . . . . . . . . . . . . 7 Specification . . . . . . . . . . . . . . . . . . . . 7
2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7 2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7 2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7
2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8
2.2. Constructing Responses from Caches . . . . . . . . . . . . 9 2.2. Constructing Responses from Caches . . . . . . . . . . . . 9
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 15
2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15
2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18
3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
5.1. Message Header Registration . . . . . . . . . . . . . . . 28 5.1. Message Header Registration . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Compatibility with Previous Versions . . . . . . . . 30 Appendix A. Compatibility with Previous Versions . . . . . . . . 30
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 30 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 30
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 30 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 32 publication) . . . . . . . . . . . . . . . . . . . . 33
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 32 C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 32 C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 33 C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 33 C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34 C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 34 C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35 C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35
C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 35 C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 36
C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 36
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 10, line 14 skipping to change at page 10, line 14
having received a corresponding response. having received a corresponding response.
Also, note that unsafe requests might invalidate already stored Also, note that unsafe requests might invalidate already stored
responses; see Section 2.5. responses; see Section 2.5.
Caches MUST use the most recent response (as determined by the Date Caches MUST use the most recent response (as determined by the Date
header) when more than one suitable response is stored. They can header) when more than one suitable response is stored. They can
also forward a request with "Cache-Control: max-age=0" or "Cache- also forward a request with "Cache-Control: max-age=0" or "Cache-
Control: no-cache" to disambiguate which response to use. Control: no-cache" to disambiguate which response to use.
[[TODO-header-properties: end-to-end and hop-by-hop headers, non-
modifiable headers removed; re-spec in p1]]
2.3. Freshness Model 2.3. Freshness Model
When a response is "fresh" in the cache, it can be used to satisfy When a response is "fresh" in the cache, it can be used to satisfy
subsequent requests without contacting the origin server, thereby subsequent requests without contacting the origin server, thereby
improving efficiency. improving efficiency.
The primary mechanism for determining freshness is for an origin The primary mechanism for determining freshness is for an origin
server to provide an explicit expiration time in the future, using server to provide an explicit expiration time in the future, using
either the Expires header (Section 3.3) or the max-age response cache either the Expires header (Section 3.3) or the max-age response cache
directive (Section 3.2.2). Generally, origin servers will assign directive (Section 3.2.2). Generally, origin servers will assign
skipping to change at page 11, line 32 skipping to change at page 11, line 29
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
present, use its value, or present, use its value, or
o If the Expires response header (Section 3.3) is present, use its o If the Expires response header (Section 3.3) is present, use its
value minus the value of the Date response header, or value minus the value of the Date response header, or
o Otherwise, no explicit expiration time is present in the response, o Otherwise, no explicit expiration time is present in the response.
but a heuristic may be used; see Section 2.3.1.1. A heuristic freshness lifetime might be applicable; see
Section 2.3.1.1.
Note that this calculation is not vulnerable to clock skew, since all Note that this calculation is not vulnerable to clock skew, since all
of the information comes from the origin server. of the information comes from the origin server.
2.3.1.1. Calculating Heuristic Freshness 2.3.1.1. 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 of 200, 203, 206, 300, 301 or 410, a heuristic has a status code of 200, 203, 206, 300, 301 or 410, a heuristic
expiration time can be calculated. Heuristics MUST NOT be used for expiration time can be calculated. Heuristics MUST NOT be used for
other response status codes. other response status codes.
skipping to change at page 12, line 19 skipping to change at page 12, line 18
2.3.2. Calculating Age 2.3.2. Calculating Age
HTTP/1.1 uses the Age response-header to convey the estimated age of HTTP/1.1 uses the Age response-header to convey the estimated age of
the response message when obtained from a cache. The Age field value the response message when obtained from a cache. The Age field value
is the cache's estimate of the amount of time since the response was is the cache's estimate of the amount of time since the response was
generated or validated by the origin server. In essence, the Age generated or validated by the origin server. In essence, the Age
value is the sum of the time that the response has been resident in value is the sum of the time that the response has been resident in
each of the caches along the path from the origin server, plus the each of the caches along the path from the origin server, plus the
amount of time it has been in transit along network paths. amount of time it has been in transit along network paths.
The term "age_value" denotes the value of the Age header, in a form The following data is used for the age calculation:
appropriate for arithmetic operations.
HTTP/1.1 requires origin servers to send a Date header, if possible, age_value
with every response, giving the time at which the response was
generated (see Section 9.3 of [Part1]). The term "date_value"
denotes the value of the Date header, in a form appropriate for
arithmetic operations.
The term "now" means "the current value of the clock at the host The term "age_value" denotes the value of the Age header
performing the calculation." Hosts that use HTTP, but especially (Section 3.1), in a form appropriate for arithmetic operation; or
hosts running origin servers and caches, SHOULD use NTP [RFC1305] or 0, if not available.
some similar protocol to synchronize their clocks to a globally
accurate time standard.
A response's age can be calculated in two entirely independent ways: date_value
1. now minus date_value, if the local clock is reasonably well HTTP/1.1 requires origin servers to send a Date header, if
synchronized to the origin server's clock. If the result is possible, with every response, giving the time at which the
negative, the result is replaced by zero. response was generated. The term "date_value" denotes the value
of the Date header, in a form appropriate for arithmetic
operations. See Section 9.3 of [Part1] for the definition of the
Date header, and for requirements regarding responses without a
Date response header.
2. age_value, if all of the caches along the response path implement now
HTTP/1.1.
These are combined as The term "now" means "the current value of the clock at the host
performing the calculation". Hosts that use HTTP, but especially
hosts running origin servers and caches, SHOULD use NTP
([RFC1305]) or some similar protocol to synchronize their clocks
to a globally accurate time standard.
corrected_received_age = max(now - date_value, age_value) request_time
When an Age value is received, it MUST be interpreted relative to the The current value of the clock at the host at the time the request
time the request was initiated, not the time that the response was resulting in the stored response was made.
received.
corrected_initial_age = corrected_received_age response_time
+ (now - request_time)
where "request_time" is the time (according to the local clock) when The current value of the clock at the host at the time the
the request that elicited this response was sent. response was received.
The current_age of a stored response can then be calculated by adding A response's age can be calculated in two entirely independent ways:
the amount of time (in seconds) since the stored response was last
validated by the origin server to the corrected_initial_age.
In summary: 1. the "apparent_age": response_time minus date_value, if the local
clock is reasonably well synchronized to the origin server's
clock. If the result is negative, the result is replaced by
zero.
age_value - Age header field-value received with the response 2. the "corrected_age_value", if all of the caches along the
date_value - Date header field-value received with the response response path implement HTTP/1.1; note this value MUST be
request_time - local time when the cache made the request interpreted relative to the time the request was initiated, not
resulting in the stored response the time that the response was received.
response_time - local time when the cache received the response
now - current local time
apparent_age = max(0, response_time - date_value); apparent_age = max(0, response_time - date_value);
corrected_received_age = max(apparent_age, age_value);
response_delay = response_time - request_time; response_delay = response_time - request_time;
corrected_initial_age = corrected_received_age + response_delay; corrected_age_value = age_value + response_delay;
These are combined as
corrected_initial_age = max(apparent_age, corrected_age_value);
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
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;
2.3.3. Serving Stale Responses 2.3.3. Serving Stale Responses
A "stale" response is one that either has explicit expiry A "stale" response is one that either has explicit expiry information
information, or is allowed to have heuristic expiry calculated, but or is allowed to have heuristic expiry calculated, but is not fresh
is not fresh according to the calculations in Section 2.3. according to the calculations in Section 2.3.
Caches MUST NOT return a stale response if it is prohibited by an Caches 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 3.2.2). see Section 3.2.2).
Caches SHOULD NOT return stale responses unless they are disconnected Caches SHOULD NOT return stale responses unless they are 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 otherwise explicitly allowed (e.g., the max-stale forward path) or otherwise explicitly allowed (e.g., the max-stale
skipping to change at page 19, line 21 skipping to change at page 19, line 27
This directive is NOT a reliable or sufficient mechanism for This directive is NOT a reliable or sufficient mechanism for
ensuring privacy. In particular, malicious or compromised caches ensuring privacy. In particular, malicious or compromised caches
might not recognize or obey this directive, and communications might not recognize or obey this directive, and communications
networks may be vulnerable to eavesdropping. networks may be vulnerable to eavesdropping.
max-age max-age
The max-age request directive indicates that the client is willing The max-age request directive indicates that the client is willing
to accept a response whose age is no greater than the specified to accept a response whose age is no greater than the specified
time in seconds. Unless max-stale directive is also included, the time in seconds. Unless the max-stale request directive is also
client is not willing to accept a stale response. present, the client is not willing to accept a stale response.
max-stale max-stale
The max-stale request directive indicates that the client is The max-stale request directive indicates that the client is
willing to accept a response that has exceeded its expiration willing to accept a response that has exceeded its expiration
time. If max-stale is assigned a value, then the client is time. If max-stale is assigned a value, then the client is
willing to accept a response that has exceeded its expiration time willing to accept a response that has exceeded its expiration time
by no more than the specified number of seconds. If no value is by no more than the specified number of seconds. If no value is
assigned to max-stale, then the client is willing to accept a assigned to max-stale, then the client is willing to accept a
stale response of any age. [[TODO-staleness: of any staleness? stale response of any age. [[TODO-staleness: of any staleness?
skipping to change at page 29, line 24 skipping to change at page 29, line 42
suggestions and comments from individuals including: Shel Kaphan, suggestions and comments from individuals including: Shel Kaphan,
Paul Leach, Koen Holtman, David Morris, and Larry Masinter. Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
8. References 8. References
8.1. Normative References 8.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-09 and Message Parsing",
(work in progress), March 2010. draft-ietf-httpbis-p1-messaging-latest (work in progress),
March 2010.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-09 (work in Semantics", draft-ietf-httpbis-p2-semantics-latest (work
progress), March 2010. in progress), March 2010.
[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-09 (work in Requests", draft-ietf-httpbis-p4-conditional-latest (work
progress), March 2010. in progress), March 2010.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-09 (work Partial Responses", draft-ietf-httpbis-p5-range-latest
in progress), March 2010. (work in progress), March 2010.
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
draft-ietf-httpbis-p7-auth-09 (work in progress), draft-ietf-httpbis-p7-auth-latest (work in progress),
March 2010. March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
8.2. Informative References 8.2. Informative References
skipping to change at page 36, line 5 skipping to change at page 36, line 28
Affected issues: Affected issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes
and caching and caching
Partly resolved issues: Partly resolved issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
13.5.1 and 13.5.2" 13.5.1 and 13.5.2"
C.11. Since draft-ietf-httpbis-p6-cache-09
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/29>: "Age
calculation"
Index Index
A A
age 6 age 6
Age header 17 Age header 17
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 19, 22 max-age 19, 22
max-stale 19 max-stale 19
min-fresh 19 min-fresh 19
must-revalidate 21 must-revalidate 21
no-cache 18, 21 no-cache 18, 21
no-store 18, 21 no-store 19, 21
no-transform 19, 22 no-transform 19, 22
only-if-cached 19 only-if-cached 20
private 20 private 20
proxy-revalidate 22 proxy-revalidate 22
public 20 public 20
s-maxage 22 s-maxage 22
Cache-Control header 18 Cache-Control header 18
cacheable 5 cacheable 5
E E
Expires header 23 Expires header 23
explicit expiration time 5 explicit expiration time 5
skipping to change at page 36, line 48 skipping to change at page 37, line 30
G G
Grammar Grammar
Age 17 Age 17
Age-v 17 Age-v 17
Cache-Control 18 Cache-Control 18
Cache-Control-v 18 Cache-Control-v 18
cache-extension 18 cache-extension 18
cache-request-directive 18 cache-request-directive 18
cache-response-directive 20 cache-response-directive 20
delta-seconds 17 delta-seconds 17
Expires 23 Expires 24
Expires-v 23 Expires-v 24
extension-pragma 24 extension-pragma 24
Pragma 24 Pragma 24
pragma-directive 24 pragma-directive 24
Pragma-v 24 Pragma-v 24
Vary 25 Vary 25
Vary-v 25 Vary-v 25
warn-agent 26 warn-agent 26
warn-code 26 warn-code 26
warn-date 26 warn-date 26
warn-text 26 warn-text 26
Warning 26 Warning 26
Warning-v 26 Warning-v 26
warning-value 26 warning-value 26
H H
Headers Headers
Age 17 Age 17
Cache-Control 18 Cache-Control 18
Expires 23 Expires 23
Pragma 24 Pragma 24
Vary 24 Vary 25
Warning 25 Warning 25
heuristic expiration time 5 heuristic expiration time 5
M M
max-age max-age
Cache Directive 19, 22 Cache Directive 19, 22
max-stale max-stale
Cache Directive 19 Cache Directive 19
min-fresh min-fresh
Cache Directive 19 Cache Directive 19
must-revalidate must-revalidate
Cache Directive 21 Cache Directive 21
N N
no-cache no-cache
Cache Directive 18, 21 Cache Directive 18, 21
no-store no-store
Cache Directive 18, 21 Cache Directive 19, 21
no-transform no-transform
Cache Directive 19, 22 Cache Directive 19, 22
O O
only-if-cached only-if-cached
Cache Directive 19 Cache Directive 20
P P
Pragma header 24 Pragma header 24
private private
Cache Directive 20 Cache Directive 20
proxy-revalidate proxy-revalidate
Cache Directive 22 Cache Directive 22
public public
Cache Directive 20 Cache Directive 20
S S
s-maxage s-maxage
Cache Directive 22 Cache Directive 22
stale 6 stale 6
V V
validator 6 validator 6
Vary header 24 Vary header 25
W W
Warning header 25 Warning header 25
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
 End of changes. 47 change blocks. 
84 lines changed or deleted 97 lines changed or added

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