draft-ietf-httpbis-p6-cache-16.txt		draft-ietf-httpbis-p6-cache-17.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: February 25, 2012 J. Mogul		Expires: May 3, 2012 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	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.
			Rackspace
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	August 24, 2011		October 31, 2011
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-16		draft-ietf-httpbis-p6-cache-17
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 6 of the		information initiative since 1990. This document is Part 6 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616.		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	skipping to change at page 2, line 6		skipping to change at page 2, line 6
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org), which is archived at		group mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.17.		The changes in this draft are summarized in Appendix C.18.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 25, 2012.		This Internet-Draft will expire on May 3, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 10		skipping to change at page 3, line 10
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	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 . . . . . . . . . . . . . . . . . . . . . . . 7		1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7
	1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7		1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
	1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7		1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8
	1.4.2. ABNF Rules defined in other Parts of the		1.4.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 8		Specification . . . . . . . . . . . . . . . . . . . . 8
	1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8		1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
	2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8		2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9		2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9
	2.2. Constructing Responses from Caches . . . . . . . . . . . . 10		2.2. Constructing Responses from Caches . . . . . . . . . . . . 10
	2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11		2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11
	2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12		2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12
	2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13		2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13
	2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15		2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15
	2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16		2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16
	2.5. Request Methods that Invalidate . . . . . . . . . . . . . 16		2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17
	2.6. Shared Caching of Authenticated Responses . . . . . . . . 17		2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18
	2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 18		2.6. Shared Caching of Authenticated Responses . . . . . . . . 18
	2.8. Combining Partial Content . . . . . . . . . . . . . . . . 18		2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19
	2.9. Freshening Responses . . . . . . . . . . . . . . . . . . . 19		2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20
	3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20		3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
	3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20		3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
	3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21		3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
	3.2.2. Response Cache-Control Directives . . . . . . . . . . 23		3.2.2. Response Cache-Control Directives . . . . . . . . . . 23
	3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25		3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
	3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 26		3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
	3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 27		3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29		3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
	4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31		4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31		5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32
	5.2. Header Field Registration . . . . . . . . . . . . . . . . 32		5.2. Header Field Registration . . . . . . . . . . . . . . . . 33
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 32		6. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 33		8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
	8.2. Informative References . . . . . . . . . . . . . . . . . . 33		8.2. Informative References . . . . . . . . . . . . . . . . . . 34
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 34		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 36		publication) . . . . . . . . . . . . . . . . . . . . 36
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36
	C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 36		C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37
	C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37		C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37
	C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 37		C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38
	C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 37		C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 38
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 37		C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 38
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38		C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38
	C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 38		C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 39
	C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 38		C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 39
	C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39		C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39
	C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 39		C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 40
	C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40		C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40
	C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 40		C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41
	C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 40		C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 41
	C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 40		C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 41
	C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 40		C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 41
	C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 41		C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 42
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	1. Introduction		1. Introduction
	HTTP is typically used for distributed information systems, where		HTTP is typically used for distributed information systems, where
	performance can be improved by the use of response caches. This		performance can be improved by the use of response caches. This
	document defines aspects of HTTP/1.1 related to caching and reusing		document defines aspects of HTTP/1.1 related to caching and reusing
	response messages.		response messages.
	1.1. Purpose		1.1. Purpose
	skipping to change at page 7, line 13		skipping to change at page 7, line 13
	equivalent copy of a representation. See Section 2.1 of [Part4].		equivalent copy of a representation. See Section 2.1 of [Part4].
	strong validator		strong validator
	A validator that is defined by the origin server such that its		A validator that is defined by the origin server such that its
	current value will change if the representation body changes;		current value will change if the representation body changes;
	i.e., an entity-tag that is not marked as weak (Section 2.3 of		i.e., an entity-tag that is not marked as weak (Section 2.3 of
	[Part4]) or, if no entity-tag is provided, a Last-Modified value		[Part4]) or, if no entity-tag is provided, a Last-Modified value
	that is strong in the sense defined by Section 2.2.2 of [Part4].		that is strong in the sense defined by Section 2.2.2 of [Part4].
	1.3. Requirements		1.3. Conformance and Error Handling
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	An implementation is not compliant if it fails to satisfy one or more		This document defines conformance criteria for several roles in HTTP
	of the "MUST" or "REQUIRED" level requirements for the protocols it		communication, including Senders, Recipients, Clients, Servers, User-
	implements. An implementation that satisfies all the "MUST" or		Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
	"REQUIRED" level and all the "SHOULD" level requirements for its		Section 2 of [Part1] for definitions of these terms.
	protocols is said to be "unconditionally compliant"; one that
	satisfies all the "MUST" level requirements but not all the "SHOULD"		An implementation is considered conformant if it complies with all of
	level requirements for its protocols is said to be "conditionally		the requirements associated with its role(s). Note that SHOULD-level
	compliant".		requirements are relevant here, unless one of the documented
			exceptions is applicable.
			This document also uses ABNF to define valid protocol elements
			(Section 1.4). In addition to the prose requirements placed upon
			them, Senders MUST NOT generate protocol elements that are invalid.
			Unless noted otherwise, Recipients MAY take steps to recover a usable
			protocol element from an invalid construct. However, HTTP does not
			define specific error handling mechanisms, except in cases where it
			has direct impact on security. This is because different uses of the
			protocol require different error handling strategies; for example, a
			Web browser may wish to transparently recover from a response where
			the Location header field doesn't parse according to the ABNF,
			whereby in a systems control protocol using HTTP, this type of error
			recovery could lead to dangerous consequences.
	1.4. Syntax Notation		1.4. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the ABNF syntax defined in Section 1.2 of
	[Part1] (which extends the syntax defined in [RFC5234] with a list		[Part1] (which extends the syntax defined in [RFC5234] with a list
	rule). Appendix B shows the collected ABNF, with the list rule		rule). Appendix B shows the collected ABNF, with the list rule
	expanded.		expanded.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), VCHAR (any visible USASCII character),		sequence of data), SP (space), and VCHAR (any visible US-ASCII
	and WSP (whitespace).		character).
	1.4.1. Core Rules		1.4.1. Core Rules
	The core rules below are defined in [Part1]:		The core rules below are defined in [Part1]:
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.3>
	1.4.2. ABNF Rules defined in other Parts of the Specification		1.4.2. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	field-name = <field-name, defined in [Part1], Section 3.2>		field-name = <field-name, defined in [Part1], Section 3.2>
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8>
	port = <port, defined in [Part1], Section 2.7>		port = <port, defined in [Part1], Section 2.7>
	pseudonym = <pseudonym, defined in [Part1], Section 9.9>		pseudonym = <pseudonym, defined in [Part1], Section 8.8>
	uri-host = <uri-host, defined in [Part1], Section 2.7>		uri-host = <uri-host, defined in [Part1], Section 2.7>
	1.5. Delta Seconds		1.5. Delta Seconds
	The delta-seconds rule specifies a non-negative integer, representing		The delta-seconds rule specifies a non-negative integer, representing
	time in seconds.		time in seconds.
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	If an implementation receives a delta-seconds value larger than the		If an implementation receives a delta-seconds value larger than the
	largest positive integer it can represent, or if any of its		largest positive integer it can represent, or if any of its
	subsequent calculations overflows, it MUST consider the value to be		subsequent calculations overflows, it MUST consider the value to be
	2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD		2147483648 (2^31). Recipients parsing a delta-seconds value MUST use
	use an arithmetic type of at least 31 bits of range, and senders MUST		an arithmetic type of at least 31 bits of range, and senders MUST NOT
	NOT send delta-seconds with a value greater than 2147483648.		send delta-seconds with a value greater than 2147483648.
	2. Cache Operation		2. Cache Operation
	Proper cache operation preserves the semantics of HTTP transfers		Proper cache operation preserves the semantics of HTTP transfers
	([Part2]) while eliminating the transfer of information already held		([Part2]) while eliminating the transfer of information already held
	in the cache. Although caching is an entirely OPTIONAL feature of		in the cache. Although caching is an entirely OPTIONAL feature of
	HTTP, we assume that reusing the cached response is desirable and		HTTP, we assume that reusing the cached response is desirable and
	that such reuse is the default behavior when no requirement or		that such reuse is the default behavior when no requirement or
	locally-desired configuration prevents it. Therefore, HTTP cache		locally-desired configuration prevents it. Therefore, HTTP cache
	requirements are focused on preventing a cache from either storing a		requirements are focused on preventing a cache from either storing a
	skipping to change at page 11, line 17		skipping to change at page 11, line 31
	Note that any of the requirements listed above can be overridden by a		Note that any of the requirements listed above can be overridden by a
	cache-control extension; see Section 3.2.3.		cache-control extension; see Section 3.2.3.
	When a stored response is used to satisfy a request without		When a stored response is used to satisfy a request without
	validation, a cache MUST include a single Age header field		validation, a cache MUST include a single Age header field
	(Section 3.1) in the response with a value equal to the stored		(Section 3.1) in the response with a value equal to the stored
	response's current_age; see Section 2.3.2.		response's current_age; see Section 2.3.2.
	A cache MUST write through requests with methods that are unsafe		A cache MUST write through requests with methods that are unsafe
	(Section 7.1.1 of [Part2]) to the origin server; i.e., a cache must		(Section 6.1.1 of [Part2]) to the origin server; i.e., a cache must
	not generate a reply to such a request before having forwarded the		not generate a reply to such a request before having forwarded the
	request and having received a corresponding response.		request and having received a corresponding response.
	Also, note that unsafe requests might invalidate already stored		Also, note that unsafe requests might invalidate already stored
	responses; see Section 2.5.		responses; see Section 2.5.
	When more than one suitable response is stored, a cache MUST use the		When more than one suitable response is stored, a cache MUST use the
	most recent response (as determined by the Date header field). It		most recent response (as determined by the Date header field). It
	can also forward a request with "Cache-Control: max-age=0" or "Cache-		can also forward a request with "Cache-Control: max-age=0" or "Cache-
	Control: no-cache" to disambiguate which response to use.		Control: no-cache" to disambiguate which response to use.
	skipping to change at page 13, line 9		skipping to change at page 13, line 22
	A heuristic freshness lifetime might be applicable; see		A heuristic freshness lifetime might be applicable; see
	Section 2.3.1.1.		Section 2.3.1.1.
	Note that this calculation is not vulnerable to clock skew, since all		Note that this calculation is not vulnerable to clock skew, since all
	of the information comes from the origin server.		of the information comes from the origin server.
	2.3.1.1. Calculating Heuristic Freshness		2.3.1.1. Calculating Heuristic Freshness
	If no explicit expiration time is present in a stored response that		If no explicit expiration time is present in a stored response that
	has a status code whose definition allows heuristic freshness to be		has a status code whose definition allows heuristic freshness to be
	used (including the following in Section 8 of [Part2]: 200, 203, 206,		used (including the following in Section 7 of [Part2]: 200, 203, 206,
	300, 301 and 410), a cache MAY calculate a heuristic expiration time.		300, 301 and 410), a cache MAY calculate a heuristic expiration time.
	A cache MUST NOT use heuristics to determine freshness for responses		A cache MUST NOT use heuristics to determine freshness for responses
	with status codes that do not explicitly allow it.		with status codes that do not explicitly allow it.
	When a heuristic is used to calculate freshness lifetime, a cache		When a heuristic is used to calculate freshness lifetime, a cache
	SHOULD attach a Warning header field with a 113 warn-code to the		SHOULD attach a Warning header field with a 113 warn-code to the
	response if its current_age is more than 24 hours and such a warning		response if its current_age is more than 24 hours and such a warning
	is not already present.		is not already present.
	Also, if the response has a Last-Modified header field (Section 2.2		Also, if the response has a Last-Modified header field (Section 2.2
	of [Part4]), a cache SHOULD NOT use a heuristic expiration value that		of [Part4]), caches are encouraged to use a heuristic expiration
	is more than some fraction of the interval since that time. A		value that is no more than some fraction of the interval since that
	typical setting of this fraction might be 10%.		time. A typical setting of this fraction might be 10%.
	Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do		Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do
	not calculate heuristic freshness for URIs with query components		not calculate heuristic freshness for URIs with query components
	(i.e., those containing '?'). In practice, this has not been		(i.e., those containing '?'). In practice, this has not been
	widely implemented. Therefore, servers are encouraged to send		widely implemented. Therefore, servers are encouraged to send
	explicit directives (e.g., Cache-Control: no-cache) if they wish		explicit directives (e.g., Cache-Control: no-cache) if they wish
	to preclude caching.		to preclude caching.
	2.3.2. Calculating Age		2.3.2. Calculating Age
	skipping to change at page 14, line 6		skipping to change at page 14, line 19
	The term "age_value" denotes the value of the Age header field		The term "age_value" denotes the value of the Age header field
	(Section 3.1), in a form appropriate for arithmetic operation; or		(Section 3.1), in a form appropriate for arithmetic operation; or
	0, if not available.		0, if not available.
	date_value		date_value
	HTTP/1.1 requires origin servers to send a Date header field, if		HTTP/1.1 requires origin servers to send a Date header field, if
	possible, with every response, giving the time at which the		possible, with every response, giving the time at which the
	response was generated. The term "date_value" denotes the value		response was generated. The term "date_value" denotes the value
	of the Date header field, in a form appropriate for arithmetic		of the Date header field, in a form appropriate for arithmetic
	operations. See Section 9.3 of [Part1] for the definition of the		operations. See Section 9.2 of [Part2] for the definition of the
	Date header field, and for requirements regarding responses		Date header field, and for requirements regarding responses
	without it.		without it.
	now		now
	The term "now" means "the current value of the clock at the host		The term "now" means "the current value of the clock at the host
	performing the calculation". A cache SHOULD use NTP ([RFC1305])		performing the calculation". A cache SHOULD use NTP ([RFC1305])
	or some similar protocol to synchronize its clocks to a globally		or some similar protocol to synchronize its clocks to a globally
	accurate time standard.		accurate time standard.
	skipping to change at page 15, line 8		skipping to change at page 15, line 21
	corrected_initial_age = max(apparent_age, corrected_age_value);		corrected_initial_age = max(apparent_age, corrected_age_value);
	The current_age of a stored response can then be calculated by adding		The current_age of a stored response can then be calculated by adding
	the amount of time (in seconds) since the stored response was last		the amount of time (in seconds) since the stored response was last
	validated by the origin server to the corrected_initial_age.		validated by the origin server to the corrected_initial_age.
	resident_time = now - response_time;		resident_time = now - response_time;
	current_age = corrected_initial_age + resident_time;		current_age = corrected_initial_age + resident_time;
	Additional rules for requirements on parsing and encoding of dates		Additionally, to avoid common problems in date parsing:
	and other potential problems with date encodings include:
	o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date		o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
	which appears to be more than 50 years in the future is in fact in		which appears to be more than 50 years in the future is in fact in
	the past (this helps solve the "year 2000" problem).		the past (this helps solve the "year 2000" problem).
	o Although all date formats are specified to be case-sensitive,		o Although all date formats are specified to be case-sensitive,
	recipients SHOULD match day, week and timezone names case-		recipients SHOULD match day, week and timezone names case-
	insensitively.		insensitively.
	o An HTTP/1.1 implementation MAY internally represent a parsed		o An HTTP/1.1 implementation MAY internally represent a parsed
	skipping to change at page 15, line 44		skipping to change at page 16, line 7
	A "stale" response is one that either has explicit expiry information		A "stale" response is one that either has explicit expiry information
	or is allowed to have heuristic expiry calculated, but is not fresh		or is allowed to have heuristic expiry calculated, but is not fresh
	according to the calculations in Section 2.3.		according to the calculations in Section 2.3.
	A cache MUST NOT return a stale response if it is prohibited by an		A cache MUST NOT return a stale response if it is prohibited by an
	explicit in-protocol directive (e.g., by a "no-store" or "no-cache"		explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
	cache directive, a "must-revalidate" cache-response-directive, or an		cache directive, a "must-revalidate" cache-response-directive, or an
	applicable "s-maxage" or "proxy-revalidate" cache-response-directive;		applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
	see Section 3.2.2).		see Section 3.2.2).
	A cache SHOULD NOT return stale responses unless it is disconnected		A cache MUST NOT return stale responses unless it is disconnected
	(i.e., it cannot contact the origin server or otherwise find a		(i.e., it cannot contact the origin server or otherwise find a
	forward path) or doing so is explicitly allowed (e.g., by the max-		forward path) or doing so is explicitly allowed (e.g., by the max-
	stale request directive; see Section 3.2.1).		stale request directive; see Section 3.2.1).
	A cache SHOULD append a Warning header field with the 110 warn-code		A cache SHOULD append a Warning header field with the 110 warn-code
	(see Section 3.6) to stale responses. Likewise, a cache SHOULD add		(see Section 3.6) to stale responses. Likewise, a cache SHOULD add
	the 112 warn-code to stale responses if the cache is disconnected.		the 112 warn-code to stale responses if the cache is disconnected.
	If a cache receives a first-hand response (either an entire response,		If a cache receives a first-hand response (either an entire response,
	or a 304 (Not Modified) response) that it would normally forward to		or a 304 (Not Modified) response) that it would normally forward to
	the requesting client, and the received response is no longer fresh,		the requesting client, and the received response is no longer fresh,
	the cache SHOULD forward it to the requesting client without adding a		the cache can forward it to the requesting client without adding a
	new Warning (but without removing any existing Warning header		new Warning (but without removing any existing Warning header
	fields). A cache SHOULD NOT attempt to validate a response simply		fields). A cache shouldn't attempt to validate a response simply
	because that response became stale in transit.		because that response became stale in transit.
	2.4. Validation Model		2.4. Validation Model
	When a cache has one or more stored responses for a requested URI,		When a cache has one or more stored responses for a requested URI,
	but cannot serve any of them (e.g., because they are not fresh, or		but cannot serve any of them (e.g., because they are not fresh, or
	one cannot be selected; see Section 2.7), it can use the conditional		one cannot be selected; see Section 2.7), it can use the conditional
	request mechanism [Part4] in the forwarded request to give the origin		request mechanism [Part4] in the forwarded request to give the origin
	server an opportunity to both select a valid stored response to be		server an opportunity to both select a valid stored response to be
	used, and to update it. This process is known as "validating" or		used, and to update it. This process is known as "validating" or
	"revalidating" the stored response.		"revalidating" the stored response.
	When sending such a conditional request, a cache SHOULD add an If-		When sending such a conditional request, a cache adds an If-Modified-
	Modified-Since header field whose value is that of the Last-Modified		Since header field whose value is that of the Last-Modified header
	header field from the selected (see Section 2.7) stored response, if		field from the selected (see Section 2.7) stored response, if
	available.		available.
	Additionally, a cache SHOULD add an If-None-Match header field whose		Additionally, a cache can add an If-None-Match header field whose
	value is that of the ETag header field(s) from all responses stored		value is that of the ETag header field(s) from all responses stored
	for the requested URI, if present. However, if any of the stored		for the requested URI, if present. However, if any of the stored
	responses contains only partial content, the cache SHOULD NOT include		responses contains only partial content, the cache shouldn't include
	its entity-tag in the If-None-Match header field unless the request		its entity-tag in the If-None-Match header field unless the request
	is for a range that would be fully satisfied by that stored response.		is for a range that would be fully satisfied by that stored response.
	A 304 (Not Modified) response status code indicates that the stored		Cache handling of a response to a conditional request is dependent
	response can be updated and reused; see Section 2.9.		upon its status code:
	A full response (i.e., one with a response body) indicates that none		o A 304 (Not Modified) response status code indicates that the
	of the stored responses nominated in the conditional request is		stored response can be updated and reused; see Section 2.4.1.
	suitable. Instead, a cache SHOULD use the full response to satisfy
	the request and MAY replace the stored response(s).
	If a cache receives a 5xx response while attempting to validate a		o A full response (i.e., one with a response body) indicates that
	response, it MAY either forward this response to the requesting		none of the stored responses nominated in the conditional request
	client, or act as if the server failed to respond. In the latter		is suitable. Instead, the cache can use the full response to
	case, it MAY return a previously stored response (see Section 2.3.3).		satisfy the request and MAY replace the stored response(s).
			o However, if a cache receives a 5xx response while attempting to
			validate a response, it can either forward this response to the
			requesting client, or act as if the server failed to respond. In
			the latter case, it can return a previously stored response (see
			Section 2.3.3).
			2.4.1. Freshening Responses
			When a cache receives a 304 (Not Modified) response and already has
			one or more stored 200 (OK) responses for the same cache key, the
			cache needs to identify which of the stored responses are updated by
			this new response and then update the stored response(s) with the new
			information provided in the 304 response.
			o If the new response contains a strong validator, then that strong
			validator identifies the selected representation. All of the
			stored responses with the same strong validator are selected. If
			none of the stored responses contain the same strong validator,
			then this new response corresponds to a new selected
			representation and MUST NOT update the existing stored responses.
			o If the new response contains a weak validator and that validator
			corresponds to one of the cache's stored responses, then the most
			recent of those matching stored responses is selected.
			o If the new response does not include any form of validator, there
			is only one stored response, and that stored response also lacks a
			validator, then that stored response is selected.
			If a stored response is selected for update, the cache MUST:
			o delete any Warning header fields in the stored response with warn-
			code 1xx (see Section 3.6);
			o retain any Warning header fields in the stored response with warn-
			code 2xx; and,
			o use other header fields provided in the 304 response to replace
			all instances of the corresponding header fields in the stored
			response.
	2.5. Request Methods that Invalidate		2.5. Request Methods that Invalidate
	Because unsafe request methods (Section 7.1.1 of [Part2]) such as		Because unsafe request methods (Section 6.1.1 of [Part2]) such as
	PUT, POST or DELETE have the potential for changing state on the		PUT, POST or DELETE have the potential for changing state on the
	origin server, intervening caches can use them to keep their contents		origin server, intervening caches can use them to keep their contents
	up-to-date.		up-to-date.
	A cache MUST invalidate the effective Request URI (Section 4.3 of		A cache MUST invalidate the effective Request URI (Section 4.3 of
	[Part1]) as well as the URI(s) in the Location and Content-Location		[Part1]) as well as the URI(s) in the Location and Content-Location
	header fields (if present) when a non-error response to a request		header fields (if present) when a non-error response to a request
	with an unsafe method is received.		with an unsafe method is received.
	However, a cache MUST NOT invalidate a URI from a Location or		However, a cache MUST NOT invalidate a URI from a Location or
	Content-Location header field if the host part of that URI differs		Content-Location header field if the host part of that URI differs
	from the host part in the effective request URI (Section 4.3 of		from the host part in the effective request URI (Section 4.3 of
	[Part1]). This helps prevent denial of service attacks.		[Part1]). This helps prevent denial of service attacks.
	A cache SHOULD invalidate the effective request URI (Section 4.3 of		A cache MUST invalidate the effective request URI (Section 4.3 of
	[Part1]) when it receives a non-error response to a request with a		[Part1]) when it receives a non-error response to a request with a
	method whose safety is unknown.		method whose safety is unknown.
	Here, a "non-error response" is one with a 2xx or 3xx status code.		Here, a "non-error response" is one with a 2xx or 3xx status code.
	"Invalidate" means that the cache will either remove all stored		"Invalidate" means that the cache will either remove all stored
	responses related to the effective request URI, or will mark these as		responses related to the effective request URI, or will mark these as
	"invalid" and in need of a mandatory validation before they can be		"invalid" and in need of a mandatory validation before they can be
	returned in response to a subsequent request.		returned in response to a subsequent request.
	Note that this does not guarantee that all appropriate responses are		Note that this does not guarantee that all appropriate responses are
	skipping to change at page 18, line 44		skipping to change at page 19, line 45
	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 header fields is known as		The stored response with matching selecting header fields is known as
	the selected response.		the selected response.
	If multiple selected responses are available, the most recent		If multiple selected responses are available, the most recent
	response (as determined by the Date header field) is used; see		response (as determined by the Date header field) is used; see
	Section 2.2.		Section 2.2.
	If no selected response is available, the cache MAY forward the		If no selected response is available, the cache can forward the
	presented request to the origin server in a conditional request; see		presented request to the origin server in a conditional request; see
	Section 2.4.		Section 2.4.
	2.8. Combining Partial Content		2.8. Combining Partial Content
	A response might transfer only a partial representation if the		A response might transfer only a partial representation if the
	connection closed prematurely or if the request used one or more		connection closed prematurely or if the request used one or more
	Range specifiers ([Part5]). After several such transfers, a cache		Range specifiers ([Part5]). After several such transfers, a cache
	might have received several ranges of the same representation. A		might have received several ranges of the same representation. A
	cache MAY combine these ranges into a single stored response, and		cache MAY combine these ranges into a single stored response, and
	skipping to change at page 19, line 23		skipping to change at page 20, line 29
	o delete any Warning header fields in the stored response with warn-		o delete any Warning header fields in the stored response with warn-
	code 1xx (see Section 3.6);		code 1xx (see Section 3.6);
	o retain any Warning header fields in the stored response with warn-		o retain any Warning header fields in the stored response with warn-
	code 2xx; and,		code 2xx; and,
	o use other header fields provided in the new response, aside from		o use other header fields provided in the new response, aside from
	Content-Range, to replace all instances of the corresponding		Content-Range, to replace all instances of the corresponding
	header fields in the stored response.		header fields in the stored response.
	2.9. Freshening Responses
	When a cache receives a 304 (Not Modified) response and already has
	one or more stored 200 (OK) responses for the same cache key, the
	cache needs to identify which of the stored responses are updated by
	this new response and then update the stored response(s) with the new
	information provided in the 304 response.
	o If the new response contains a strong validator, then that strong
	validator identifies the selected representation. All of the
	stored responses with the same strong validator are selected. If
	none of the stored responses contain the same strong validator,
	then this new response corresponds to a new selected
	representation and MUST NOT update the existing stored responses.
	o If the new response contains a weak validator and that validator
	corresponds to one of the cache's stored responses, then the most
	recent of those matching stored responses is selected.
	o If the new response does not include any form of validator, there
	is only one stored response, and that stored response also lacks a
	validator, then that stored response is selected.
	If a stored response is selected for update, the cache MUST:
	o delete any Warning header fields in the stored response with warn-
	code 1xx (see Section 3.6);
	o retain any Warning header fields in the stored response with warn-
	code 2xx; and,
	o use other header fields provided in the 304 response to replace
	all instances of the corresponding header fields in the stored
	response.
	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.
	3.1. Age		3.1. Age
	The "Age" header field conveys the sender's estimate of the amount of		The "Age" header field conveys the sender's estimate of the amount of
	time since the response was generated or successfully validated at		time since the response was generated or successfully validated at
	the origin server. Age values are calculated as specified in		the origin server. Age values are calculated as specified in
	skipping to change at page 21, line 5		skipping to change at page 21, line 25
	Note: HTTP/1.0 caches might not implement Cache-Control and might		Note: HTTP/1.0 caches might not implement Cache-Control and might
	only implement Pragma: no-cache (see Section 3.4).		only implement Pragma: no-cache (see Section 3.4).
	A proxy, whether or not it implements a cache, MUST pass cache		A proxy, whether or not it implements a cache, MUST pass cache
	directives through in forwarded messages, regardless of their		directives through in forwarded messages, regardless of their
	significance to that application, since the directives might be		significance to that application, since the directives might be
	applicable to all recipients along the request/response chain. It is		applicable to all recipients along the request/response chain. It is
	not possible to target a directive to a specific cache.		not possible to target a directive to a specific cache.
			Cache directives are identified by a token, to be compared case-
			insensitively, and have an optional argument.
	Cache-Control = 1#cache-directive		Cache-Control = 1#cache-directive
	cache-directive = cache-request-directive		cache-directive = cache-request-directive
	/ cache-response-directive		/ cache-response-directive
	cache-extension = token [ "=" ( token / quoted-string ) ]		cache-extension = token [ "=" ( token / quoted-string ) ]
	3.2.1. Request Cache-Control Directives		3.2.1. Request Cache-Control Directives
	cache-request-directive =		cache-request-directive =
	skipping to change at page 24, line 48		skipping to change at page 25, line 18
	become stale, a cache MUST NOT use the response to satisfy		become stale, a cache MUST NOT use the response to satisfy
	subsequent requests without successful validation on the origin		subsequent requests without successful validation on the origin
	server.		server.
	The must-revalidate directive is necessary to support reliable		The must-revalidate directive is necessary to support reliable
	operation for certain protocol features. In all circumstances a		operation for certain protocol features. In all circumstances a
	cache MUST obey the must-revalidate directive; in particular, if a		cache MUST obey the must-revalidate directive; in particular, if a
	cache cannot reach the origin server for any reason, it MUST		cache cannot reach the origin server for any reason, it MUST
	generate a 504 (Gateway Timeout) response.		generate a 504 (Gateway Timeout) response.
	A server SHOULD send the must-revalidate directive if and only if		The must-revalidate directive ought to be used by servers if and
	failure to validate a request on the representation could result		only if failure to validate a request on the representation could
	in incorrect operation, such as a silently unexecuted financial		result in incorrect operation, such as a silently unexecuted
	transaction.		financial transaction.
	proxy-revalidate		proxy-revalidate
	The proxy-revalidate response directive has the same meaning as		The proxy-revalidate response directive has the same meaning as
	the must-revalidate response directive, except that it does not		the must-revalidate response directive, except that it does not
	apply to private caches.		apply to private caches.
	max-age		max-age
	The max-age response directive indicates that the response is to		The max-age response directive indicates that the response is to
	skipping to change at page 26, line 52		skipping to change at page 27, line 26
	The "Expires" header field gives the date/time after which the		The "Expires" header field gives the date/time after which the
	response is considered stale. See Section 2.3 for further discussion		response is considered stale. See Section 2.3 for further discussion
	of the freshness model.		of the freshness model.
	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 6.1 of [Part1]; a sender MUST use the rfc1123-date format.		in Section 8 of [Part2]; a sender MUST use the rfc1123-date format.
	Expires = HTTP-date		Expires = HTTP-date
	For example		For example
	Expires: Thu, 01 Dec 1994 16:00:00 GMT		Expires: Thu, 01 Dec 1994 16:00:00 GMT
	A cache MUST treat other invalid date formats, especially including		A cache MUST treat other invalid date formats, especially including
	the value "0", as in the past (i.e., "already expired").		the value "0", as in the past (i.e., "already expired").
	skipping to change at page 27, line 26		skipping to change at page 27, line 49
	Expires field. Likewise, the s-maxage directive overrides Expires		Expires field. Likewise, the s-maxage directive overrides Expires
	in shared caches.		in shared caches.
	Historically, HTTP required the Expires field-value to be no more		Historically, HTTP required the Expires field-value to be no more
	than a year in the future. While longer freshness lifetimes are no		than a year in the future. While longer freshness lifetimes are no
	longer prohibited, extremely large values have been demonstrated to		longer prohibited, extremely large values have been demonstrated to
	cause problems (e.g., clock overflows due to use of 32-bit integers		cause problems (e.g., clock overflows due to use of 32-bit integers
	for time values), and most caches will evict a response far sooner		for time values), and most caches will evict a response far sooner
	than that. Therefore, senders ought not produce them.		than that. Therefore, senders ought not produce them.
			An origin server without a clock MUST NOT assign Expires values to a
			response unless these values were associated with the resource by a
			system or user with a reliable clock. It MAY assign an Expires value
			that is known, at or before server configuration time, to be in the
			past (this allows "pre-expiration" of responses without storing
			separate Expires values for each resource).
	3.4. Pragma		3.4. Pragma
	The "Pragma" header field allows backwards compatibility with		The "Pragma" header field allows backwards compatibility with
	HTTP/1.0 caches, so that clients can specify a "no-cache" request		HTTP/1.0 caches, so that clients can specify a "no-cache" request
	that they will understand (as Cache-Control was not defined until		that they will understand (as Cache-Control was not defined until
	HTTP/1.1). When the Cache-Control header is also present and		HTTP/1.1). When the Cache-Control header is also present and
	understood in a request, Pragma is ignored.		understood in a request, Pragma is ignored.
	In HTTP/1.0, Pragma was defined as an extensible field for		In HTTP/1.0, Pragma was defined as an extensible field for
	implementation-specified directives for recipients. This		implementation-specified directives for recipients. This
	specification deprecates such extensions to improve interoperability.		specification deprecates such extensions to improve interoperability.
	Pragma = 1#pragma-directive		Pragma = 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 ) ]
	When the Cache-Control header is not present in a request, the no-		When the Cache-Control header is not present in a request, the no-
	cache request pragma-directive MUST have the same effect on caches as		cache request pragma-directive MUST have the same effect on caches as
	if "Cache-Control: no-cache" were present (see Section 3.2.1).		if "Cache-Control: no-cache" were present (see Section 3.2.1).
	When sending a no-cache request, a client SHOULD include both pragma		When sending a no-cache request, a client ought to include both the
	and cache-control directives unless Cache-Control: no-cache is		pragma and cache-control directives, unless Cache-Control: no-cache
	purposefully omitted to target other Cache-Control response		is purposefully omitted to target other Cache-Control response
	directives at HTTP/1.1 caches. For example:		directives at HTTP/1.1 caches. For example:
	GET / HTTP/1.1		GET / HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Cache-Control: max-age=30		Cache-Control: max-age=30
	Pragma: no-cache		Pragma: no-cache
	will constrain HTTP/1.1 caches to serve a response no older than 30		will constrain HTTP/1.1 caches to serve a response no older than 30
	seconds, while precluding implementations that do not understand		seconds, while precluding implementations that do not understand
	Cache-Control from serving a cached response.		Cache-Control from serving a cached response.
	skipping to change at page 29, line 45		skipping to change at page 30, line 25
	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, only differing in warn-text.		number, only differing in warn-text.
	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.		them as possible, in the order that they appear in the response.
	Systems that generate multiple Warning header fields SHOULD order		Systems that generate multiple Warning header fields are encouraged
	them with this user agent behavior in mind. New Warning header		to order them with this user agent behavior in mind. New Warning
	fields SHOULD be added after any existing Warning headers fields.		header fields are added after any existing Warning headers fields.
	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 describe the freshness or validation status of the		o 1xx Warnings describe the freshness or validation status of the
	response, and so MUST be deleted by a cache after validation.		response, and so MUST be deleted by a cache after validation.
	They can only be generated by a cache when validating a cached		They can only be generated by a cache when validating a cached
	entry, and MUST NOT be generated in any other situation.		entry, and MUST NOT be generated in any other situation.
	skipping to change at page 30, line 45		skipping to change at page 31, line 25
	stale.		stale.
	111 Revalidation failed		111 Revalidation failed
	A cache SHOULD include this when returning a stale response		A cache SHOULD include this when returning a stale response
	because an attempt to validate the response failed, due to an		because an attempt to validate the response failed, due to an
	inability to reach the server.		inability to reach the server.
	112 Disconnected operation		112 Disconnected operation
	A cache SHOULD b include this if it is intentionally disconnected		A cache SHOULD include this if it is intentionally disconnected
	from the rest of the network for a period of time.		from the rest of the network for a period of time.
	113 Heuristic expiration		113 Heuristic expiration
	A cache SHOULD include this if it heuristically chose a freshness		A cache SHOULD include this if it heuristically chose a freshness
	lifetime greater than 24 hours and the response's age is greater		lifetime greater than 24 hours and the response's age is greater
	than 24 hours.		than 24 hours.
	199 Miscellaneous warning		199 Miscellaneous warning
	skipping to change at page 33, line 7		skipping to change at page 33, line 37
	Caches expose additional potential vulnerabilities, since the		Caches expose additional potential vulnerabilities, since the
	contents of the cache represent an attractive target for malicious		contents of the cache represent an attractive target for malicious
	exploitation. Because cache contents persist after an HTTP request		exploitation. Because cache contents persist after an HTTP request
	is complete, an attack on the cache can reveal information long after		is complete, an attack on the cache can reveal information long after
	a user believes that the information has been removed from the		a user believes that the information has been removed from the
	network. Therefore, cache contents need to be protected as sensitive		network. Therefore, cache contents need to be protected as sensitive
	information.		information.
	7. Acknowledgments		7. Acknowledgments
	See Section 12 of [Part1].		See Section 11 of [Part1].
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-16		and Message Parsing", draft-ietf-httpbis-p1-messaging-17
	(work in progress), August 2011.		(work in progress), October 2011.
	[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-16 (work in		Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
	progress), August 2011.		progress), October 2011.
	[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-16 (work in		Requests", draft-ietf-httpbis-p4-conditional-17 (work in
	progress), August 2011.		progress), October 2011.
	[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-16 (work		Partial Responses", draft-ietf-httpbis-p5-range-17 (work
	in progress), August 2011.		in progress), October 2011.
	[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-16 (work in progress),		draft-ietf-httpbis-p7-auth-17 (work in progress),
	August 2011.		October 2011.
	[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 34, line 48		skipping to change at page 35, line 33
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	Age = delta-seconds		Age = delta-seconds
	Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS		Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
	cache-directive ] )		cache-directive ] )
	Expires = HTTP-date		Expires = HTTP-date
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS		Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
	pragma-directive ] )		pragma-directive ] )
	Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]		Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
	) )		) )
	Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]		Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
	)		)
	cache-directive = cache-request-directive / cache-response-directive		cache-directive = cache-request-directive / cache-response-directive
	skipping to change at page 35, line 34		skipping to change at page 36, line 20
	) / ( "s-maxage=" delta-seconds ) / cache-extension		) / ( "s-maxage=" delta-seconds ) / cache-extension
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	extension-pragma = token [ "=" ( token / quoted-string ) ]		extension-pragma = token [ "=" ( token / quoted-string ) ]
	field-name = <field-name, defined in [Part1], Section 3.2>		field-name = <field-name, defined in [Part1], Section 3.2>
	port = <port, defined in [Part1], Section 2.7>		port = <port, defined in [Part1], Section 2.7>
	pragma-directive = "no-cache" / extension-pragma		pragma-directive = "no-cache" / extension-pragma
	pseudonym = <pseudonym, defined in [Part1], Section 9.9>		pseudonym = <pseudonym, defined in [Part1], Section 8.8>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.3>
	uri-host = <uri-host, defined in [Part1], Section 2.7>		uri-host = <uri-host, defined in [Part1], Section 2.7>
	warn-agent = ( uri-host [ ":" port ] ) / pseudonym		warn-agent = ( uri-host [ ":" port ] ) / pseudonym
	warn-code = 3DIGIT		warn-code = 3DIGIT
	warn-date = DQUOTE HTTP-date DQUOTE		warn-date = DQUOTE HTTP-date DQUOTE
	skipping to change at page 41, line 25		skipping to change at page 42, line 12
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma"		o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma"
	C.17. Since draft-ietf-httpbis-p6-cache-15		C.17. Since draft-ietf-httpbis-p6-cache-15
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one-		o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one-
	year limit for Expires"		year limit for Expires"
			C.18. Since draft-ietf-httpbis-p6-cache-16
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
			HTTP's error-handling philosophy"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/317>: "Cache-Control
			directive case sensitivity"
	Index		Index
	A		A
	age 6		age 6
	Age header field 20		Age header field 20
	C		C
	cache 5		cache 5
	Cache Directives		Cache Directives
	max-age 21, 25		max-age 22, 25
	max-stale 22		max-stale 22
	min-fresh 22		min-fresh 22
	must-revalidate 24		must-revalidate 25
	no-cache 21, 23		no-cache 21, 24
	no-store 21, 24		no-store 22, 24
	no-transform 22, 25		no-transform 23, 25
	only-if-cached 22		only-if-cached 23
	private 23		private 23
	proxy-revalidate 25		proxy-revalidate 25
	public 23		public 23
	s-maxage 25		s-maxage 25
	cache entry 8		cache entry 8
	cache key 8		cache key 8
	Cache-Control header field 20		Cache-Control header field 21
	cacheable 5		cacheable 5
	E		E
	Expires header field 26		Expires header field 27
	explicit expiration time 6		explicit expiration time 6
	F		F
	first-hand 6		first-hand 6
	fresh 6		fresh 6
	freshness lifetime 6		freshness lifetime 6
	G		G
	Grammar		Grammar
	Age 20		Age 20
	Cache-Control 21		Cache-Control 21
	cache-extension 21		cache-extension 21
	cache-request-directive 21		cache-request-directive 21
	cache-response-directive 23		cache-response-directive 23
	delta-seconds 8		delta-seconds 8
	Expires 27		Expires 27
	extension-pragma 27		extension-pragma 28
	Pragma 27		Pragma 28
	pragma-directive 27		pragma-directive 28
	Vary 28		Vary 29
	warn-agent 29		warn-agent 30
	warn-code 29		warn-code 30
	warn-date 29		warn-date 30
	warn-text 29		warn-text 30
	Warning 29		Warning 30
	warning-value 29		warning-value 30
	H		H
	Header Fields		Header Fields
	Age 20		Age 20
	Cache-Control 20		Cache-Control 21
	Expires 26		Expires 27
	Pragma 27		Pragma 28
	Vary 28		Vary 28
	Warning 29		Warning 29
	heuristic expiration time 6		heuristic expiration time 6
	M		M
	max-age		max-age
	Cache Directive 21, 25		Cache Directive 22, 25
	max-stale		max-stale
	Cache Directive 22		Cache Directive 22
	min-fresh		min-fresh
	Cache Directive 22		Cache Directive 22
	must-revalidate		must-revalidate
	Cache Directive 24		Cache Directive 25
	N		N
	no-cache		no-cache
	Cache Directive 21, 23
	no-store
	Cache Directive 21, 24		Cache Directive 21, 24
			no-store
			Cache Directive 22, 24
	no-transform		no-transform
	Cache Directive 22, 25		Cache Directive 23, 25
	O		O
	only-if-cached		only-if-cached
	Cache Directive 22		Cache Directive 23
	P		P
	Pragma header field 27		Pragma header field 28
	private		private
	Cache Directive 23		Cache Directive 23
	private cache 5		private cache 5
	proxy-revalidate		proxy-revalidate
	Cache Directive 25		Cache Directive 25
	public		public
	Cache Directive 23		Cache Directive 23
	S		S
	s-maxage		s-maxage
	skipping to change at page 45, line 26		skipping to change at page 46, line 26
	World Wide Web Consortium		World Wide Web Consortium
	W3C / ERCIM		W3C / ERCIM
	2004, rte des Lucioles		2004, rte des Lucioles
	Sophia-Antipolis, AM 06902		Sophia-Antipolis, AM 06902
	France		France
	EMail: ylafon@w3.org		EMail: ylafon@w3.org
	URI: http://www.raubacapeu.net/people/yves/		URI: http://www.raubacapeu.net/people/yves/
	Mark Nottingham (editor)		Mark Nottingham (editor)
			Rackspace
	EMail: mnot@mnot.net		EMail: mnot@mnot.net
	URI: http://www.mnot.net/		URI: http://www.mnot.net/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
End of changes. 73 change blocks.
	171 lines changed or deleted		212 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/