draft-ietf-httpbis-p6-cache-18.txt | draft-ietf-httpbis-p6-cache-19.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) Y. Lafon, Ed. | |||
Intended status: Standards Track Alcatel-Lucent | Intended status: Standards Track W3C | |||
Expires: July 7, 2012 J. Mogul | Expires: September 13, 2012 M. Nottingham, Ed. | |||
HP | ||||
H. Frystyk | ||||
Microsoft | ||||
L. Masinter | ||||
Adobe | ||||
P. Leach | ||||
Microsoft | ||||
T. Berners-Lee | ||||
W3C/MIT | ||||
Y. Lafon, Ed. | ||||
W3C | ||||
M. Nottingham, Ed. | ||||
Rackspace | Rackspace | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
January 4, 2012 | March 12, 2012 | |||
HTTP/1.1, part 6: Caching | HTTP/1.1, part 6: Caching | |||
draft-ietf-httpbis-p6-cache-18 | draft-ietf-httpbis-p6-cache-19 | |||
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 1, line 40 | |||
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.19. | The changes in this draft are summarized in Appendix C.20. | |||
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 July 7, 2012. | This Internet-Draft will expire on September 13, 2012. | |||
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 3, line 24 | skipping to change at page 3, line 11 | |||
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 . . . . . . . . . . . . . . . . . . . . . 12 | 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 12 | |||
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 13 | 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 13 | |||
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 14 | 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 14 | |||
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 16 | 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 with 304 Not Modified . . . . . . 17 | |||
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18 | 2.5. Updating Caches with HEAD Responses . . . . . . . . . . . 18 | |||
2.6. Shared Caching of Authenticated Responses . . . . . . . . 18 | 2.6. Request Methods that Invalidate . . . . . . . . . . . . . 18 | |||
2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19 | 2.7. Shared Caching of Authenticated Responses . . . . . . . . 19 | |||
2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20 | 2.8. Caching Negotiated Responses . . . . . . . . . . . . . . . 19 | |||
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20 | 2.9. Combining Partial Content . . . . . . . . . . . . . . . . 20 | |||
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 21 | |||
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
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 . . . . . . . . . . . 22 | |||
3.2.2. Response Cache-Control Directives . . . . . . . . . . 23 | 3.2.2. Response Cache-Control Directives . . . . . . . . . . 24 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
3.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31 | 3.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31 | |||
3.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 31 | 3.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 31 | |||
3.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 31 | 3.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 31 | |||
3.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 31 | 3.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 32 | |||
3.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 31 | 3.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 32 | |||
3.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 31 | 3.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 32 | |||
3.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31 | 3.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 32 | |||
3.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32 | 3.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32 | |||
3.7. History Lists . . . . . . . . . . . . . . . . . . . . . . 32 | 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
3.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 32 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
3.8.1. Cache Directive Registry . . . . . . . . . . . . . . . 32 | 5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 33 | |||
3.8.2. Warn Code Registry . . . . . . . . . . . . . . . . . . 33 | 5.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33 | |||
3.9. Header Field Registration . . . . . . . . . . . . . . . . 33 | 5.3. Header Field Registration . . . . . . . . . . . . . . . . 34 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | |||
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . . 34 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 | |||
6.2. Informative References . . . . . . . . . . . . . . . . . . 35 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 35 | |||
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35 | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36 | |||
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 36 | 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) . . . . . . . . . . . . . . . . . . . . 37 | publication) . . . . . . . . . . . . . . . . . . . . 37 | |||
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37 | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 38 | |||
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37 | C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 38 | |||
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 38 | 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 . . . . . . . . . . . 39 | |||
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 39 | C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 39 | |||
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 39 | C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 39 | |||
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 39 | C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 39 | |||
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 40 | C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 40 | |||
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 40 | C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 40 | |||
C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 40 | C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 40 | |||
C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 41 | C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 41 | |||
C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 41 | 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 . . . . . . . . . . . 42 | |||
C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 42 | C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 42 | |||
C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 42 | C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 42 | |||
C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 42 | 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 . . . . . . . . . . . 43 | |||
C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 43 | C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 43 | |||
C.19. Since draft-ietf-httpbis-p6-cache-17 . . . . . . . . . . . 43 | C.19. Since draft-ietf-httpbis-p6-cache-17 . . . . . . . . . . . 43 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 | C.20. Since draft-ietf-httpbis-p6-cache-18 . . . . . . . . . . . 43 | |||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 | ||||
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 7, line 45 | skipping to change at page 7, line 45 | |||
define specific error handling mechanisms, except in cases where it | define specific error handling mechanisms, except in cases where it | |||
has direct impact on security. This is because different uses of the | has direct impact on security. This is because different uses of the | |||
protocol require different error handling strategies; for example, a | protocol require different error handling strategies; for example, a | |||
Web browser may wish to transparently recover from a response where | Web browser may wish to transparently recover from a response where | |||
the Location header field doesn't parse according to the ABNF, | the Location header field doesn't parse according to the ABNF, | |||
whereby in a systems control protocol using HTTP, this type of error | whereby in a systems control protocol using HTTP, this type of error | |||
recovery could lead to dangerous consequences. | recovery could lead to dangerous consequences. | |||
1.4. Syntax Notation | 1.4. Syntax Notation | |||
This specification uses the ABNF syntax defined in Section 1.2 of | This specification uses the Augmented Backus-Naur Form (ABNF) | |||
[Part1] (which extends the syntax defined in [RFC5234] with a list | notation of [RFC5234] with the list rule extension defined in Section | |||
rule). Appendix B shows the collected ABNF, with the list rule | 1.2 of [Part1]. Appendix B shows the collected ABNF with the list | |||
expanded. | rule expanded. | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | |||
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | 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 | sequence of data), SP (space), and VCHAR (any visible US-ASCII | |||
character). | character). | |||
1.4.1. Core Rules | 1.4.1. Core Rules | |||
The core rules below are defined in [Part1]: | The core rules below are defined in [Part1]: | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 3.2.1> | |||
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> | quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> | |||
token = <token, defined in [Part1], Section 3.2.3> | token = <token, defined in [Part1], Section 3.2.4> | |||
1.4.2. ABNF Rules defined in other Parts of the Specification | 1.4.2. ABNF Rules defined in other Parts of the Specification | |||
The ABNF rules below are defined in other parts: | The ABNF rules below are defined in other parts: | |||
field-name = <field-name, defined in [Part1], Section 3.2> | field-name = <field-name, defined in [Part1], Section 3.2> | |||
HTTP-date = <HTTP-date, defined in [Part2], Section 8> | HTTP-date = <HTTP-date, defined in [Part2], Section 8> | |||
port = <port, defined in [Part1], Section 2.7> | port = <port, defined in [Part1], Section 2.7> | |||
pseudonym = <pseudonym, defined in [Part1], Section 8.8> | pseudonym = <pseudonym, defined in [Part1], Section 6.2> | |||
uri-host = <uri-host, defined in [Part1], Section 2.7> | uri-host = <uri-host, defined in [Part1], Section 2.7> | |||
1.5. Delta Seconds | 1.5. Delta Seconds | |||
The delta-seconds rule specifies a non-negative integer, representing | The delta-seconds rule specifies a non-negative integer, representing | |||
time in seconds. | time in seconds. | |||
delta-seconds = 1*DIGIT | delta-seconds = 1*DIGIT | |||
If an implementation receives a delta-seconds value larger than the | If an implementation receives a delta-seconds value larger than the | |||
skipping to change at page 9, line 21 | skipping to change at page 9, line 21 | |||
caching and defines something suitable for use as a cache key. | caching and defines something suitable for use as a cache key. | |||
The default cache key consists of the request method and target URI. | The default cache key consists of the request method and target URI. | |||
However, since HTTP caches in common use today are typically limited | However, since HTTP caches in common use today are typically limited | |||
to caching responses to GET, most implementations simply decline | to caching responses to GET, most implementations simply decline | |||
other methods and use only the URI as the key. | other methods and use only the URI as the key. | |||
If a request target is subject to content negotiation, its cache | If a request target is subject to content negotiation, its cache | |||
entry might consist of multiple stored responses, each differentiated | entry might consist of multiple stored responses, each differentiated | |||
by a secondary key for the values of the original request's selecting | by a secondary key for the values of the original request's selecting | |||
header fields (Section 2.7). | header fields (Section 2.8). | |||
2.1. Response Cacheability | 2.1. Response Cacheability | |||
A cache MUST NOT store a response to any request, unless: | A cache MUST NOT store a response to any request, unless: | |||
o The request method is understood by the cache and defined as being | o The request method is understood by the cache and defined as being | |||
cacheable, and | cacheable, and | |||
o the response status code is understood by the cache, and | o the response status code is understood by the cache, and | |||
o the "no-store" cache directive (see Section 3.2) does not appear | o the "no-store" cache directive (see Section 3.2) does not appear | |||
in request or response header fields, and | in request or response header fields, and | |||
o the "private" cache response directive (see Section 3.2.2 does not | o the "private" cache response directive (see Section 3.2.2) does | |||
appear in the response, if the cache is shared, and | not appear in the response, if the cache is shared, and | |||
o the "Authorization" header field (see Section 4.1 of [Part7]) does | o the "Authorization" header field (see Section 4.1 of [Part7]) does | |||
not appear in the request, if the cache is shared, unless the | not appear in the request, if the cache is shared, unless the | |||
response explicitly allows it (see Section 2.6), and | response explicitly allows it (see Section 2.7), and | |||
o the response either: | o the response either: | |||
* contains an Expires header field (see Section 3.3), or | * contains an Expires header field (see Section 3.3), or | |||
* contains a max-age response cache directive (see | * contains a max-age response cache directive (see | |||
Section 3.2.2), or | Section 3.2.2), or | |||
* contains a s-maxage response cache directive and the cache is | * contains a s-maxage response cache directive and the cache is | |||
shared, or | shared, or | |||
skipping to change at page 10, line 27 | skipping to change at page 10, line 27 | |||
Note that, in normal operation, most caches will not store a response | Note that, in normal operation, most caches will not store a response | |||
that has neither a cache validator nor an explicit expiration time, | that has neither a cache validator nor an explicit expiration time, | |||
as such responses are not usually useful to store. However, caches | as such responses are not usually useful to store. However, caches | |||
are not prohibited from storing such responses. | are not prohibited from storing such responses. | |||
A response message is considered complete when all of the octets | A response message is considered complete when all of the octets | |||
indicated by the message framing ([Part1]) are received prior to the | indicated by the message framing ([Part1]) are received prior to the | |||
connection being closed. If the request is GET, the response status | connection being closed. If the request is GET, the response status | |||
is 200 (OK), and the entire response header block has been received, | is 200 (OK), and the entire response header block has been received, | |||
a cache MAY store an incomplete response message-body if the cache | a cache MAY store an incomplete response message body if the cache | |||
entry is recorded as incomplete. Likewise, a 206 (Partial Content) | entry is recorded as incomplete. Likewise, a 206 (Partial Content) | |||
response MAY be stored as if it were an incomplete 200 (OK) cache | response MAY be stored as if it were an incomplete 200 (OK) cache | |||
entry. However, a cache MUST NOT store incomplete or partial content | entry. However, a cache MUST NOT store incomplete or partial content | |||
responses if it does not support the Range and Content-Range header | responses if it does not support the Range and Content-Range header | |||
fields or if it does not understand the range units used in those | fields or if it does not understand the range units used in those | |||
fields. | fields. | |||
A cache MAY complete a stored incomplete response by making a | A cache MAY complete a stored incomplete response by making a | |||
subsequent range request ([Part5]) and combining the successful | subsequent range request ([Part5]) and combining the successful | |||
response with the stored entry, as defined in Section 2.8. A cache | response with the stored entry, as defined in Section 2.9. A cache | |||
MUST NOT use an incomplete response to answer requests unless the | MUST NOT use an incomplete response to answer requests unless the | |||
response has been made complete or the request is partial and | response has been made complete or the request is partial and | |||
specifies a range that is wholly within the incomplete response. A | specifies a range that is wholly within the incomplete response. A | |||
cache MUST NOT send a partial response to a client without explicitly | cache MUST NOT send a partial response to a client without explicitly | |||
marking it as such using the 206 (Partial Content) status code. | marking it as such using the 206 (Partial Content) status code. | |||
2.2. Constructing Responses from Caches | 2.2. Constructing Responses from Caches | |||
For a presented request, a cache MUST NOT return a stored response, | For a presented request, a cache MUST NOT return a stored response, | |||
unless: | unless: | |||
o The presented effective request URI (Section 4.3 of [Part1]) and | o The presented effective request URI (Section 5.5 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.8), and | |||
o the presented request does not contain the no-cache pragma | o the presented request does not contain the no-cache pragma | |||
(Section 3.4), nor the no-cache cache directive (Section 3.2.1), | (Section 3.4), nor the no-cache cache directive (Section 3.2.1), | |||
unless the stored response is successfully validated | unless the stored response is successfully validated | |||
(Section 2.4), and | (Section 2.4), and | |||
o the stored response does not contain the no-cache cache directive | o the stored response does not contain the no-cache cache directive | |||
(Section 3.2.2), unless it is successfully validated | (Section 3.2.2), unless it is successfully validated | |||
(Section 2.4), and | (Section 2.4), and | |||
skipping to change at page 11, line 42 | skipping to change at page 11, line 42 | |||
validation, a cache MUST include a single Age header field | validation, a cache MUST include a single Age header field | |||
(Section 3.1) in the response with a value equal to the stored | (Section 3.1) in the response with a value equal to the stored | |||
response's current_age; see Section 2.3.2. | response's current_age; see Section 2.3.2. | |||
A cache MUST write through requests with methods that are unsafe | A cache MUST write through requests with methods that are unsafe | |||
(Section 6.1.1 of [Part2]) to the origin server; i.e., a cache must | (Section 6.1.1 of [Part2]) to the origin server; i.e., a cache must | |||
not generate a reply to such a request before having forwarded the | not generate a reply to such a request before having forwarded the | |||
request and having received a corresponding response. | 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 2.5. | responses; see Section 2.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. | |||
A cache that does not have a clock available MUST NOT use stored | A cache that does not have a clock available MUST NOT use stored | |||
responses without revalidating them on every use. A cache, | responses without revalidating them on every use. A cache, | |||
especially a shared cache, SHOULD use a mechanism, such as NTP | especially a shared cache, SHOULD use a mechanism, such as NTP | |||
[RFC1305], to synchronize its clock with a reliable external | [RFC1305], to synchronize its clock with a reliable external | |||
skipping to change at page 12, line 46 | skipping to change at page 12, line 46 | |||
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 can influence freshness calculation -- either | Additionally, clients can influence freshness calculation -- either | |||
constraining it relaxing it -- by using the max-age and min-fresh | constraining it relaxing it -- by using the max-age and min-fresh | |||
request cache directives. See Section 3.2.1 for details. | request cache directives. See Section 3.2.1 for details. | |||
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 3.7 for an explanation of the difference | resource. See Section 4 for an explanation of the difference between | |||
between caches and history mechanisms. | caches and history mechanisms. | |||
2.3.1. Calculating Freshness Lifetime | 2.3.1. Calculating Freshness Lifetime | |||
A cache can calculate the freshness lifetime (denoted as | A cache can calculate the freshness lifetime (denoted as | |||
freshness_lifetime) of a response by using the first match of: | freshness_lifetime) of a response by using the first match of: | |||
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 14, line 29 | skipping to change at page 14, line 29 | |||
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 3.1), in a form appropriate for arithmetic operation; or | (Section 3.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.2 of [Part2] for the definition of the | operations. See Section 10.2 of [Part2] for the definition of the | |||
Date header field, and for requirements regarding responses | 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. | |||
skipping to change at page 16, line 43 | skipping to change at page 16, line 43 | |||
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. | |||
2.4. Validation Model | 2.4. Validation Model | |||
When a cache has one or more stored responses for a requested URI, | When a cache has one or more stored responses for a requested URI, | |||
but cannot serve any of them (e.g., because they are not fresh, or | but cannot serve any of them (e.g., because they are not fresh, or | |||
one cannot be selected; see Section 2.7), it can use the conditional | one cannot be selected; see Section 2.8), it can use the conditional | |||
request mechanism [Part4] in the forwarded request to give the origin | request mechanism [Part4] in the forwarded request to give the origin | |||
server an opportunity to both select a valid stored response to be | server an opportunity to both select a valid stored response to be | |||
used, and to update it. This process is known as "validating" or | used, and to update it. This process is known as "validating" or | |||
"revalidating" the stored response. | "revalidating" the stored response. | |||
When sending such a conditional request, a cache adds an If-Modified- | When sending such a conditional request, a cache adds an If-Modified- | |||
Since header field whose value is that of the Last-Modified header | Since header field whose value is that of the Last-Modified header | |||
field from the selected (see Section 2.7) stored response, if | field from the selected (see Section 2.8) stored response, if | |||
available. | available. | |||
Additionally, a cache can add an If-None-Match header field whose | Additionally, a cache can add an If-None-Match header field whose | |||
value is that of the ETag header field(s) from all responses stored | value is that of the ETag header field(s) from all responses stored | |||
for the requested URI, if present. However, if any of the stored | for the requested URI, if present. However, if any of the stored | |||
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 | |||
skipping to change at page 17, line 30 | skipping to change at page 17, line 30 | |||
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 response while attempting to | o However, if a cache receives a 5xx response while attempting to | |||
validate a response, it can either forward this response to the | validate a response, it can either forward this response to the | |||
requesting client, or act as if the server failed to respond. In | requesting client, or act as if the server failed to respond. In | |||
the latter case, it can return a previously stored response (see | the latter case, it can return a previously stored response (see | |||
Section 2.3.3). | Section 2.3.3). | |||
2.4.1. Freshening Responses | 2.4.1. Freshening Responses with 304 Not Modified | |||
When a cache receives a 304 (Not Modified) response and already has | When a cache receives a 304 (Not Modified) response and already has | |||
one or more stored 200 (OK) responses for the same cache key, the | one or more stored 200 (OK) responses for the same cache key, the | |||
cache needs to identify which of the stored responses are updated by | cache needs to identify which of the stored responses are updated by | |||
this new response and then update the stored response(s) with the new | this new response and then update the stored response(s) with the new | |||
information provided in the 304 response. | information provided in the 304 response. | |||
o If the new response contains a strong validator, then that strong | o If the new response contains a strong validator, then that strong | |||
validator identifies the selected representation. All of the | validator identifies the selected representation. All of the | |||
stored responses with the same strong validator are selected. If | stored responses with the same strong validator are selected. If | |||
skipping to change at page 18, line 17 | skipping to change at page 18, line 17 | |||
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 3.6); | code 1xx (see Section 3.6); | |||
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 response to replace | o use other header fields provided in the 304 response to replace | |||
all instances of the corresponding header fields in the stored | all instances of the corresponding header fields in the stored | |||
response. | response. | |||
2.5. Request Methods that Invalidate | 2.5. Updating Caches with HEAD Responses | |||
A response to the HEAD method is identical to what an equivalent | ||||
request made with a GET would have been, except it lacks a body. | ||||
This property of HEAD responses is used to both invalidate and update | ||||
cached GET responses. | ||||
If one or more stored GET responses can be selected (as per | ||||
Section 2.8) for a HEAD request, and the Content-Length, ETag or | ||||
Last-Modified value of a HEAD response differs from that in a | ||||
selected GET response, the cache MUST consider that selected response | ||||
to be stale. | ||||
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 (as per Section 2.8), the cache SHOULD update the remaining | ||||
headers in the stored response using the following rules: | ||||
o delete any Warning header fields in the stored response with warn- | ||||
code 1xx (see Section 3.6); | ||||
o retain any Warning header fields in the stored response with warn- | ||||
code 2xx; and, | ||||
o use other header fields provided in the response to replace all | ||||
instances of the corresponding header fields in the stored | ||||
response. | ||||
2.6. Request Methods that Invalidate | ||||
Because unsafe request methods (Section 6.1.1 of [Part2]) such as | Because unsafe request methods (Section 6.1.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 4.3 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 | |||
header fields (if present) when a non-error response to a request | response header fields (if present) when a non-error response to a | |||
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 | |||
Content-Location header field if the host part of that URI differs | Content-Location response header field if the host part of that URI | |||
from the host part in the effective request URI (Section 4.3 of | differs from the host part in the effective request URI (Section 5.5 | |||
[Part1]). This helps prevent denial of service attacks. | of [Part1]). This helps prevent denial of service attacks. | |||
A cache MUST invalidate the effective request URI (Section 4.3 of | A cache MUST invalidate the effective request URI (Section 5.5 of | |||
[Part1]) when it receives a non-error response to a request with a | [Part1]) when it receives a non-error response to a request with a | |||
method whose safety is unknown. | method whose safety is unknown. | |||
Here, a "non-error response" is one with a 2xx or 3xx status code. | Here, a "non-error response" is one with a 2xx or 3xx status code. | |||
"Invalidate" means that the cache will either remove all stored | "Invalidate" means that the cache will either remove all stored | |||
responses related to the effective request URI, or will mark these as | responses related to the effective request URI, or will mark these as | |||
"invalid" and in need of a mandatory validation before they can be | "invalid" and in need of a mandatory validation before they can be | |||
returned in response to a subsequent request. | returned in response to a subsequent request. | |||
Note that this does not guarantee that all appropriate responses are | Note that this does not guarantee that all appropriate responses are | |||
invalidated. For example, the request that caused the change at the | invalidated. For example, the request that caused the change at the | |||
origin server might not have gone through the cache where a response | origin server might not have gone through the cache where a response | |||
is stored. | is stored. | |||
2.6. Shared Caching of Authenticated Responses | 2.7. Shared Caching of Authenticated Responses | |||
A shared cache MUST NOT use a cached response to a request with an | A shared cache MUST NOT use a cached response to a request with an | |||
Authorization header field (Section 4.1 of [Part7]) to satisfy any | Authorization header field (Section 4.1 of [Part7]) to satisfy any | |||
subsequent request unless a cache directive that allows such | subsequent request unless a cache directive that allows such | |||
responses to be stored is present in the response. | responses to be stored is present in the response. | |||
In this specification, the following Cache-Control response | In this specification, the following Cache-Control response | |||
directives (Section 3.2.2) have such an effect: must-revalidate, | directives (Section 3.2.2) have such an effect: must-revalidate, | |||
public, s-maxage. | public, s-maxage. | |||
Note that cached responses that contain the "must-revalidate" and/or | Note that cached responses that contain the "must-revalidate" and/or | |||
"s-maxage" response directives are not allowed to be served stale | "s-maxage" response directives are not allowed to be served stale | |||
(Section 2.3.3) by shared caches. In particular, a response with | (Section 2.3.3) by shared caches. In particular, a response with | |||
either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to | either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to | |||
satisfy a subsequent request without revalidating it on the origin | satisfy a subsequent request without revalidating it on the origin | |||
server. | server. | |||
2.7. Caching Negotiated Responses | 2.8. Caching Negotiated Responses | |||
When a cache receives a request that can be satisfied by a stored | When a cache receives a request that can be satisfied by a stored | |||
response that has a Vary header field (Section 3.5), it MUST NOT use | response that has a Vary header field (Section 3.5), it MUST NOT use | |||
that response unless all of the selecting header fields nominated by | that response unless all of the selecting header fields nominated by | |||
the Vary header field match in both the original request (i.e., that | the Vary header field match in both the original request (i.e., that | |||
associated with the stored response), and the presented request. | associated with the stored response), and the presented request. | |||
The selecting 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: | |||
skipping to change at page 20, line 13 | skipping to change at page 20, line 41 | |||
the selected response. | the selected response. | |||
If multiple selected responses are available, the most recent | If multiple selected responses are available, the most recent | |||
response (as determined by the Date header field) is used; see | response (as determined by the Date header field) is used; see | |||
Section 2.2. | Section 2.2. | |||
If no selected response is available, the cache can forward the | If no selected response is available, the cache can forward the | |||
presented request to the origin server in a conditional request; see | presented request to the origin server in a conditional request; see | |||
Section 2.4. | Section 2.4. | |||
2.8. Combining Partial Content | 2.9. Combining Partial Content | |||
A response might transfer only a partial representation if the | A response might transfer only a partial representation if the | |||
connection closed prematurely or if the request used one or more | connection closed prematurely or if the request used one or more | |||
Range specifiers ([Part5]). After several such transfers, a cache | Range specifiers ([Part5]). After several such transfers, a cache | |||
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 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 3.6); | code 1xx (see Section 3.6); | |||
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, | |||
skipping to change at page 23, line 43 | skipping to change at page 24, line 23 | |||
/ "must-revalidate" | / "must-revalidate" | |||
/ "proxy-revalidate" | / "proxy-revalidate" | |||
/ "max-age" "=" delta-seconds | / "max-age" "=" delta-seconds | |||
/ "s-maxage" "=" delta-seconds | / "s-maxage" "=" delta-seconds | |||
/ cache-extension | / cache-extension | |||
public | public | |||
The public response directive indicates that a response whose | The public response directive indicates that a response whose | |||
associated request contains an 'Authentication' header MAY be | associated request contains an 'Authentication' header MAY be | |||
stored (see Section 2.6). | stored (see Section 2.7). | |||
private | private | |||
The private response directive indicates that the response message | The private response directive indicates that the response message | |||
is intended for a single user and MUST NOT be stored by a shared | is intended for a single user and MUST NOT be stored by a shared | |||
cache. A private cache MAY store the response. | cache. A private cache MAY store the response. | |||
If the private response directive specifies one or more field- | If the private response directive specifies one or more field- | |||
names, this requirement is limited to the field-values associated | names, this requirement is limited to the field-values associated | |||
with the listed response header fields. That is, a shared cache | with the listed response header fields. That is, a shared cache | |||
MUST NOT store the specified field-names(s), whereas it MAY store | MUST NOT store the specified field-names(s), whereas it MAY store | |||
the remainder of the response message. | the remainder of the response message. | |||
Note: This usage of the word private only controls where the | Note: This usage of the word "private" only controls where the | |||
response can be stored; it cannot ensure the privacy of the | response can be stored; it cannot ensure the privacy of the | |||
message content. Also, private response directives with field- | message content. Also, private response directives with field- | |||
names are often handled by implementations as if an unqualified | names are often handled by implementations as if an unqualified | |||
private directive was received; i.e., the special handling for the | private directive was received; i.e., the special handling for the | |||
qualified form is not widely implemented. | qualified form is not widely implemented. | |||
no-cache | no-cache | |||
The no-cache response directive indicates that the response MUST | The no-cache response directive indicates that the response MUST | |||
NOT be used to satisfy a subsequent request without successful | NOT be used to satisfy a subsequent request without successful | |||
validation on the origin server. This allows an origin server to | validation on the origin server. This allows an origin server to | |||
prevent a cache from using it to satisfy a request without | prevent a cache from using it to satisfy a request without | |||
contacting it, even by caches that have been configured to return | contacting it, even by caches that have been configured to return | |||
stale responses. | stale responses. | |||
If the no-cache response directive specifies one or more field- | If the no-cache response directive specifies one or more field- | |||
names, this requirement is limited to the field-values associated | names, then a cache MAY use the response to satisfy a subsequent | |||
with the listed response header fields. That is, a cache MUST NOT | request, subject to any other restrictions on caching. However, | |||
send the specified field-name(s) in the response to a subsequent | any header fields in the response that have the field-name(s) | |||
request without successful validation on the origin server. This | listed MUST NOT be sent in the response to a subsequent request | |||
without successful revalidation with the origin server. This | ||||
allows an origin server to prevent the re-use of certain header | allows an origin server to prevent the re-use of certain header | |||
fields in a response, while still allowing caching of the rest of | fields in a response, while still allowing caching of the rest of | |||
the response. | the response. | |||
Note: Most HTTP/1.0 caches will not recognize or obey this | Note: Most HTTP/1.0 caches will not recognize or obey this | |||
directive. Also, no-cache response directives with field-names | directive. Also, no-cache response directives with field-names | |||
are often handled by implementations as if an unqualified no-cache | are often handled by implementations as if an unqualified no-cache | |||
directive was received; i.e., the special handling for the | directive was received; i.e., the special handling for the | |||
qualified form is not widely implemented. | qualified form is not widely implemented. | |||
skipping to change at page 27, line 9 | skipping to change at page 27, line 35 | |||
The HTTP Cache Directive Registry defines the name space for the | The HTTP Cache Directive Registry defines the name space for the | |||
cache directives. | cache directives. | |||
A registration MUST include the following fields: | A registration MUST include the following fields: | |||
o Cache Directive Name | o Cache Directive Name | |||
o Pointer to specification text | o Pointer to specification text | |||
Values to be added to this name space are subject to IETF review | 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-cache-directives>. | <http://www.iana.org/assignments/http-cache-directives>. | |||
3.3. Expires | 3.3. Expires | |||
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 2.3 for further discussion | response is considered stale. See Section 2.3 for further discussion | |||
of the freshness model. | of the freshness model. | |||
skipping to change at page 29, line 4 | skipping to change at page 29, line 29 | |||
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. | |||
3.5. Vary | 3.5. Vary | |||
The "Vary" header field conveys the set of header fields that were | The "Vary" header field conveys the set of header fields that were | |||
used to select the representation. | used to select the representation. | |||
Caches use this information, in part, to determine whether a stored | Caches use this information, in part, to determine whether a stored | |||
response can be used to satisfy a given request; see Section 2.7. | response can be used to satisfy a given request; see Section 2.8. | |||
determines, while the response is fresh, whether a cache is permitted | determines, while the response is fresh, whether a cache is permitted | |||
to use the response to reply to a subsequent request without | to use the response to reply to a subsequent request without | |||
validation; see Section 2.7. | validation; see Section 2.8. | |||
In uncacheable or stale responses, the Vary field value advises the | In uncacheable or stale responses, the Vary field value advises the | |||
user agent about the criteria that were used to select the | user agent about the criteria that were used to select the | |||
representation. | representation. | |||
Vary = "*" / 1#field-name | Vary = "*" / 1#field-name | |||
The set of header fields named by the Vary field value is known as | The set of header fields named by the Vary field value is known as | |||
the selecting header fields. | the selecting header fields. | |||
skipping to change at page 32, line 17 | skipping to change at page 32, line 43 | |||
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 are subject to IETF review | 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>. | |||
3.7. History Lists | 4. History Lists | |||
User agents often have history mechanisms, such as "Back" buttons and | User agents often have history mechanisms, such as "Back" buttons and | |||
history lists, that can be used to redisplay 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). | |||
3.8. IANA Considerations | 5. IANA Considerations | |||
3.8.1. Cache Directive Registry | 5.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 24 | skipping to change at page 33, line 44 | |||
| 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 | | |||
+------------------------+------------------------------+ | +------------------------+------------------------------+ | |||
3.8.2. Warn Code Registry | 5.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 3.6.8 of this document. | Section 3.6.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 3.6.1 | | | 110 | Response is Stale | Section 3.6.1 | | |||
| 111 | Revalidation Failed | Section 3.6.2 | | | 111 | Revalidation Failed | Section 3.6.2 | | |||
| 112 | Disconnected Operation | Section 3.6.3 | | | 112 | Disconnected Operation | Section 3.6.3 | | |||
| 113 | Heuristic Expiration | Section 3.6.4 | | | 113 | Heuristic Expiration | Section 3.6.4 | | |||
| 199 | Miscellaneous Warning | Section 3.6.5 | | | 199 | Miscellaneous Warning | Section 3.6.5 | | |||
| 214 | Transformation Applied | Section 3.6.6 | | | 214 | Transformation Applied | Section 3.6.6 | | |||
| 299 | Miscellaneous Persistent Warning | Section 3.6.7 | | | 299 | Miscellaneous Persistent Warning | Section 3.6.7 | | |||
+-----------+----------------------------------+---------------+ | +-----------+----------------------------------+---------------+ | |||
3.9. Header Field Registration | 5.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 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". | |||
4. Security Considerations | 6. 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. | |||
5. Acknowledgments | 7. Acknowledgments | |||
See Section 11 of [Part1]. | ||||
6. References | See Section 9 of [Part1]. | |||
6.1. Normative References | 8. References | |||
8.1. Normative References | ||||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | "HTTP/1.1, part 1: URIs, Connections, and Message | |||
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | Parsing", draft-ietf-httpbis-p1-messaging-19 (work in | |||
and Message Parsing", draft-ietf-httpbis-p1-messaging-18 | progress), March 2012. | |||
(work in progress), January 2012. | ||||
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | "HTTP/1.1, part 2: Message Semantics", | |||
and J. Reschke, Ed., "HTTP/1.1, part 2: Message | draft-ietf-httpbis-p2-semantics-19 (work in progress), | |||
Semantics", draft-ietf-httpbis-p2-semantics-18 (work in | March 2012. | |||
progress), January 2012. | ||||
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | "HTTP/1.1, part 4: Conditional Requests", | |||
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional | draft-ietf-httpbis-p4-conditional-19 (work in progress), | |||
Requests", draft-ietf-httpbis-p4-conditional-18 (work in | March 2012. | |||
progress), January 2012. | ||||
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | "HTTP/1.1, part 5: Range Requests and Partial Responses", | |||
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | draft-ietf-httpbis-p5-range-19 (work in progress), | |||
Partial Responses", draft-ietf-httpbis-p5-range-18 (work | March 2012. | |||
in progress), January 2012. | ||||
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | "HTTP/1.1, part 7: Authentication", | |||
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", | draft-ietf-httpbis-p7-auth-19 (work in progress), | |||
draft-ietf-httpbis-p7-auth-18 (work in progress), | March 2012. | |||
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. | |||
6.2. Informative References | 8.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 36, line 4 | skipping to change at page 36, line 17 | |||
Content", RFC 5861, April 2010. | Content", RFC 5861, April 2010. | |||
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 2.3.2) | (Section 2.3.2) | |||
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 2.4) | (Section 2.4) | |||
Clarify denial of service attack avoidance requirement. | Clarify denial of service attack avoidance requirement. | |||
(Section 2.5) | (Section 2.6) | |||
Change ABNF productions for header fields to only define the field | Change ABNF productions for header fields to only define the field | |||
value. (Section 3) | value. (Section 3) | |||
Do not mention RFC 2047 encoding and multiple languages in Warning | 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 3.6) | (Section 3.6) | |||
Appendix B. Collected ABNF | Appendix B. 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 8> | HTTP-date = <HTTP-date, defined in [Part2], Section 8> | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | 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 ] | Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] | |||
) ) | ) ) | |||
Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] | Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ] | |||
) | ) | |||
skipping to change at page 37, line 4 | skipping to change at page 37, line 18 | |||
cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( "," | cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( "," | |||
OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( | OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( | |||
"no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS | "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS | |||
field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / | field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / | |||
"must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds | "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds | |||
) / ( "s-maxage=" delta-seconds ) / cache-extension | ) / ( "s-maxage=" delta-seconds ) / cache-extension | |||
delta-seconds = 1*DIGIT | delta-seconds = 1*DIGIT | |||
extension-pragma = token [ "=" ( token / quoted-string ) ] | extension-pragma = token [ "=" ( token / quoted-string ) ] | |||
field-name = <field-name, defined in [Part1], Section 3.2> | field-name = <field-name, defined in [Part1], Section 3.2> | |||
port = <port, defined in [Part1], Section 2.7> | 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 8.8> | pseudonym = <pseudonym, defined in [Part1], Section 6.2> | |||
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> | quoted-string = <quoted-string, defined in [Part1], Section 3.2.4> | |||
token = <token, defined in [Part1], Section 3.2.3> | token = <token, defined in [Part1], Section 3.2.4> | |||
uri-host = <uri-host, defined in [Part1], Section 2.7> | 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 | |||
] | ] | |||
skipping to change at page 43, line 28 | skipping to change at page 43, line 40 | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/293>: "Interaction | o <http://tools.ietf.org/wg/httpbis/trac/ticket/293>: "Interaction | |||
of request and response Cache-Control" | of request and response Cache-Control" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/212>: "Refining age | o <http://tools.ietf.org/wg/httpbis/trac/ticket/212>: "Refining age | |||
for 1.1 proxy chains" | for 1.1 proxy chains" | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/274>: "warn-code | o <http://tools.ietf.org/wg/httpbis/trac/ticket/274>: "warn-code | |||
registry" | registry" | |||
C.20. Since draft-ietf-httpbis-p6-cache-18 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/227>: "Combining | ||||
HEAD responses" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/337>: "Field names | ||||
in cache-control header arguments" | ||||
Index | Index | |||
1 | 1 | |||
110 Response is Stale (warn code) 31 | 110 Response is Stale (warn code) 31 | |||
111 Revalidation Failed (warn code) 31 | 111 Revalidation Failed (warn code) 31 | |||
112 Disconnected Operation (warn code) 31 | 112 Disconnected Operation (warn code) 31 | |||
113 Heuristic Expiration (warn code) 31 | 113 Heuristic Expiration (warn code) 32 | |||
199 Miscellaneous Warning (warn code) 31 | 199 Miscellaneous Warning (warn code) 32 | |||
2 | 2 | |||
214 Transformation Applied (warn code) 31 | 214 Transformation Applied (warn code) 32 | |||
299 Miscellaneous Persistent Warning (warn code) 31 | 299 Miscellaneous Persistent Warning (warn code) 32 | |||
A | A | |||
age 6 | age 6 | |||
Age header field 20 | Age header field 21 | |||
C | C | |||
cache 5 | cache 5 | |||
Cache Directives | Cache Directives | |||
max-age 22, 25 | max-age 23, 26 | |||
max-stale 22 | max-stale 23 | |||
min-fresh 22 | min-fresh 23 | |||
must-revalidate 25 | must-revalidate 25 | |||
no-cache 22, 24 | no-cache 22, 24 | |||
no-store 22, 24 | no-store 22, 25 | |||
no-transform 23, 25 | no-transform 23, 26 | |||
only-if-cached 23 | only-if-cached 23 | |||
private 23 | private 24 | |||
proxy-revalidate 25 | proxy-revalidate 26 | |||
public 23 | public 24 | |||
s-maxage 25 | s-maxage 26 | |||
cache entry 8 | cache entry 8 | |||
cache key 8 | cache key 8 | |||
Cache-Control header field 21 | Cache-Control header field 21 | |||
cacheable 5 | cacheable 5 | |||
E | E | |||
Expires header field 27 | Expires header field 27 | |||
explicit expiration time 6 | explicit expiration time 6 | |||
F | F | |||
first-hand 6 | first-hand 6 | |||
fresh 6 | fresh 6 | |||
freshness lifetime 6 | freshness lifetime 6 | |||
G | G | |||
Grammar | Grammar | |||
Age 20 | Age 21 | |||
Cache-Control 21 | Cache-Control 22 | |||
cache-extension 21 | cache-extension 22 | |||
cache-request-directive 21 | cache-request-directive 22 | |||
cache-response-directive 23 | cache-response-directive 24 | |||
delta-seconds 8 | delta-seconds 8 | |||
Expires 27 | Expires 28 | |||
extension-pragma 28 | extension-pragma 28 | |||
Pragma 28 | Pragma 28 | |||
pragma-directive 28 | pragma-directive 28 | |||
Vary 29 | Vary 29 | |||
warn-agent 30 | warn-agent 30 | |||
warn-code 30 | warn-code 30 | |||
warn-date 30 | warn-date 30 | |||
warn-text 30 | warn-text 30 | |||
Warning 30 | Warning 30 | |||
warning-value 30 | warning-value 30 | |||
H | H | |||
Header Fields | Header Fields | |||
Age 20 | Age 21 | |||
Cache-Control 21 | Cache-Control 21 | |||
Expires 27 | Expires 27 | |||
Pragma 28 | Pragma 28 | |||
Vary 28 | Vary 29 | |||
Warning 29 | Warning 30 | |||
heuristic expiration time 6 | heuristic expiration time 6 | |||
M | M | |||
max-age | max-age | |||
Cache Directive 22, 25 | Cache Directive 23, 26 | |||
max-stale | max-stale | |||
Cache Directive 22 | Cache Directive 23 | |||
min-fresh | min-fresh | |||
Cache Directive 22 | Cache Directive 23 | |||
must-revalidate | must-revalidate | |||
Cache Directive 25 | Cache Directive 25 | |||
N | N | |||
no-cache | no-cache | |||
Cache Directive 22, 24 | Cache Directive 22, 24 | |||
no-store | no-store | |||
Cache Directive 22, 24 | Cache Directive 22, 25 | |||
no-transform | no-transform | |||
Cache Directive 23, 25 | Cache Directive 23, 26 | |||
O | O | |||
only-if-cached | only-if-cached | |||
Cache Directive 23 | Cache Directive 23 | |||
P | P | |||
Pragma header field 28 | Pragma header field 28 | |||
private | private | |||
Cache Directive 23 | Cache Directive 24 | |||
private cache 5 | private cache 5 | |||
proxy-revalidate | proxy-revalidate | |||
Cache Directive 25 | Cache Directive 26 | |||
public | public | |||
Cache Directive 23 | Cache Directive 24 | |||
S | S | |||
s-maxage | s-maxage | |||
Cache Directive 25 | Cache Directive 26 | |||
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 29 | |||
W | W | |||
Warn Codes | Warn Codes | |||
110 Response is Stale 31 | 110 Response is Stale 31 | |||
111 Revalidation Failed 31 | 111 Revalidation Failed 31 | |||
112 Disconnected Operation 31 | 112 Disconnected Operation 31 | |||
113 Heuristic Expiration 31 | 113 Heuristic Expiration 32 | |||
199 Miscellaneous Warning 31 | 199 Miscellaneous Warning 32 | |||
214 Transformation Applied 31 | 214 Transformation Applied 32 | |||
299 Miscellaneous Persistent Warning 31 | 299 Miscellaneous Persistent Warning 32 | |||
Warning header field 29 | 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/ | |||
Jim Gettys | ||||
Alcatel-Lucent Bell Labs | ||||
21 Oak Knoll Road | ||||
Carlisle, MA 01741 | ||||
USA | ||||
EMail: jg@freedesktop.org | ||||
URI: http://gettys.wordpress.com/ | ||||
Jeffrey C. Mogul | ||||
Hewlett-Packard Company | ||||
HP Labs, Large Scale Systems Group | ||||
1501 Page Mill Road, MS 1177 | ||||
Palo Alto, CA 94304 | ||||
USA | ||||
EMail: JeffMogul@acm.org | ||||
Henrik Frystyk Nielsen | ||||
Microsoft Corporation | ||||
1 Microsoft Way | ||||
Redmond, WA 98052 | ||||
USA | ||||
EMail: henrikn@microsoft.com | ||||
Larry Masinter | ||||
Adobe Systems Incorporated | ||||
345 Park Ave | ||||
San Jose, CA 95110 | ||||
USA | ||||
EMail: LMM@acm.org | ||||
URI: http://larry.masinter.net/ | ||||
Paul J. Leach | ||||
Microsoft Corporation | ||||
1 Microsoft Way | ||||
Redmond, WA 98052 | ||||
EMail: paulle@microsoft.com | ||||
Tim Berners-Lee | ||||
World Wide Web Consortium | ||||
MIT Computer Science and Artificial Intelligence Laboratory | ||||
The Stata Center, Building 32 | ||||
32 Vassar Street | ||||
Cambridge, MA 02139 | ||||
USA | ||||
EMail: timbl@w3.org | ||||
URI: http://www.w3.org/People/Berners-Lee/ | ||||
Yves Lafon (editor) | Yves Lafon (editor) | |||
World Wide Web Consortium | World Wide Web Consortium | |||
W3C / ERCIM | W3C / ERCIM | |||
2004, rte des Lucioles | 2004, rte des Lucioles | |||
Sophia-Antipolis, AM 06902 | Sophia-Antipolis, AM 06902 | |||
France | France | |||
EMail: ylafon@w3.org | EMail: ylafon@w3.org | |||
URI: http://www.raubacapeu.net/people/yves/ | URI: http://www.raubacapeu.net/people/yves/ | |||
End of changes. 92 change blocks. | ||||
230 lines changed or deleted | 204 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/ |