draft-ietf-httpbis-p6-cache-07.txt | draft-ietf-httpbis-p6-cache-08.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Day Software | Internet-Draft Day Software | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Intended status: Standards Track One Laptop per Child | Intended status: Standards Track One Laptop per Child | |||
Expires: January 14, 2010 J. Mogul | Expires: April 29, 2010 J. Mogul | |||
HP | HP | |||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe Systems | Adobe Systems | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
Y. Lafon, Ed. | Y. Lafon, Ed. | |||
W3C | W3C | |||
M. Nottingham, Ed. | M. Nottingham, Ed. | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
July 13, 2009 | October 26, 2009 | |||
HTTP/1.1, part 6: Caching | HTTP/1.1, part 6: Caching | |||
draft-ietf-httpbis-p6-cache-07 | draft-ietf-httpbis-p6-cache-08 | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted to IETF in full conformance with the | This Internet-Draft is submitted to IETF in full conformance with the | |||
provisions of BCP 78 and BCP 79. This document may contain material | provisions of BCP 78 and BCP 79. This document may contain material | |||
from IETF Documents or IETF Contributions published or made publicly | from IETF Documents or IETF Contributions published or made publicly | |||
available before November 10, 2008. The person(s) controlling the | available before November 10, 2008. The person(s) controlling the | |||
copyright in some of this material may not have granted the IETF | copyright in some of this material may not have granted the IETF | |||
Trust the right to allow modifications of such material outside the | Trust the right to allow modifications of such material outside the | |||
IETF Standards Process. Without obtaining an adequate license from | IETF Standards Process. Without obtaining an adequate license from | |||
skipping to change at page 2, line 13 | skipping to change at page 2, line 13 | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
This Internet-Draft will expire on January 14, 2010. | This Internet-Draft will expire on April 29, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2009 IETF Trust and the persons identified as the | Copyright (c) 2009 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents in effect on the date of | Provisions Relating to IETF Documents in effect on the date of | |||
publication of this document (http://trustee.ietf.org/license-info). | publication of this document (http://trustee.ietf.org/license-info). | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 2, line 44 | skipping to change at page 2, line 44 | |||
or indicate cacheable response messages. | or indicate cacheable response messages. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org). The current issues list is | group mailing list (ietf-http-wg@w3.org). The current issues list is | |||
at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related | at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related | |||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix C.8. | The changes in this draft are summarized in Appendix C.9. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 | 1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7 | |||
1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 | 1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7 | |||
1.4.2. ABNF Rules defined in other Parts of the | 1.4.2. ABNF Rules defined in other Parts of the | |||
skipping to change at page 3, line 27 | skipping to change at page 3, line 27 | |||
2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 | 2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8 | |||
2.2. Constructing Responses from Caches . . . . . . . . . . . . 8 | 2.2. Constructing Responses from Caches . . . . . . . . . . . . 8 | |||
2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9 | 2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9 | |||
2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10 | 2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10 | |||
2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11 | 2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11 | |||
2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 | 2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13 | |||
2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13 | 2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13 | |||
2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 | 2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14 | |||
2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 | 2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15 | |||
2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 | 2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16 | |||
3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17 | 3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16 | |||
3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17 | 3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17 | |||
3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 | 3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18 | |||
3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 | 3.2.2. Response Cache-Control Directives . . . . . . . . . . 20 | |||
3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22 | 3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22 | |||
3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 | 4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 | |||
5.1. Message Header Registration . . . . . . . . . . . . . . . 28 | 5.1. Message Header Registration . . . . . . . . . . . . . . . 28 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . . 30 | 8.2. Informative References . . . . . . . . . . . . . . . . . . 30 | |||
Appendix A. Compatibility with Previous Versions . . . . . . . . 31 | Appendix A. Compatibility with Previous Versions . . . . . . . . 30 | |||
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31 | A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 31 | |||
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31 | A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31 | |||
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31 | |||
Appendix C. Change Log (to be removed by RFC Editor before | Appendix C. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 33 | publication) . . . . . . . . . . . . . . . . . . . . 33 | |||
C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 | C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33 | |||
C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33 | C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33 | |||
C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 | C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34 | |||
C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34 | C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34 | |||
C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 | C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34 | |||
C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 | C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35 | |||
C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 | C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35 | |||
C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 | C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35 | |||
C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
1. Introduction | 1. Introduction | |||
HTTP is typically used for distributed information systems, where | HTTP is typically used for distributed information systems, where | |||
performance can be improved by the use of response caches. This | performance can be improved by the use of response caches. This | |||
document defines aspects of HTTP/1.1 related to caching and reusing | document defines aspects of HTTP/1.1 related to caching and reusing | |||
response messages. | response messages. | |||
skipping to change at page 7, line 38 | skipping to change at page 7, line 38 | |||
The core rules below are defined in Section 1.2.2 of [Part1]: | The core rules below are defined in Section 1.2.2 of [Part1]: | |||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | |||
token = <token, defined in [Part1], Section 1.2.2> | token = <token, defined in [Part1], Section 1.2.2> | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 1.2.2> | |||
1.4.2. ABNF Rules defined in other Parts of the Specification | 1.4.2. ABNF Rules defined in other Parts of the Specification | |||
The ABNF rules below are defined in other parts: | The ABNF rules below are defined in other parts: | |||
field-name = <field-name, defined in [Part1], Section 4.2> | field-name = <field-name, defined in [Part1], Section 3.2> | |||
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | |||
port = <port, defined in [Part1], Section 2.1> | port = <port, defined in [Part1], Section 2.6> | |||
pseudonym = <pseudonym, defined in [Part1], Section 8.9> | pseudonym = <pseudonym, defined in [Part1], Section 9.9> | |||
uri-host = <uri-host, defined in [Part1], Section 2.1> | uri-host = <uri-host, defined in [Part1], Section 2.6> | |||
2. Cache Operation | 2. Cache Operation | |||
2.1. Response Cacheability | 2.1. Response Cacheability | |||
A cache MUST NOT store a response to any request, unless: | A cache MUST NOT store a response to any request, unless: | |||
o The request method is defined as being cacheable, and | o The request method is defined as being cacheable, and | |||
o the "no-store" cache directive (see Section 3.2) does not appear | o the "no-store" cache directive (see Section 3.2) does not appear | |||
skipping to change at page 8, line 47 | skipping to change at page 8, line 47 | |||
MUST NOT store incomplete or partial responses. | MUST NOT store incomplete or partial responses. | |||
2.2. Constructing Responses from Caches | 2.2. Constructing Responses from Caches | |||
For a presented request, a cache MUST NOT return a stored response, | For a presented request, a cache MUST NOT return a stored response, | |||
unless: | unless: | |||
o The presented Request-URI and that of the stored response match | o The presented Request-URI and that of the stored response match | |||
([[TODO-Request-URI: Need to find a new term for this, as Part 1 | ([[TODO-Request-URI: Need to find a new term for this, as Part 1 | |||
doesn't define Request-URI anymore; the new term request-target | doesn't define Request-URI anymore; the new term request-target | |||
does not work for this.]]), and | does not work for this. (see | |||
<http://tools.ietf.org/wg/httpbis/trac/ticket/196>)]]), and | ||||
o the request method associated with the stored response allows it | o the request method associated with the stored response allows it | |||
to be used for the presented request, and | to be used for the presented request, and | |||
o selecting request-headers nominated by the stored response (if | o selecting request-headers nominated by the stored response (if | |||
any) match those presented (see Section 2.6), and | any) match those presented (see Section 2.6), and | |||
o the presented request and stored response are free from directives | o the presented request and stored response are free from directives | |||
that would prevent its use (see Section 3.2 and Section 3.4), and | that would prevent its use (see Section 3.2 and Section 3.4), and | |||
skipping to change at page 11, line 52 | skipping to change at page 11, line 52 | |||
generated or validated by the origin server. In essence, the Age | generated or validated by the origin server. In essence, the Age | |||
value is the sum of the time that the response has been resident in | value is the sum of the time that the response has been resident in | |||
each of the caches along the path from the origin server, plus the | each of the caches along the path from the origin server, plus the | |||
amount of time it has been in transit along network paths. | amount of time it has been in transit along network paths. | |||
The term "age_value" denotes the value of the Age header, in a form | The term "age_value" denotes the value of the Age header, in a form | |||
appropriate for arithmetic operations. | appropriate for arithmetic operations. | |||
HTTP/1.1 requires origin servers to send a Date header, if possible, | HTTP/1.1 requires origin servers to send a Date header, if possible, | |||
with every response, giving the time at which the response was | with every response, giving the time at which the response was | |||
generated (see Section 8.3 of [Part1]). The term "date_value" | generated (see Section 9.3 of [Part1]). The term "date_value" | |||
denotes the value of the Date header, in a form appropriate for | denotes the value of the Date header, in a form appropriate for | |||
arithmetic operations. | arithmetic operations. | |||
The term "now" means "the current value of the clock at the host | The term "now" means "the current value of the clock at the host | |||
performing the calculation." Hosts that use HTTP, but especially | performing the calculation." Hosts that use HTTP, but especially | |||
hosts running origin servers and caches, SHOULD use NTP [RFC1305] or | hosts running origin servers and caches, SHOULD use NTP [RFC1305] or | |||
some similar protocol to synchronize their clocks to a globally | some similar protocol to synchronize their clocks to a globally | |||
accurate time standard. | accurate time standard. | |||
A response's age can be calculated in two entirely independent ways: | A response's age can be calculated in two entirely independent ways: | |||
skipping to change at page 14, line 34 | skipping to change at page 14, line 34 | |||
of the stored responses nominated in the conditional request is | of the stored responses nominated in the conditional request is | |||
suitable. Instead, the full response is used both to satisfy the | suitable. Instead, the full response is used both to satisfy the | |||
request and replace the stored response. [[anchor5: Should there be a | request and replace the stored response. [[anchor5: Should there be a | |||
requirement here?]] | requirement here?]] | |||
If a cache receives a 5xx response while attempting to validate a | If a cache receives a 5xx response while attempting to validate a | |||
response, it MAY either forward this response to the requesting | response, it MAY either forward this response to the requesting | |||
client, or act as if the server failed to respond. In the latter | client, or act as if the server failed to respond. In the latter | |||
case, it MAY return a previously stored response (see Section 2.3.3). | case, it MAY return a previously stored response (see Section 2.3.3). | |||
If a cache receives a successful response whose Content-Location | ||||
field matches that of an existing stored response for the same | ||||
Request-URI, whose entity-tag differs from that of the existing | ||||
stored response, and whose Date is more recent than that of the | ||||
existing response, the existing response SHOULD NOT be returned in | ||||
response to future requests and SHOULD be deleted from the cache. | ||||
[[anchor6: DISCUSS: Not sure if this is necessary.]] | ||||
2.5. Request Methods that Invalidate | 2.5. Request Methods that Invalidate | |||
Because unsafe methods (Section 7.1.1 of [Part2]) have the potential | Because unsafe methods (Section 7.1.1 of [Part2]) have the potential | |||
for changing state on the origin server, intervening caches can use | for changing state on the origin server, intervening caches can use | |||
them to keep their contents up-to-date. | them to keep their contents up-to-date. | |||
The following HTTP methods MUST cause a cache to invalidate the | The following HTTP methods MUST cause a cache to invalidate the | |||
Request-URI as well as the URI(s) in the Location and Content- | Request-URI as well as the URI(s) in the Location and Content- | |||
Location headers (if present): | Location headers (if present): | |||
skipping to change at page 15, line 16 | skipping to change at page 15, line 7 | |||
o DELETE | o DELETE | |||
o POST | o POST | |||
An invalidation based on a URI from a Location or Content-Location | An invalidation based on a URI from a Location or Content-Location | |||
header MUST NOT be performed if the host part of that URI differs | header MUST NOT be performed if the host part of that URI differs | |||
from the host part in the Request-URI. This helps prevent denial of | from the host part in the Request-URI. This helps prevent denial of | |||
service attacks. | service attacks. | |||
[[anchor7: TODO: "host part" needs to be specified better.]] | [[anchor6: TODO: "host part" needs to be specified better.]] | |||
A cache that passes through requests for methods it does not | A cache that passes through requests for methods it does not | |||
understand SHOULD invalidate the Request-URI. | understand SHOULD invalidate the Request-URI. | |||
Here, "invalidate" means that the cache will either remove all stored | Here, "invalidate" means that the cache will either remove all stored | |||
responses related to the Request-URI, or will mark these as "invalid" | responses related to the Request-URI, or will mark these as "invalid" | |||
and in need of a mandatory validation before they can be returned in | and in need of a mandatory validation before they can be returned in | |||
response to a subsequent request. | response to a subsequent request. | |||
Note that this does not guarantee that all appropriate responses are | Note that this does not guarantee that all appropriate responses are | |||
invalidated. For example, the request that caused the change at the | invalidated. For example, the request that caused the change at the | |||
origin server might not have gone through the cache where a response | origin server might not have gone through the cache where a response | |||
is stored. | is stored. | |||
[[anchor8: TODO: specify that only successful (2xx, 3xx?) responses | [[anchor7: TODO: specify that only successful (2xx, 3xx?) responses | |||
invalidate.]] | invalidate.]] | |||
2.6. Caching Negotiated Responses | 2.6. Caching Negotiated Responses | |||
When a cache receives a request that can be satisfied by a stored | When a cache receives a request that can be satisfied by a stored | |||
response that has a Vary header field (Section 3.5), it MUST NOT use | response that has a Vary header field (Section 3.5), it MUST NOT use | |||
that response unless all of the selecting request-headers nominated | that response unless all of the selecting request-headers nominated | |||
by the Vary header match in both the original request (i.e., that | by the Vary header match in both the original request (i.e., that | |||
associated with the stored response), and the presented request. | associated with the stored response), and the presented request. | |||
The selecting request-headers from two requests are defined to match | The selecting request-headers from two requests are defined to match | |||
if and only if the selecting request-headers in the first request can | if and only if the selecting request-headers in the first request can | |||
be transformed to the selecting request-headers in the second request | be transformed to the selecting request-headers in the second request | |||
by adding or removing linear white space [[anchor9: [ref]]] at places | by adding or removing linear white space [[anchor8: [ref]]] at places | |||
where this is allowed by the corresponding ABNF, and/or combining | where this is allowed by the corresponding ABNF, and/or combining | |||
multiple message-header fields with the same field name following the | multiple message-header fields with the same field name following the | |||
rules about message headers in Section 4.2 of [Part1]. | rules about header fields in Section 3.2 of [Part1]. | |||
If a header field is absent from a request, it can only match another | If a header field is absent from a request, it can only match another | |||
request if it is also absent there. | request if it is also absent there. | |||
A Vary header field-value of "*" always fails to match, and | A Vary header field-value of "*" always fails to match, and | |||
subsequent requests to that resource can only be properly interpreted | subsequent requests to that resource can only be properly interpreted | |||
by the origin server. | by the origin server. | |||
The stored response with matching selecting request-headers is known | The stored response with matching selecting request-headers is known | |||
as the selected response. | as the selected response. | |||
skipping to change at page 16, line 25 | skipping to change at page 16, line 16 | |||
2.7. Combining Responses | 2.7. Combining Responses | |||
When a cache receives a 304 (Not Modified) response or a 206 (Partial | When a cache receives a 304 (Not Modified) response or a 206 (Partial | |||
Content) response (in this section, the "new" response"), it needs to | Content) response (in this section, the "new" response"), it needs to | |||
created an updated response by combining the stored response with the | created an updated response by combining the stored response with the | |||
new one, so that the updated response can be used to satisfy the | new one, so that the updated response can be used to satisfy the | |||
request. | request. | |||
If the new response contains an ETag, it identifies the stored | If the new response contains an ETag, it identifies the stored | |||
response to use. [[anchor10: may need language about Content-Location | response to use. [[anchor9: may need language about Content-Location | |||
here]][[anchor11: cover case where INM with multiple etags was sent]] | here]][[anchor10: cover case where INM with multiple etags was sent]] | |||
If the status code is 206 (partial content), both the stored and new | If the status code is 206 (partial content), both the stored and new | |||
responses MUST have ETags, and those ETags MUST match using the | responses MUST have validators, and those validators MUST match using | |||
strong comparison function (see Section 4 of [Part4]). Otherwise, | the strong comparison function (see Section 4 of [Part4]). | |||
the responses MUST NOT be combined. | Otherwise, the responses MUST NOT be combined. | |||
The stored response headers are used as those of the updated | The stored response headers are used as those of the updated | |||
response, except that | response, except that | |||
o any stored Warning headers with warn-code 1xx (see Section 3.6) | o any stored Warning headers with warn-code 1xx (see Section 3.6) | |||
MUST be deleted from the stored response and the updated response. | MUST be deleted from the stored response and the updated response. | |||
o any stored Warning headers with warn-code 2xx MUST be retained in | o any stored Warning headers with warn-code 2xx MUST be retained in | |||
the stored response and the updated response. | the stored response and the updated response. | |||
o any headers provided in the new response MUST replace the | o any headers provided in the new response MUST replace the | |||
corresponding headers from the stored response. | corresponding headers from the stored response. | |||
If a header field-name in the new response matches more than one | If a header field-name in the new response matches more than one | |||
header in the stored response, all such stored headers MUST be | header in the stored response, all such stored headers MUST be | |||
replaced. | replaced. | |||
The updated response can [[[[anchor12: requirement?]]]] be used to | The updated response can [[[[anchor11: requirement?]]]] be used to | |||
replace the stored response in cache. In the case of a 206 response, | replace the stored response in cache. In the case of a 206 response, | |||
the combined entity-body MAY be stored. | the combined entity-body MAY be stored. | |||
[[anchor13: ISSUE: discuss how to handle HEAD updates]] | [[anchor12: ISSUE: discuss how to handle HEAD updates]] | |||
3. Header Field Definitions | 3. Header Field Definitions | |||
This section defines the syntax and semantics of HTTP/1.1 header | This section defines the syntax and semantics of HTTP/1.1 header | |||
fields related to caching. | fields related to caching. | |||
For entity-header fields, both sender and recipient refer to either | For entity-header fields, both sender and recipient refer to either | |||
the client or the server, depending on who sends and who receives the | the client or the server, depending on who sends and who receives the | |||
entity. | entity. | |||
3.1. Age | 3.1. Age | |||
The response-header field "Age" conveys the sender's estimate of the | The "Age" response-header field conveys the sender's estimate of the | |||
amount of time since the response (or its validation) was generated | amount of time since the response was generated or successfully | |||
at the origin server. Age values are calculated as specified in | validated at the origin server. Age values are calculated as | |||
Section 2.3.2. | specified in Section 2.3.2. | |||
Age = "Age" ":" OWS Age-v | Age = "Age" ":" OWS Age-v | |||
Age-v = delta-seconds | Age-v = delta-seconds | |||
Age field-values are non-negative integers, representing time in | Age field-values are non-negative integers, representing time in | |||
seconds. | seconds. | |||
delta-seconds = 1*DIGIT | delta-seconds = 1*DIGIT | |||
If a cache receives a value larger than the largest positive integer | If a cache receives a value larger than the largest positive integer | |||
it can represent, or if any of its age calculations overflows, it | it can represent, or if any of its age calculations overflows, it | |||
MUST transmit an Age header with a field-value of 2147483648 (2^31). | MUST transmit an Age header with a field-value of 2147483648 (2^31). | |||
Caches SHOULD use an arithmetic type of at least 31 bits of range. | Caches SHOULD use an arithmetic type of at least 31 bits of range. | |||
The presence of an Age header field in a response implies that a | The presence of an Age header field in a response implies that a | |||
response is not first-hand. However, the converse is not true, since | response is not first-hand. However, the converse is not true, since | |||
HTTP/1.0 caches may not implement the Age header field. | HTTP/1.0 caches may not implement the Age header field. | |||
3.2. Cache-Control | 3.2. Cache-Control | |||
The general-header field "Cache-Control" is used to specify | The "Cache-Control" general-header field is used to specify | |||
directives that MUST be obeyed by all caches along the request/ | directives that MUST be obeyed by all caches along the request/ | |||
response chain. The directives specify behavior intended to prevent | response chain. Such cache directives are unidirectional in that the | |||
caches from adversely interfering with the request or response. | presence of a directive in a request does not imply that the same | |||
Cache directives are unidirectional in that the presence of a | directive is to be given in the response. | |||
directive in a request does not imply that the same directive is to | ||||
be given in the response. | ||||
Note that HTTP/1.0 caches might not implement Cache-Control and | Note that HTTP/1.0 caches might not implement Cache-Control and | |||
might only implement Pragma: no-cache (see Section 3.4). | might only implement Pragma: no-cache (see Section 3.4). | |||
Cache directives MUST be passed through by a proxy or gateway | Cache directives MUST be passed through by a proxy or gateway | |||
application, regardless of their significance to that application, | application, regardless of their significance to that application, | |||
since the directives might be applicable to all recipients along the | since the directives might be applicable to all recipients along the | |||
request/response chain. It is not possible to target a directive to | request/response chain. It is not possible to target a directive to | |||
a specific cache. | a specific cache. | |||
skipping to change at page 19, line 21 | skipping to change at page 19, line 13 | |||
client is not willing to accept a stale response. | client is not willing to accept a stale response. | |||
max-stale | max-stale | |||
The max-stale request directive indicates that the client is | The max-stale request directive indicates that the client is | |||
willing to accept a response that has exceeded its expiration | willing to accept a response that has exceeded its expiration | |||
time. If max-stale is assigned a value, then the client is | time. If max-stale is assigned a value, then the client is | |||
willing to accept a response that has exceeded its expiration time | willing to accept a response that has exceeded its expiration time | |||
by no more than the specified number of seconds. If no value is | by no more than the specified number of seconds. If no value is | |||
assigned to max-stale, then the client is willing to accept a | assigned to max-stale, then the client is willing to accept a | |||
stale response of any age. [[anchor14: of any staleness? --mnot]] | stale response of any age. [[anchor13: of any staleness? --mnot]] | |||
min-fresh | min-fresh | |||
The min-fresh request directive indicates that the client is | The min-fresh request directive indicates that the client is | |||
willing to accept a response whose freshness lifetime is no less | willing to accept a response whose freshness lifetime is no less | |||
than its current age plus the specified time in seconds. That is, | than its current age plus the specified time in seconds. That is, | |||
the client wants a response that will still be fresh for at least | the client wants a response that will still be fresh for at least | |||
the specified number of seconds. | the specified number of seconds. | |||
no-transform | no-transform | |||
skipping to change at page 20, line 40 | skipping to change at page 20, line 40 | |||
cache. A private (non-shared) cache MAY store the response. | cache. A private (non-shared) cache MAY store the response. | |||
If the private response directive specifies one or more field- | If the private response directive specifies one or more field- | |||
names, this requirement is limited to the field-values associated | names, this requirement is limited to the field-values associated | |||
with the listed response headers. That is, the specified field- | with the listed response headers. That is, the specified field- | |||
names(s) MUST NOT be stored by a shared cache, whereas the | names(s) MUST NOT be stored by a shared cache, whereas the | |||
remainder of the response message MAY be. | remainder of the response message MAY be. | |||
Note: This usage of the word private only controls where the | Note: This usage of the word private only controls where the | |||
response may be stored, and cannot ensure the privacy of the | response may be stored, and cannot ensure the privacy of the | |||
message content. | message content. Also, private response directives with field- | |||
names are often handled by implementations as if an unqualified | ||||
private directive was recieved; i.e., the special handling for the | ||||
qualified form is not widely implemented. | ||||
no-cache | no-cache | |||
The no-cache response directive indicates that the response MUST | The no-cache response directive indicates that the response MUST | |||
NOT be used to satisfy a subsequent request without successful | NOT be used to satisfy a subsequent request without successful | |||
validation on the origin server. This allows an origin server to | validation on the origin server. This allows an origin server to | |||
prevent caching even by caches that have been configured to return | prevent caching even by caches that have been configured to return | |||
stale responses. | stale responses. | |||
If the no-cache response directive specifies one or more field- | If the no-cache response directive specifies one or more field- | |||
names, this requirement is limited to the field-values associated | names, this requirement is limited to the field-values associated | |||
with the listed response headers. That is, the specified field- | with the listed response headers. That is, the specified field- | |||
name(s) MUST NOT be sent in the response to a subsequent request | name(s) MUST NOT be sent in the response to a subsequent request | |||
without successful validation on the origin server. This allows | without successful validation on the origin server. This allows | |||
an origin server to prevent the re-use of certain header fields in | an origin server to prevent the re-use of certain header fields in | |||
a response, while still allowing caching of the rest of the | a response, while still allowing caching of the rest of the | |||
response. | response. | |||
Note: Most HTTP/1.0 caches will not recognize or obey this | Note: Most HTTP/1.0 caches will not recognize or obey this | |||
directive. | directive. Also, no-cache response directives with field-names | |||
are often handled by implementations as if an unqualified no-cache | ||||
directive was recieved; i.e., the special handling for the | ||||
qualified form is not widely implemented. | ||||
no-store | no-store | |||
The no-store response directive indicates that a cache MUST NOT | The no-store response directive indicates that a cache MUST NOT | |||
store any part of either the immediate request or response. This | store any part of either the immediate request or response. This | |||
directive applies to both non-shared and shared caches. "MUST NOT | directive applies to both non-shared and shared caches. "MUST NOT | |||
store" in this context means that the cache MUST NOT intentionally | store" in this context means that the cache MUST NOT intentionally | |||
store the information in non-volatile storage, and MUST make a | store the information in non-volatile storage, and MUST make a | |||
best-effort attempt to remove the information from volatile | best-effort attempt to remove the information from volatile | |||
storage as promptly as possible after forwarding it. | storage as promptly as possible after forwarding it. | |||
skipping to change at page 23, line 18 | skipping to change at page 23, line 24 | |||
behavior. | behavior. | |||
Unrecognized cache directives MUST be ignored; it is assumed that any | Unrecognized cache directives MUST be ignored; it is assumed that any | |||
cache directive likely to be unrecognized by an HTTP/1.1 cache will | cache directive likely to be unrecognized by an HTTP/1.1 cache will | |||
be combined with standard directives (or the response's default | be combined with standard directives (or the response's default | |||
cacheability) such that the cache behavior will remain minimally | cacheability) such that the cache behavior will remain minimally | |||
correct even if the cache does not understand the extension(s). | correct even if the cache does not understand the extension(s). | |||
3.3. Expires | 3.3. Expires | |||
The entity-header field "Expires" gives the date/time after which the | The "Expires" entity-header field gives the date/time after which the | |||
response is considered stale. See Section 2.3 for further discussion | response is considered stale. See Section 2.3 for further discussion | |||
of the freshness model. | of the freshness model. | |||
The presence of an Expires field does not imply that the original | The presence of an Expires field does not imply that the original | |||
resource will change or cease to exist at, before, or after that | resource will change or cease to exist at, before, or after that | |||
time. | time. | |||
The field-value is an absolute date and time as defined by HTTP-date | The field-value is an absolute date and time as defined by HTTP-date | |||
in Section 3.2 of [Part1]; it MUST be sent in rfc1123-date format. | in Section 6.1 of [Part1]; it MUST be sent in rfc1123-date format. | |||
Expires = "Expires" ":" OWS Expires-v | Expires = "Expires" ":" OWS Expires-v | |||
Expires-v = HTTP-date | Expires-v = HTTP-date | |||
For example | For example | |||
Expires: Thu, 01 Dec 1994 16:00:00 GMT | Expires: Thu, 01 Dec 1994 16:00:00 GMT | |||
Note: if a response includes a Cache-Control field with the max- | Note: if a response includes a Cache-Control field with the max- | |||
age directive (see Section 3.2.2), that directive overrides the | age directive (see Section 3.2.2), that directive overrides the | |||
skipping to change at page 23, line 50 | skipping to change at page 24, line 8 | |||
HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in | HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in | |||
the future. | the future. | |||
HTTP/1.1 clients and caches MUST treat other invalid date formats, | HTTP/1.1 clients and caches MUST treat other invalid date formats, | |||
especially including the value "0", as in the past (i.e., "already | especially including the value "0", as in the past (i.e., "already | |||
expired"). | expired"). | |||
3.4. Pragma | 3.4. Pragma | |||
The general-header field "Pragma" is used to include implementation- | The "Pragma" general-header field is used to include implementation- | |||
specific directives that might apply to any recipient along the | specific directives that might apply to any recipient along the | |||
request/response chain. All pragma directives specify optional | request/response chain. All pragma directives specify optional | |||
behavior from the viewpoint of the protocol; however, some systems | behavior from the viewpoint of the protocol; however, some systems | |||
MAY require that behavior be consistent with the directives. | MAY require that behavior be consistent with the directives. | |||
Pragma = "Pragma" ":" OWS Pragma-v | Pragma = "Pragma" ":" OWS Pragma-v | |||
Pragma-v = 1#pragma-directive | Pragma-v = 1#pragma-directive | |||
pragma-directive = "no-cache" / extension-pragma | pragma-directive = "no-cache" / extension-pragma | |||
extension-pragma = token [ "=" ( token / quoted-string ) ] | extension-pragma = token [ "=" ( token / quoted-string ) ] | |||
skipping to change at page 24, line 31 | skipping to change at page 24, line 38 | |||
Note: because the meaning of "Pragma: no-cache" as a response- | Note: because the meaning of "Pragma: no-cache" as a response- | |||
header field is not actually specified, it does not provide a | header field is not actually specified, it does not provide a | |||
reliable replacement for "Cache-Control: no-cache" in a response. | reliable replacement for "Cache-Control: no-cache" in a response. | |||
This mechanism is deprecated; no new Pragma directives will be | This mechanism is deprecated; no new Pragma directives will be | |||
defined in HTTP. | defined in HTTP. | |||
3.5. Vary | 3.5. Vary | |||
The "Vary" response-header field's value indicates the set of | The "Vary" response-header field conveys the set of request-header | |||
request-header fields that determines, while the response is fresh, | fields that were used to select the representation. | |||
whether a cache is permitted to use the response to reply to a | ||||
subsequent request without validation; see Section 2.6. | Caches use this information, in part, to determine whether a stored | |||
response can be used to satisdy a given request; see Section 2.6. | ||||
determines, while the response is fresh, whether a cache is permitted | ||||
to use the response to reply to a subsequent request without | ||||
validation; see Section 2.6. | ||||
In uncacheable or stale responses, the Vary field value advises the | In uncacheable or stale responses, the Vary field value advises the | |||
user agent about the criteria that were used to select the | user agent about the criteria that were used to select the | |||
representation. | representation. | |||
Vary = "Vary" ":" OWS Vary-v | Vary = "Vary" ":" OWS Vary-v | |||
Vary-v = "*" / 1#field-name | Vary-v = "*" / 1#field-name | |||
The set of header fields named by the Vary field value is known as | The set of header fields named by the Vary field value is known as | |||
the selecting request-headers. | the selecting request-headers. | |||
skipping to change at page 25, line 21 | skipping to change at page 25, line 32 | |||
therefore, a cache cannot determine whether this response is | therefore, a cache cannot determine whether this response is | |||
appropriate. The "*" value MUST NOT be generated by a proxy server; | appropriate. The "*" value MUST NOT be generated by a proxy server; | |||
it may only be generated by an origin server. | it may only be generated by an origin server. | |||
The field-names given are not limited to the set of standard request- | The field-names given are not limited to the set of standard request- | |||
header fields defined by this specification. Field names are case- | header fields defined by this specification. Field names are case- | |||
insensitive. | insensitive. | |||
3.6. Warning | 3.6. Warning | |||
The general-header field "Warning" is used to carry additional | The "Warning" general-header field is used to carry additional | |||
information about the status or transformation of a message that | information about the status or transformation of a message that | |||
might not be reflected in the message. This information is typically | might not be reflected in the message. This information is typically | |||
used to warn about possible incorrectness introduced by caching | used to warn about possible incorrectness introduced by caching | |||
operations or transformations applied to the entity body of the | operations or transformations applied to the entity body of the | |||
message. | message. | |||
Warnings can be used for other purposes, both cache-related and | Warnings can be used for other purposes, both cache-related and | |||
otherwise. The use of a warning, rather than an error status code, | otherwise. The use of a warning, rather than an error status code, | |||
distinguish these responses from true failures. | distinguish these responses from true failures. | |||
skipping to change at page 25, line 51 | skipping to change at page 26, line 20 | |||
warn-code = 3DIGIT | warn-code = 3DIGIT | |||
warn-agent = ( uri-host [ ":" port ] ) / pseudonym | warn-agent = ( uri-host [ ":" port ] ) / pseudonym | |||
; the name or pseudonym of the server adding | ; the name or pseudonym of the server adding | |||
; the Warning header, for use in debugging | ; the Warning header, for use in debugging | |||
warn-text = quoted-string | warn-text = quoted-string | |||
warn-date = DQUOTE HTTP-date DQUOTE | warn-date = DQUOTE HTTP-date DQUOTE | |||
Multiple warnings can be attached to a response (either by the origin | Multiple warnings can be attached to a response (either by the origin | |||
server or by a cache), including multiple warnings with the same code | server or by a cache), including multiple warnings with the same code | |||
number. For example, a server might provide the same warning with | number, only differing in warn-text. | |||
texts in both English and Basque. | ||||
When this occurs, the user agent SHOULD inform the user of as many of | When this occurs, the user agent SHOULD inform the user of as many of | |||
them as possible, in the order that they appear in the response. If | them as possible, in the order that they appear in the response. | |||
it is not possible to inform the user of all of the warnings, the | ||||
user agent SHOULD follow these heuristics: | ||||
o Warnings that appear early in the response take priority over | ||||
those appearing later in the response. | ||||
o Warnings in the user's preferred character set take priority over | ||||
warnings in other character sets but with identical warn-codes and | ||||
warn-agents. | ||||
Systems that generate multiple Warning headers SHOULD order them with | Systems that generate multiple Warning headers SHOULD order them with | |||
this user agent behavior in mind. New Warning headers SHOULD be | this user agent behavior in mind. New Warning headers SHOULD be | |||
added after any existing Warning headers. | added after any existing Warning headers. | |||
Warnings are assigned three digit warn-codes. The first digit | Warnings are assigned three digit warn-codes. The first digit | |||
indicates whether the Warning is required to be deleted from a stored | indicates whether the Warning is required to be deleted from a stored | |||
response after validation: | response after validation: | |||
o 1xx Warnings that describe the freshness or validation status of | o 1xx Warnings describe the freshness or validation status of the | |||
the response, and so MUST be deleted by caches after validation. | response, and so MUST be deleted by caches after validation. They | |||
They MUST NOT be generated by a cache except when validating a | can only be generated by a cache when validating a cached entry, | |||
cached entry, and MUST NOT be generated by clients. | and MUST NOT be generated in any other situation. | |||
o 2xx Warnings that describe some aspect of the entity body or | o 2xx Warnings describe some aspect of the entity body or entity | |||
entity headers that is not rectified by a validation (for example, | headers that is not rectified by a validation (for example, a | |||
a lossy compression of the entity bodies) and MUST NOT be deleted | lossy compression of the entity bodies) and MUST NOT be deleted by | |||
by caches after validation, unless a full response is returned, in | caches after validation, unless a full response is returned, in | |||
which case they MUST be. | which case they MUST be. | |||
The warn-text SHOULD be in a natural language and character set that | ||||
is most likely to be intelligible to the human user receiving the | ||||
response. This decision can be based on any available knowledge, | ||||
such as the location of the cache or user, the Accept-Language field | ||||
in a request, the Content-Language field in a response, etc. The | ||||
default language is English and the default character set is ISO- | ||||
8859-1 ([ISO-8859-1]). | ||||
If a character set other than ISO-8859-1 is used, it MUST be encoded | ||||
in the warn-text using the method described in [RFC2047]. | ||||
If an implementation sends a message with one or more Warning headers | If an implementation sends a message with one or more Warning headers | |||
to a receiver whose version is HTTP/1.0 or lower, then the sender | to a receiver whose version is HTTP/1.0 or lower, then the sender | |||
MUST include in each warning-value a warn-date that matches the Date | MUST include in each warning-value a warn-date that matches the Date | |||
header in the message. | header in the message. | |||
If an implementation receives a message with a warning-value that | If an implementation receives a message with a warning-value that | |||
includes a warn-date, and that warn-date is different from the Date | includes a warn-date, and that warn-date is different from the Date | |||
value in the response, then that warning-value MUST be deleted from | value in the response, then that warning-value MUST be deleted from | |||
the message before storing, forwarding, or using it. (preventing the | the message before storing, forwarding, or using it. (preventing the | |||
consequences of naive caching of Warning header fields.) If all of | consequences of naive caching of Warning header fields.) If all of | |||
skipping to change at page 29, line 39 | skipping to change at page 29, line 39 | |||
7. Acknowledgments | 7. Acknowledgments | |||
Much of the content and presentation of the caching design is due to | Much of the content and presentation of the caching design is due to | |||
suggestions and comments from individuals including: Shel Kaphan, | suggestions and comments from individuals including: Shel Kaphan, | |||
Paul Leach, Koen Holtman, David Morris, and Larry Masinter. | Paul Leach, Koen Holtman, David Morris, and Larry Masinter. | |||
8. References | 8. References | |||
8.1. Normative References | 8.1. Normative References | |||
[ISO-8859-1] | ||||
International Organization for Standardization, | ||||
"Information technology -- 8-bit single-byte coded graphic | ||||
character sets -- Part 1: Latin alphabet No. 1", ISO/ | ||||
IEC 8859-1:1998, 1998. | ||||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | |||
and Message Parsing", draft-ietf-httpbis-p1-messaging-07 | and Message Parsing", draft-ietf-httpbis-p1-messaging-08 | |||
(work in progress), July 2009. | (work in progress), October 2009. | |||
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 2: Message | and J. Reschke, Ed., "HTTP/1.1, part 2: Message | |||
Semantics", draft-ietf-httpbis-p2-semantics-07 (work in | Semantics", draft-ietf-httpbis-p2-semantics-08 (work in | |||
progress), July 2009. | progress), October 2009. | |||
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | |||
and Content Negotiation", draft-ietf-httpbis-p3-payload-07 | and Content Negotiation", draft-ietf-httpbis-p3-payload-08 | |||
(work in progress), July 2009. | (work in progress), October 2009. | |||
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional | and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional | |||
Requests", draft-ietf-httpbis-p4-conditional-07 (work in | Requests", draft-ietf-httpbis-p4-conditional-08 (work in | |||
progress), July 2009. | progress), October 2009. | |||
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | |||
Partial Responses", draft-ietf-httpbis-p5-range-07 (work | Partial Responses", draft-ietf-httpbis-p5-range-08 (work | |||
in progress), July 2009. | in progress), October 2009. | |||
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", | and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", | |||
draft-ietf-httpbis-p7-auth-07 (work in progress), | draft-ietf-httpbis-p7-auth-08 (work in progress), | |||
July 2009. | October 2009. | |||
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) | ||||
Part Three: Message Header Extensions for Non-ASCII Text", | ||||
RFC 2047, November 1996. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
8.2. Informative References | 8.2. Informative References | |||
[RFC1305] Mills, D., "Network Time Protocol (Version 3) | [RFC1305] Mills, D., "Network Time Protocol (Version 3) | |||
skipping to change at page 31, line 10 | skipping to change at page 31, line 4 | |||
[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, | |||
September 2004. | September 2004. | |||
Appendix A. Compatibility with Previous Versions | Appendix A. Compatibility with Previous Versions | |||
A.1. Changes from RFC 2068 | A.1. Changes from RFC 2068 | |||
A case was missed in the Cache-Control model of HTTP/1.1; s-maxage | A case was missed in the Cache-Control model of HTTP/1.1; s-maxage | |||
was introduced to add this missing case. (Sections 2.1, 3.2). | was introduced to add this missing case. (Sections 2.1, 3.2). | |||
Transfer-coding and message lengths all interact in ways that | Transfer-coding and message lengths all interact in ways that | |||
required fixing exactly when chunked encoding is used (to allow for | required fixing exactly when chunked encoding is used (to allow for | |||
transfer encoding that may not be self delimiting); it was important | transfer encoding that may not be self delimiting); it was important | |||
to straighten out exactly how message lengths are computed. (see also | to straighten out exactly how message lengths are computed. (see also | |||
[Part1], [Part3] and [Part5]) [[anchor17: This used to refer to the | [Part1], [Part3] and [Part5]) [[anchor16: This used to refer to the | |||
text about non-modifiable headers, and will have to be updated later | text about non-modifiable headers, and will have to be updated later | |||
on. --jre]] | on. --jre]] | |||
Proxies should be able to add Content-Length when appropriate. | Proxies should be able to add Content-Length when appropriate. | |||
[[anchor18: This used to refer to the text about non-modifiable | [[anchor17: This used to refer to the text about non-modifiable | |||
headers, and will have to be updated later on. --jre]] | headers, and will have to be updated later on. --jre]] | |||
Range request responses would become very verbose if all meta-data | Range request responses would become very verbose if all meta-data | |||
were always returned; by allowing the server to only send needed | were always returned; by allowing the server to only send needed | |||
headers in a 206 response, this problem can be avoided. | headers in a 206 response, this problem can be avoided. | |||
(Section 2.7) | (Section 2.7) | |||
The Cache-Control: max-age directive was not properly defined for | The Cache-Control: max-age directive was not properly defined for | |||
responses. (Section 3.2.2) | responses. (Section 3.2.2) | |||
Warnings could be cached incorrectly, or not updated appropriately. | Warnings could be cached incorrectly, or not updated appropriately. | |||
(Section 2.3, 2.7, 3.2, and 3.6) Warning also needed to be a general | (Section 2.3, 2.7, 3.2, and 3.6) Warning also needed to be a general | |||
header, as PUT or other methods may have need for it in requests. | header, as PUT or other methods may have need for it in requests. | |||
A.2. Changes from RFC 2616 | A.2. Changes from RFC 2616 | |||
Remove requirement to consider Content-Location in successful | ||||
responses in order to determine the appropriate response to use. | ||||
(Section 2.4) | ||||
Clarify denial of service attack avoidance requirement. | Clarify denial of service attack avoidance requirement. | |||
(Section 2.5) | (Section 2.5) | |||
Do not mention RFC 2047 encoding and multiple languages in Warning | ||||
headers anymore, as these aspects never were implemented. | ||||
(Section 3.6) | ||||
Appendix B. Collected ABNF | Appendix B. Collected ABNF | |||
Age = "Age:" OWS Age-v | Age = "Age:" OWS Age-v | |||
Age-v = delta-seconds | Age-v = delta-seconds | |||
Cache-Control = "Cache-Control:" OWS Cache-Control-v | Cache-Control = "Cache-Control:" OWS Cache-Control-v | |||
Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS | Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS | |||
cache-directive ] ) | cache-directive ] ) | |||
Expires = "Expires:" OWS Expires-v | Expires = "Expires:" OWS Expires-v | |||
Expires-v = HTTP-date | Expires-v = HTTP-date | |||
HTTP-date = <HTTP-date, defined in [Part1], Section 3.2> | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 1.2.2> | |||
Pragma = "Pragma:" OWS Pragma-v | Pragma = "Pragma:" OWS Pragma-v | |||
Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS | Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS | |||
pragma-directive ] ) | pragma-directive ] ) | |||
Vary = "Vary:" OWS Vary-v | Vary = "Vary:" OWS Vary-v | |||
Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name | Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name | |||
] ) ) | ] ) ) | |||
skipping to change at page 32, line 43 | skipping to change at page 32, line 44 | |||
OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( | OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / ( | |||
"no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS | "no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS | |||
field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / | field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" / | |||
"must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds | "must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds | |||
) / ( "s-maxage=" delta-seconds ) / cache-extension | ) / ( "s-maxage=" delta-seconds ) / cache-extension | |||
delta-seconds = 1*DIGIT | delta-seconds = 1*DIGIT | |||
extension-pragma = token [ "=" ( token / quoted-string ) ] | extension-pragma = token [ "=" ( token / quoted-string ) ] | |||
field-name = <field-name, defined in [Part1], Section 4.2> | field-name = <field-name, defined in [Part1], Section 3.2> | |||
port = <port, defined in [Part1], Section 2.1> | port = <port, defined in [Part1], Section 2.6> | |||
pragma-directive = "no-cache" / extension-pragma | pragma-directive = "no-cache" / extension-pragma | |||
pseudonym = <pseudonym, defined in [Part1], Section 8.9> | pseudonym = <pseudonym, defined in [Part1], Section 9.9> | |||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | |||
token = <token, defined in [Part1], Section 1.2.2> | token = <token, defined in [Part1], Section 1.2.2> | |||
uri-host = <uri-host, defined in [Part1], Section 2.1> | ||||
uri-host = <uri-host, defined in [Part1], Section 2.6> | ||||
warn-agent = ( uri-host [ ":" port ] ) / pseudonym | warn-agent = ( uri-host [ ":" port ] ) / pseudonym | |||
warn-code = 3DIGIT | warn-code = 3DIGIT | |||
warn-date = DQUOTE HTTP-date DQUOTE | warn-date = DQUOTE HTTP-date DQUOTE | |||
warn-text = quoted-string | warn-text = quoted-string | |||
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date | warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date | |||
] | ] | |||
ABNF diagnostics: | ABNF diagnostics: | |||
skipping to change at page 36, line 5 | skipping to change at page 36, line 5 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for | o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for | |||
numeric protocol elements" | numeric protocol elements" | |||
Affected issues: | Affected issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non- | o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non- | |||
existant headers | existant headers | |||
C.9. Since draft-ietf-httpbis-p6-cache-07 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of | ||||
1xx Warn-Codes" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content- | ||||
Location on 304 responses" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/169>: "private and | ||||
no-cache CC directives with headers" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/187>: "RFC2047 and | ||||
warn-text" | ||||
Index | Index | |||
A | A | |||
age 6 | age 6 | |||
Age header 17 | Age header 17 | |||
C | C | |||
cache 5 | cache 5 | |||
Cache Directives | Cache Directives | |||
max-age 19, 21 | max-age 18, 22 | |||
max-stale 19 | max-stale 19 | |||
min-fresh 19 | min-fresh 19 | |||
must-revalidate 21 | must-revalidate 21 | |||
no-cache 18, 20 | no-cache 18, 20 | |||
no-store 18, 21 | no-store 18, 21 | |||
no-transform 19, 22 | no-transform 19, 22 | |||
only-if-cached 19 | only-if-cached 19 | |||
private 20 | private 20 | |||
proxy-revalidate 21 | proxy-revalidate 21 | |||
public 20 | public 20 | |||
skipping to change at page 37, line 7 | skipping to change at page 37, line 24 | |||
cache-response-directive 20 | cache-response-directive 20 | |||
delta-seconds 17 | delta-seconds 17 | |||
Expires 23 | Expires 23 | |||
Expires-v 23 | Expires-v 23 | |||
extension-pragma 24 | extension-pragma 24 | |||
Pragma 24 | Pragma 24 | |||
pragma-directive 24 | pragma-directive 24 | |||
Pragma-v 24 | Pragma-v 24 | |||
Vary 24 | Vary 24 | |||
Vary-v 24 | Vary-v 24 | |||
warn-agent 25 | warn-agent 26 | |||
warn-code 25 | warn-code 26 | |||
warn-date 25 | warn-date 26 | |||
warn-text 25 | warn-text 26 | |||
Warning 25 | Warning 26 | |||
Warning-v 25 | Warning-v 26 | |||
warning-value 25 | warning-value 26 | |||
H | H | |||
Headers | Headers | |||
Age 17 | Age 17 | |||
Cache-Control 17 | Cache-Control 17 | |||
Expires 23 | Expires 23 | |||
Pragma 23 | Pragma 24 | |||
Vary 24 | Vary 24 | |||
Warning 25 | Warning 25 | |||
heuristic expiration time 5 | heuristic expiration time 5 | |||
M | M | |||
max-age | max-age | |||
Cache Directive 19, 21 | Cache Directive 18, 22 | |||
max-stale | max-stale | |||
Cache Directive 19 | Cache Directive 19 | |||
min-fresh | min-fresh | |||
Cache Directive 19 | Cache Directive 19 | |||
must-revalidate | must-revalidate | |||
Cache Directive 21 | Cache Directive 21 | |||
N | N | |||
no-cache | no-cache | |||
Cache Directive 18, 20 | Cache Directive 18, 20 | |||
no-store | no-store | |||
Cache Directive 18, 21 | Cache Directive 18, 21 | |||
no-transform | no-transform | |||
Cache Directive 19, 22 | Cache Directive 19, 22 | |||
O | O | |||
only-if-cached | only-if-cached | |||
Cache Directive 19 | Cache Directive 19 | |||
P | P | |||
Pragma header 23 | Pragma header 24 | |||
private | private | |||
Cache Directive 20 | Cache Directive 20 | |||
proxy-revalidate | proxy-revalidate | |||
Cache Directive 21 | Cache Directive 21 | |||
public | public | |||
Cache Directive 20 | Cache Directive 20 | |||
S | S | |||
s-maxage | s-maxage | |||
Cache Directive 22 | Cache Directive 22 | |||
End of changes. 62 change blocks. | ||||
129 lines changed or deleted | 122 lines changed or added | |||
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |