draft-ietf-httpbis-p6-cache-04.txt   draft-ietf-httpbis-p6-cache-05.txt 
Network Working Group R. Fielding, Ed. Network 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: March 2, 2009 J. Mogul Expires: May 20, 2009 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
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
August 29, 2008 November 16, 2008
HTTP/1.1, part 6: Caching HTTP/1.1, part 6: Caching
draft-ietf-httpbis-p6-cache-04 draft-ietf-httpbis-p6-cache-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 March 2, 2009. This Internet-Draft will expire on May 20, 2009.
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. 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. Part 6 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines
requirements on HTTP caches and the associated header fields that requirements on HTTP caches and the associated header fields that
control cache behavior or indicate cacheable response messages. control cache behavior 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://www.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://www.tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix B.4. The changes in this draft are summarized in Appendix B.6.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
2. Notational Conventions and Generic Grammar . . . . . . . . . . 8 2. Notational Conventions and Generic Grammar . . . . . . . . . . 8
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Cache Correctness . . . . . . . . . . . . . . . . . . . . 8 3.1. Cache Correctness . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 4, line 21 skipping to change at page 4, line 21
Appendix A. Compatibility with Previous Versions . . . . . . . . 44 Appendix A. Compatibility with Previous Versions . . . . . . . . 44
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 44 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 44
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 45 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 45
Appendix B. Change Log (to be removed by RFC Editor before Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 45 publication) . . . . . . . . . . . . . . . . . . . . 45
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 45 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 45
B.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 45 B.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 45
B.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 46 B.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 46
B.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 46 B.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 46
B.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 46 B.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 46
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 47
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 52 Intellectual Property and Copyright Statements . . . . . . . . . . 52
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, and performance can be improved by the use of response caches, and
includes a number of elements intended to make caching work as well includes a number of elements intended to make caching work as well
as possible. Because these elements interact with each other, it is as possible. Because these elements interact with each other, it is
useful to describe the caching design of HTTP separately. This useful to describe the caching design of HTTP separately. This
skipping to change at page 8, line 10 skipping to change at page 8, line 10
REQUIRED level and all the SHOULD level requirements for its REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant."
2. Notational Conventions and Generic Grammar 2. Notational Conventions and Generic Grammar
This specification uses the ABNF syntax defined in Section 2.1 of This specification uses the ABNF syntax defined in Section 2.1 of
[Part1] and the core rules defined in Section 2.2 of [Part1]: [Part1] and the core rules defined in Section 2.2 of [Part1]:
[[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
DIGIT = <DIGIT, defined in [Part1], Section 2.2> DIGIT = <DIGIT, defined in [Part1], Section 2.2>
DQUOTE = <DQUOTE, defined in [Part1], Section 2.2> DQUOTE = <DQUOTE, defined in [Part1], Section 2.2>
SP = <SP, defined in [Part1], Section 2.2> SP = <SP, defined in [Part1], Section 2.2>
quoted-string = <quoted-string, defined in [Part1], Section 2.2> quoted-string = <quoted-string, defined in [Part1], Section 2.2>
token = <token, defined in [Part1], Section 2.2> token = <token, defined in [Part1], Section 2.2>
OWS = <OWS, defined in [Part1], Section 2.2>
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 4.2>
HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1> HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
port = <port, defined in [Part1], Section 3.2.1> port = <port, defined in [Part1], Section 3.2>
pseudonym = <pseudonym, defined in [Part1], Section 8.9> pseudonym = <pseudonym, defined in [Part1], Section 8.9>
uri-host = <uri-host, defined in [Part1], Section 3.2.1> uri-host = <uri-host, defined in [Part1], Section 3.2>
3. Overview 3. Overview
3.1. Cache Correctness 3.1. Cache Correctness
A correct cache MUST respond to a request with the most up-to-date A correct cache MUST respond to a request with the most up-to-date
response held by the cache that is appropriate to the request (see response held by the cache that is appropriate to the request (see
Sections 4.5, 4.6, and 14) which meets one of the following Sections 4.5, 4.6, and 14) which meets one of the following
conditions: conditions:
skipping to change at page 27, line 16 skipping to change at page 27, line 16
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.
16.1. Age 16.1. Age
The Age response-header field conveys the sender's estimate of the The response-header field "Age" conveys the sender's estimate of the
amount of time since the response (or its revalidation) was generated amount of time since the response (or its revalidation) was generated
at the origin server. A cached response is "fresh" if its age does at the origin server. A cached response is "fresh" if its age does
not exceed its freshness lifetime. Age values are calculated as not exceed its freshness lifetime. Age values are calculated as
specified in Section 4.3. specified in Section 4.3.
Age = "Age" ":" age-value Age = "Age" ":" OWS Age-v
age-value = delta-seconds Age-v = delta-seconds
Age values are non-negative decimal integers, representing time in Age values are non-negative decimal 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 value of 2147483648 (2^31). An MUST transmit an Age header with a value of 2147483648 (2^31). An
HTTP/1.1 server that includes a cache MUST include an Age header HTTP/1.1 server that includes a cache MUST include an Age header
field in every response generated from its own cache. Caches SHOULD field in every response generated from its own cache. Caches SHOULD
use an arithmetic type of at least 31 bits of range. use an arithmetic type of at least 31 bits of range.
16.2. Cache-Control 16.2. Cache-Control
The Cache-Control general-header field is used to specify directives The general-header field "Cache-Control" is used to specify
that MUST be obeyed by all caching mechanisms along the request/ directives that MUST be obeyed by all caching mechanisms along the
response chain. The directives specify behavior intended to prevent request/response chain. The directives specify behavior intended to
caches from adversely interfering with the request or response. prevent caches from adversely interfering with the request or
These directives typically override the default caching algorithms. response. These directives typically override the default caching
Cache directives are unidirectional in that the presence of a algorithms. Cache directives are unidirectional in that the presence
directive in a request does not imply that the same directive is to of a directive in a request does not imply that the same directive is
be given in the response. 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 16.4). might only implement Pragma: no-cache (see Section 16.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 specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control = "Cache-Control" ":" 1#cache-directive Cache-Control = "Cache-Control" ":" OWS Cache-Control-v
Cache-Control-v = 1#cache-directive
cache-directive = cache-request-directive cache-directive = cache-request-directive
| cache-response-directive / cache-response-directive
cache-request-directive = cache-request-directive =
"no-cache" ; Section 16.2.1 "no-cache" ; Section 16.2.1
| "no-store" ; Section 16.2.2 / "no-store" ; Section 16.2.2
| "max-age" "=" delta-seconds ; Section 16.2.3, 16.2.4 / "max-age" "=" delta-seconds ; Section 16.2.3, 16.2.4
| "max-stale" [ "=" delta-seconds ] ; Section 16.2.3 / "max-stale" [ "=" delta-seconds ] ; Section 16.2.3
| "min-fresh" "=" delta-seconds ; Section 16.2.3 / "min-fresh" "=" delta-seconds ; Section 16.2.3
| "no-transform" ; Section 16.2.5 / "no-transform" ; Section 16.2.5
| "only-if-cached" ; Section 16.2.4 / "only-if-cached" ; Section 16.2.4
| cache-extension ; Section 16.2.6 / cache-extension ; Section 16.2.6
cache-response-directive = cache-response-directive =
"public" ; Section 16.2.1 "public" ; Section 16.2.1
| "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1 / "private" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1
| "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1 / "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ] ; Section 16.2.1
| "no-store" ; Section 16.2.2 / "no-store" ; Section 16.2.2
| "no-transform" ; Section 16.2.5 / "no-transform" ; Section 16.2.5
| "must-revalidate" ; Section 16.2.4 / "must-revalidate" ; Section 16.2.4
| "proxy-revalidate" ; Section 16.2.4 / "proxy-revalidate" ; Section 16.2.4
| "max-age" "=" delta-seconds ; Section 16.2.3 / "max-age" "=" delta-seconds ; Section 16.2.3
| "s-maxage" "=" delta-seconds ; Section 16.2.3 / "s-maxage" "=" delta-seconds ; Section 16.2.3
| cache-extension ; Section 16.2.6 / cache-extension ; Section 16.2.6
cache-extension = token [ "=" ( token | quoted-string ) ] cache-extension = token [ "=" ( token / quoted-string ) ]
When a directive appears without any 1#field-name parameter, the When a directive appears without any 1#field-name parameter, the
directive applies to the entire request or response. When such a directive applies to the entire request or response. When such a
directive appears with a 1#field-name parameter, it applies only to directive appears with a 1#field-name parameter, it applies only to
the named field or fields, and not to the rest of the request or the named field or fields, and not to the rest of the request or
response. This mechanism supports extensibility; implementations of response. This mechanism supports extensibility; implementations of
future versions of HTTP might apply these directives to header fields future versions of HTTP might apply these directives to header fields
not defined in HTTP/1.1. not defined in HTTP/1.1.
The cache-control directives can be broken down into these general The cache-control directives can be broken down into these general
skipping to change at page 37, line 24 skipping to change at page 37, line 24
intermediate cache that has a fresh copy of the entity). See intermediate cache that has a fresh copy of the entity). See
Section 4 for further discussion of the expiration model. Section 4 for further discussion of the expiration 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 format is an absolute date and time as defined by HTTP-date in The format is an absolute date and time as defined by HTTP-date in
Section 3.3.1 of [Part1]; it MUST be sent in rfc1123-date format. Section 3.3.1 of [Part1]; it MUST be sent in rfc1123-date format.
Expires = "Expires" ":" HTTP-date Expires = "Expires" ":" OWS Expires-v
Expires-v = HTTP-date
An example of its use is An example of its use is
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 16.2.3), that directive overrides the age directive (see Section 16.2.3), that directive overrides the
Expires field. Expires field.
HTTP/1.1 clients and caches MUST treat other invalid date formats, HTTP/1.1 clients and caches MUST treat other invalid date formats,
skipping to change at page 38, line 7 skipping to change at page 38, line 7
sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
year in the future. year in the future.
The presence of an Expires header field with a date value of some The presence of an Expires header field with a date value of some
time in the future on a response that otherwise would by default be time in the future on a response that otherwise would by default be
non-cacheable indicates that the response is cacheable, unless non-cacheable indicates that the response is cacheable, unless
indicated otherwise by a Cache-Control header field (Section 16.2). indicated otherwise by a Cache-Control header field (Section 16.2).
16.4. Pragma 16.4. Pragma
The Pragma general-header field is used to include implementation- The general-header field "Pragma" 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" ":" 1#pragma-directive Pragma = "Pragma" ":" OWS Pragma-v
pragma-directive = "no-cache" | extension-pragma Pragma-v = 1#pragma-directive
extension-pragma = token [ "=" ( token | quoted-string ) ] pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
When the no-cache directive is present in a request message, an When the no-cache directive is present in a request message, an
application SHOULD forward the request toward the origin server even application SHOULD forward the request toward the origin server even
if it has a cached copy of what is being requested. This pragma if it has a cached copy of what is being requested. This pragma
directive has the same semantics as the no-cache cache-directive (see directive has the same semantics as the no-cache cache-directive (see
Section 16.2) and is defined here for backward compatibility with Section 16.2) and is defined here for backward compatibility with
HTTP/1.0. Clients SHOULD include both header fields when a no-cache HTTP/1.0. Clients SHOULD include both header fields when a no-cache
request is sent to a server not known to be HTTP/1.1 compliant. request is sent to a server not known to be HTTP/1.1 compliant.
Pragma directives MUST be passed through by a proxy or gateway Pragma directives MUST be passed through by a proxy or gateway
skipping to change at page 38, line 42 skipping to change at page 38, line 43
HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
sent "Cache-Control: no-cache". No new Pragma directives will be sent "Cache-Control: no-cache". No new Pragma directives will be
defined in HTTP. defined in HTTP.
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.
16.5. Vary 16.5. Vary
The Vary response-header field's value indicates the set of request- The "Vary" response-header field's value indicates the set of
header fields that fully determines, while the response is fresh, request-header fields that fully determines, while the response is
whether a cache is permitted to use the response to reply to a fresh, whether a cache is permitted to use the response to reply to a
subsequent request without revalidation. For uncacheable or stale subsequent request without revalidation. For uncacheable or stale
responses, the Vary field value advises the user agent about the responses, the Vary field value advises the user agent about the
criteria that were used to select the representation. A Vary field criteria that were used to select the representation. A Vary field
value of "*" implies that a cache cannot determine from the request value of "*" implies that a cache cannot determine from the request
headers of a subsequent request whether this response is the headers of a subsequent request whether this response is the
appropriate representation. See Section 8 for use of the Vary header appropriate representation. See Section 8 for use of the Vary header
field by caches. field by caches.
Vary = "Vary" ":" ( "*" | 1#field-name ) Vary = "Vary" ":" OWS Vary-v
Vary-v = "*" / 1#field-name
An HTTP/1.1 server SHOULD include a Vary header field with any An HTTP/1.1 server SHOULD include a Vary header field with any
cacheable response that is subject to server-driven negotiation. cacheable response that is subject to server-driven negotiation.
Doing so allows a cache to properly interpret future requests on that Doing so allows a cache to properly interpret future requests on that
resource and informs the user agent about the presence of negotiation resource and informs the user agent about the presence of negotiation
on that resource. A server MAY include a Vary header field with a on that resource. A server MAY include a Vary header field with a
non-cacheable response that is subject to server-driven negotiation, non-cacheable response that is subject to server-driven negotiation,
since this might provide the user agent with useful information about since this might provide the user agent with useful information about
the dimensions over which the response varies at the time of the the dimensions over which the response varies at the time of the
response. response.
skipping to change at page 39, line 37 skipping to change at page 39, line 38
insensitive. insensitive.
A Vary field value of "*" signals that unspecified parameters not A Vary field value of "*" signals that unspecified parameters not
limited to the request-headers (e.g., the network address of the limited to the request-headers (e.g., the network address of the
client), play a role in the selection of the response representation. client), play a role in the selection of the response representation.
The "*" value MUST NOT be generated by a proxy server; it may only be The "*" value MUST NOT be generated by a proxy server; it may only be
generated by an origin server. generated by an origin server.
16.6. Warning 16.6. Warning
The Warning general-header field is used to carry additional The general-header field "Warning" is used to carry additional
information about the status or transformation of a message which information about the status or transformation of a message which
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 a possible lack of semantic transparency from used to warn about a possible lack of semantic transparency from
caching operations or transformations applied to the entity body of caching operations or transformations applied to the entity body of
the message. the message.
Warning headers are sent with responses using: Warning headers are sent with responses using:
Warning = "Warning" ":" 1#warning-value Warning = "Warning" ":" OWS Warning-v
Warning-v = 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date] [SP warn-date]
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
A response MAY carry more than one Warning header. A response MAY carry more than one Warning header.
The warn-text SHOULD be in a natural language and character set that 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 is most likely to be intelligible to the human user receiving the
response. This decision MAY be based on any available knowledge, response. This decision MAY be based on any available knowledge,
skipping to change at page 43, line 27 skipping to change at page 43, line 29
[ISO-8859-1] [ISO-8859-1]
International Organization for Standardization, International Organization for Standardization,
"Information technology -- 8-bit single-byte coded graphic "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. 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-04 and Message Parsing", draft-ietf-httpbis-p1-messaging-05
(work in progress), August 2008. (work in progress), November 2008.
[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-04 (work in Semantics", draft-ietf-httpbis-p2-semantics-05 (work in
progress), August 2008. progress), November 2008.
[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-04 and Content Negotiation", draft-ietf-httpbis-p3-payload-05
(work in progress), August 2008. (work in progress), November 2008.
[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-04 (work in Requests", draft-ietf-httpbis-p4-conditional-05 (work in
progress), August 2008. progress), November 2008.
[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-04 (work Partial Responses", draft-ietf-httpbis-p5-range-05 (work
in progress), August 2008. in progress), November 2008.
[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-04 (work in progress), draft-ietf-httpbis-p7-auth-05 (work in progress),
August 2008. November 2008.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. 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.
20.2. Informative References 20.2. Informative References
skipping to change at page 45, line 30 skipping to change at page 45, line 31
Appendix B. Change Log (to be removed by RFC Editor before publication) Appendix B. Change Log (to be removed by RFC Editor before publication)
B.1. Since RFC2616 B.1. Since RFC2616
Extracted relevant partitions from [RFC2616]. Extracted relevant partitions from [RFC2616].
B.2. Since draft-ietf-httpbis-p6-cache-00 B.2. Since draft-ietf-httpbis-p6-cache-00
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/9>: "Trailer" o <http://tools.ietf.org/wg/httpbis/trac/ticket/9>: "Trailer"
(<http://purl.org/NET/http-errata#trailer-hop>) (<http://purl.org/NET/http-errata#trailer-hop>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/12>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/12>: "Invalidation
"Invalidation after Update or Delete" after Update or Delete"
(<http://purl.org/NET/http-errata#invalidupd>) (<http://purl.org/NET/http-errata#invalidupd>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
and Informative references" Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
reference typo" typo"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/49>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/49>: "Connection
"Connection header text" header text"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
"Informative references" references"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
Reference"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/66>: o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
"ISO-8859-1 Reference" to-date references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative
up-to-date references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/87>: "typo in o <http://tools.ietf.org/wg/httpbis/trac/ticket/87>: "typo in
13.2.2" 13.2.2"
Other changes: Other changes:
o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress
on <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>) on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
B.3. Since draft-ietf-httpbis-p6-cache-01 B.3. Since draft-ietf-httpbis-p6-cache-01
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
not used" used"
Other changes: Other changes:
o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work
in progress on in progress on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>)
o Add explicit references to BNF syntax and rules imported from o Add explicit references to BNF syntax and rules imported from
other parts of the specification. other parts of the specification.
B.4. Since draft-ietf-httpbis-p6-cache-02 B.4. Since draft-ietf-httpbis-p6-cache-02
Ongoing work on IANA Message Header Registration Ongoing work on IANA Message Header Registration
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>): (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
o Reference RFC 3984, and update header registrations for headers o Reference RFC 3984, and update header registrations for headers
defined in this document. defined in this document.
B.5. Since draft-ietf-httpbis-p6-cache-03 B.5. Since draft-ietf-httpbis-p6-cache-03
Closed issues: Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/106>: "Vary o <http://tools.ietf.org/wg/httpbis/trac/ticket/106>: "Vary header
header classification" classification"
B.6. Since draft-ietf-httpbis-p6-cache-04
Ongoing work on ABNF conversion
(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Use "/" instead of "|" for alternatives.
o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
whitespace ("OWS") and required whitespace ("RWS").
o Rewrite ABNFs to spell out whitespace rules, factor out header
value format definitions.
Index Index
A A
age 7 age 7
Age header 27 Age header 27
C C
cache 5 cache 5
Cache Directives Cache Directives
max-age 32-33 max-age 32-33
max-stale 32 max-stale 32
min-fresh 32 min-fresh 32
must-revalidate 34 must-revalidate 34
no-cache 29 no-cache 29
no-store 30 no-store 30
no-transform 35 no-transform 35
skipping to change at page 47, line 34 skipping to change at page 48, line 6
explicit expiration time 7 explicit expiration time 7
F F
first-hand 6 first-hand 6
fresh 7 fresh 7
freshness lifetime 7 freshness lifetime 7
G G
Grammar Grammar
Age 27 Age 27
age-value 27 Age-v 27
Cache-Control 28 Cache-Control 28
Cache-Control-v 28
cache-directive 28 cache-directive 28
cache-extension 28 cache-extension 28
cache-request-directive 28 cache-request-directive 28
cache-response-directive 28 cache-response-directive 28
delta-seconds 27 delta-seconds 27
Expires 37 Expires 37
Expires-v 37
extension-pragma 38 extension-pragma 38
Pragma 38 Pragma 38
pragma-directive 38 pragma-directive 38
Vary 38 Pragma-v 38
Vary 39
Vary-v 39
warn-agent 40 warn-agent 40
warn-code 40 warn-code 40
warn-date 40 warn-date 40
warn-text 40 warn-text 40
Warning 40 Warning 40
Warning-v 40
warning-value 40 warning-value 40
H H
Headers Headers
Age 27 Age 27
Cache-Control 27 Cache-Control 27
Expires 37 Expires 37
Pragma 38 Pragma 38
Vary 38 Vary 38
Warning 39 Warning 39
heuristic expiration time 7 heuristic expiration time 7
 End of changes. 54 change blocks. 
92 lines changed or deleted 116 lines changed or added

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