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/