< draft-ietf-httpbis-p6-cache-19.txt		draft-ietf-httpbis-p6-cache-20.txt >
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) Y. Lafon, Ed.		Obsoletes: 2616 (if approved) Y. Lafon, Ed.
	Intended status: Standards Track W3C		Intended status: Standards Track W3C
	Expires: September 13, 2012 M. Nottingham, Ed.		Expires: January 17, 2013 M. Nottingham, Ed.
	Rackspace		Rackspace
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 12, 2012		July 16, 2012
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-19		draft-ietf-httpbis-p6-cache-20
	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. This document defines requirements on HTTP caches and the
	information initiative since 1990. This document is Part 6 of the		associated header fields that control cache behavior or indicate
	seven-part specification that defines the protocol referred to as		cacheable response messages.
	"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	Part 6 defines requirements on HTTP caches and the associated header
	fields that control cache behavior or indicate cacheable response
	messages.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft takes place on the HTTPBIS working group
	group mailing list (ietf-http-wg@w3.org), which is archived at		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.20.		The changes in this draft are summarized in Appendix D.1.
	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 September 13, 2012.		This Internet-Draft will expire on January 17, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 37 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7		1.3. Conformance and Error Handling . . . . . . . . . . . . . . 6
	1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7		1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
	1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8		1.4.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 7
	1.4.2. ABNF Rules defined in other Parts of the		2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 7
	Specification . . . . . . . . . . . . . . . . . . . . 8		3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 8
	1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 9
	2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Storing Responses to Authenticated Requests . . . . . . . 9
	2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9		4. Constructing Responses from Caches . . . . . . . . . . . . . . 10
	2.2. Constructing Responses from Caches . . . . . . . . . . . . 10		4.1. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11
	2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 12		4.1.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12
	2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 13		4.1.2. Calculating Heuristic Freshness . . . . . . . . . . . 12
	2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 14		4.1.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13
	2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 16		4.1.4. Serving Stale Responses . . . . . . . . . . . . . . . 15
	2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16		4.2. Validation Model . . . . . . . . . . . . . . . . . . . . . 16
	2.4.1. Freshening Responses with 304 Not Modified . . . . . . 17		4.2.1. Freshening Responses with 304 Not Modified . . . . . . 16
	2.5. Updating Caches with HEAD Responses . . . . . . . . . . . 18		4.3. Using Negotiated Responses . . . . . . . . . . . . . . . . 17
	2.6. Request Methods that Invalidate . . . . . . . . . . . . . 18		4.4. Combining Partial Content . . . . . . . . . . . . . . . . 18
	2.7. Shared Caching of Authenticated Responses . . . . . . . . 19		5. Updating Caches with HEAD Responses . . . . . . . . . . . . . 19
	2.8. Caching Negotiated Responses . . . . . . . . . . . . . . . 19		6. Request Methods that Invalidate . . . . . . . . . . . . . . . 19
	2.9. Combining Partial Content . . . . . . . . . . . . . . . . 20		7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
	3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 21		7.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		7.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20
	3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21		7.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
	3.2.1. Request Cache-Control Directives . . . . . . . . . . . 22		7.2.2. Response Cache-Control Directives . . . . . . . . . . 23
	3.2.2. Response Cache-Control Directives . . . . . . . . . . 24		7.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
	3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26		7.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 28
	3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27		7.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28		7.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 29		7.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30
	3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30		7.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31
	3.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31		7.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 32
	3.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 31		7.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 32
	3.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 31		7.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 32
	3.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 32		7.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 32
	3.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 32		7.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 32
	3.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 32		7.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 32
	3.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 32		7.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32
	3.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32		8. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 33
	4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		9.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 33
	5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 33		9.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 34
	5.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33		9.3. Header Field Registration . . . . . . . . . . . . . . . . 34
	5.3. Header Field Registration . . . . . . . . . . . . . . . . 34		10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 34		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		12.1. Normative References . . . . . . . . . . . . . . . . . . . 35
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 35		12.2. Informative References . . . . . . . . . . . . . . . . . . 36
	8.2. Informative References . . . . . . . . . . . . . . . . . . 35
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 36		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 37
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38
	publication) . . . . . . . . . . . . . . . . . . . . 37		Appendix D. Change Log (to be removed by RFC Editor before
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 38		publication) . . . . . . . . . . . . . . . . . . . . 39
	C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 38		D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 39
	C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 38		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 39
	C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 39
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 39
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 39
	C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 40
	C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 40
	C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 40
	C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 41
	C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 41
	C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 42
	C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 42
	C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 42
	C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 42
	C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 43
	C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 43
	C.19. Since draft-ietf-httpbis-p6-cache-17 . . . . . . . . . . . 43
	C.20. Since draft-ietf-httpbis-p6-cache-18 . . . . . . . . . . . 43
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	HTTP is typically used for distributed information systems, where		HTTP is typically used for distributed information systems, where
	performance can be improved by the use of response caches. This		performance can be improved by the use of response caches. This
	document defines aspects of HTTP/1.1 related to caching and reusing		document defines aspects of HTTP/1.1 related to caching and reusing
	response messages.		response messages.
	1.1. Purpose		1.1. Purpose
	An HTTP cache is a local store of response messages and the subsystem		An HTTP cache is a local store of response messages and the subsystem
	that controls its message storage, retrieval, and deletion. A cache		that controls its message storage, retrieval, and deletion. A cache
	stores cacheable responses in order to reduce the response time and		stores cacheable responses in order to reduce the response time and
	network bandwidth consumption on future, equivalent requests. Any		network bandwidth consumption on future, equivalent requests. Any
	client or server MAY employ a cache, though a cache cannot be used by		client or server MAY employ a cache, though a cache cannot be used by
	a server that is acting as a tunnel.		a server that is acting as a tunnel.
	The goal of caching in HTTP/1.1 is to significantly improve		The goal of caching in HTTP/1.1 is to significantly improve
	performance by reusing a prior response message to satisfy a current		performance by reusing a prior response message to satisfy a current
	request. A stored response is considered "fresh", as defined in		request. A stored response is considered "fresh", as defined in
	Section 2.3, if the response can be reused without "validation"		Section 4.1, if the response can be reused without "validation"
	(checking with the origin server to see if the cached response		(checking with the origin server to see if the cached response
	remains valid for this request). A fresh cache response can		remains valid for this request). A fresh cache response can
	therefore reduce both latency and network transfers each time it is		therefore reduce both latency and network transfers each time it is
	reused. When a cached response is not fresh, it might still be		reused. When a cached response is not fresh, it might still be
	reusable if it can be freshened by validation (Section 2.4) or if the		reusable if it can be freshened by validation (Section 4.2) or if the
	origin is unavailable.		origin is unavailable.
	1.2. Terminology		1.2. Terminology
	This specification uses a number of terms to refer to the roles		This specification uses a number of terms to refer to the roles
	played by participants in, and objects of, HTTP caching.		played by participants in, and objects of, HTTP caching.
	cache		cache
	A conformant implementation of a HTTP cache. Note that this		A conformant implementation of a HTTP cache. Note that this
	skipping to change at page 7, line 19 ¶		skipping to change at page 6, line 19 ¶
	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. Conformance and Error Handling		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].
	This document defines conformance criteria for several roles in HTTP		This specification targets conformance criteria according to the role
	communication, including Senders, Recipients, Clients, Servers, User-		of a participant in HTTP communication. Hence, HTTP requirements are
	Agents, Origin Servers, Intermediaries, Proxies and Gateways. See		placed on senders, recipients, clients, servers, user agents,
	Section 2 of [Part1] for definitions of these terms.		intermediaries, origin servers, proxies, gateways, or caches,
			depending on what behavior is being constrained by the requirement.
			See Section 2 of [Part1] for definitions of these terms.
			The verb "generate" is used instead of "send" where a requirement
			differentiates between creating a protocol element and merely
			forwarding a received element downstream.
	An implementation is considered conformant if it complies with all of		An implementation is considered conformant if it complies with all of
	the requirements associated with its role(s). Note that SHOULD-level		the requirements associated with the roles it partakes in HTTP. Note
	requirements are relevant here, unless one of the documented		that SHOULD-level requirements are relevant here, unless one of the
	exceptions is applicable.		documented exceptions is applicable.
	This document also uses ABNF to define valid protocol elements		This document also uses ABNF to define valid protocol elements
	(Section 1.4). In addition to the prose requirements placed upon		(Section 1.4). In addition to the prose requirements placed upon
	them, Senders MUST NOT generate protocol elements that are invalid.		them, senders MUST NOT generate protocol elements that do not match
			the grammar defined by the ABNF rules for those protocol elements
			that are applicable to the sender's role. If a received protocol
			element is processed, the recipient MUST be able to parse any value
			that would match the ABNF rules for that protocol element, excluding
			only those rules not applicable to the recipient's role.
	Unless noted otherwise, Recipients MAY take steps to recover a usable		Unless noted otherwise, a recipient MAY attempt to recover a usable
	protocol element from an invalid construct. However, HTTP does not		protocol element from an invalid construct. HTTP does not define
	define specific error handling mechanisms, except in cases where it		specific error handling mechanisms except when they have a direct
	has direct impact on security. This is because different uses of the		impact on security, since different applications of the protocol
	protocol require different error handling strategies; for example, a		require different error handling strategies. For example, a Web
	Web browser may wish to transparently recover from a response where		browser might wish to transparently recover from a response where the
	the Location header field doesn't parse according to the ABNF,		Location header field doesn't parse according to the ABNF, whereas a
	whereby in a systems control protocol using HTTP, this type of error		systems control client might consider any form of error recovery to
	recovery could lead to dangerous consequences.		be dangerous.
	1.4. Syntax Notation		1.4. Syntax Notation
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] with the list rule extension defined in Section		notation of [RFC5234] with the list rule extension defined in Section
	1.2 of [Part1]. Appendix B shows the collected ABNF with the list		1.2 of [Part1]. Appendix B describes rules imported from other
	rule expanded.		documents. Appendix C shows the collected ABNF with the list rule
			expanded.
	The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(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
	sequence of data), SP (space), and VCHAR (any visible US-ASCII
	character).
	1.4.1. Core Rules
	The core rules below are defined in [Part1]:
	OWS = <OWS, defined in [Part1], Section 3.2.1>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
	token = <token, defined in [Part1], Section 3.2.4>
	1.4.2. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:
	field-name = <field-name, defined in [Part1], Section 3.2>
	HTTP-date = <HTTP-date, defined in [Part2], Section 8>
	port = <port, defined in [Part1], Section 2.7>
	pseudonym = <pseudonym, defined in [Part1], Section 6.2>
	uri-host = <uri-host, defined in [Part1], Section 2.7>
	1.5. Delta Seconds		1.4.1. 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 MUST use		2147483648 (2^31). Recipients parsing a delta-seconds value MUST use
	an arithmetic type of at least 31 bits of range, and senders MUST NOT		an arithmetic type of at least 31 bits of range, and senders MUST NOT
	send delta-seconds with a value greater than 2147483648.		send delta-seconds with a value greater than 2147483648.
	2. Cache Operation		2. Overview of 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
	non-reusable response or reusing a stored response inappropriately.		non-reusable response or reusing a stored response inappropriately.
	Each cache entry consists of a cache key and one or more HTTP		Each cache entry consists of a cache key and one or more HTTP
	responses corresponding to prior requests that used the same key.		responses corresponding to prior requests that used the same key.
	The most common form of cache entry is a successful result of a		The most common form of cache entry is a successful result of a
	retrieval request: i.e., a 200 (OK) response containing a		retrieval request: i.e., a 200 (OK) response containing a
	representation of the resource identified by the request target.		representation of the resource identified by the request target.
	However, it is also possible to cache negative results (e.g., 404 not		However, it is also possible to cache negative results (e.g., 404
	found), incomplete results (e.g., 206 partial content), and responses		(Not Found), incomplete results (e.g., 206 (Partial Content)), and
	to safe methods other than GET if the method's definition allows such		responses to methods other than GET if the method's definition allows
	caching and defines something suitable for use as a cache key.		such caching and defines something suitable for use as a cache key.
	The default cache key consists of the request method and target URI.		The default cache key consists of the request method and target URI.
	However, since HTTP caches in common use today are typically limited		However, since HTTP caches in common use today are typically limited
	to caching responses to GET, most implementations simply decline		to caching responses to GET, many implementations simply decline
	other methods and use only the URI as the key.		other methods and use only the URI as the key.
	If a request target is subject to content negotiation, its cache		If a request target is subject to content negotiation, its cache
	entry might consist of multiple stored responses, each differentiated		entry might consist of multiple stored responses, each differentiated
	by a secondary key for the values of the original request's selecting		by a secondary key for the values of the original request's selecting
	header fields (Section 2.8).		header fields (Section 4.3).
	2.1. Response Cacheability		3. Storing Responses in Caches
	A cache MUST NOT store a response to any request, unless:		A cache MUST NOT store a response to any request, unless:
	o The request method is understood by the cache and defined as being		o The request method is understood by the cache and defined as being
	cacheable, and		cacheable, and
	o the response status code is understood by the cache, and		o the response status code is understood by the cache, and
	o the "no-store" cache directive (see Section 3.2) does not appear		o the "no-store" cache directive (see Section 7.2) does not appear
	in request or response header fields, and		in request or response header fields, and
	o the "private" cache response directive (see Section 3.2.2) does		o the "private" cache response directive (see Section 7.2.2.2) does
	not appear in the response, if the cache is shared, and		not appear in the response, if the cache is shared, and
	o the "Authorization" header field (see Section 4.1 of [Part7]) does		o the Authorization header field (see Section 4.1 of [Part7]) does
	not appear in the request, if the cache is shared, unless the		not appear in the request, if the cache is shared, unless the
	response explicitly allows it (see Section 2.7), and		response explicitly allows it (see Section 3.2), and
	o the response either:		o the response either:
	* contains an Expires header field (see Section 3.3), or		* contains an Expires header field (see Section 7.3), or
	* contains a max-age response cache directive (see		* contains a max-age response cache directive (see
	Section 3.2.2), or		Section 7.2.2.7), or
	* contains a s-maxage response cache directive and the cache is		* contains a s-maxage response cache directive and the cache is
	shared, or		shared, or
	* contains a Cache Control Extension (see Section 3.2.3) that		* contains a Cache Control Extension (see Section 7.2.3) that
	allows it to be cached, or		allows it to be cached, or
	* has a status code that can be served with heuristic freshness		* has a status code that can be served with heuristic freshness
	(see Section 2.3.1.1).		(see Section 4.1.2).
	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 7.2.3.
	In this context, a cache has "understood" a request method or a		In this context, a cache has "understood" a request method or a
	response status code if it recognizes it and implements any cache-		response status code if it recognizes it and implements any cache-
	specific behavior.		specific behavior.
	Note that, in normal operation, most caches will not store a response		Note that, in normal operation, many caches will not store a response
	that has neither a cache validator nor an explicit expiration time,		that has neither a cache validator nor an explicit expiration time,
	as such responses are not usually useful to store. However, caches		as such responses are not usually useful to store. However, caches
	are not prohibited from storing such responses.		are not prohibited from storing such responses.
			3.1. Storing Incomplete Responses
	A response message is considered complete when all of the octets		A response message is considered complete when all of the octets
	indicated by the message framing ([Part1]) are received prior to the		indicated by the message framing ([Part1]) are received prior to the
	connection being closed. If the request is GET, the response status		connection being closed. If the request is GET, the response status
	is 200 (OK), and the entire response header block has been received,		is 200 (OK), and the entire response header block has been received,
	a cache MAY store an incomplete response message body if the cache		a cache MAY store an incomplete response message body if the cache
	entry is recorded as incomplete. Likewise, a 206 (Partial Content)		entry is recorded as incomplete. Likewise, a 206 (Partial Content)
	response MAY be stored as if it were an incomplete 200 (OK) cache		response MAY be stored as if it were an incomplete 200 (OK) cache
	entry. However, a cache MUST NOT store incomplete or partial content		entry. However, a cache MUST NOT store incomplete or partial content
	responses if it does not support the Range and Content-Range header		responses if it does not support the Range and Content-Range header
	fields or if it does not understand the range units used in those		fields or if it does not understand the range units used in those
	fields.		fields.
	A cache MAY complete a stored incomplete response by making a		A cache MAY complete a stored incomplete response by making a
	subsequent range request ([Part5]) and combining the successful		subsequent range request ([Part5]) and combining the successful
	response with the stored entry, as defined in Section 2.9. A cache		response with the stored entry, as defined in Section 4.4. A cache
	MUST NOT use an incomplete response to answer requests unless the		MUST NOT use an incomplete response to answer requests unless the
	response has been made complete or the request is partial and		response has been made complete or the request is partial and
	specifies a range that is wholly within the incomplete response. A		specifies a range that is wholly within the incomplete response. A
	cache MUST NOT send a partial response to a client without explicitly		cache MUST NOT send a partial response to a client without explicitly
	marking it as such using the 206 (Partial Content) status code.		marking it as such using the 206 (Partial Content) status code.
	2.2. Constructing Responses from Caches		3.2. Storing Responses to Authenticated Requests
			A shared cache MUST NOT use a cached response to a request with an
			Authorization header field (Section 4.1 of [Part7]) to satisfy any
			subsequent request unless a cache directive that allows such
			responses to be stored is present in the response.
			In this specification, the following Cache-Control response
			directives (Section 7.2.2) have such an effect: must-revalidate,
			public, s-maxage.
			Note that cached responses that contain the "must-revalidate" and/or
			"s-maxage" response directives are not allowed to be served stale
			(Section 4.1.4) by shared caches. In particular, a response with
			either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to
			satisfy a subsequent request without revalidating it on the origin
			server.
			4. Constructing Responses from Caches
	For a presented request, a cache MUST NOT return a stored response,		For a presented request, a cache MUST NOT return a stored response,
	unless:		unless:
	o The presented effective request URI (Section 5.5 of [Part1]) and		o The presented effective request URI (Section 5.5 of [Part1]) and
	that of the stored response match, and		that of the stored response match, and
	o the request method associated with the stored response allows it		o the request method associated with the stored response allows it
	to be used for the presented request, and		to be used for the presented request, and
	o selecting header fields nominated by the stored response (if any)		o selecting header fields nominated by the stored response (if any)
	match those presented (see Section 2.8), and		match those presented (see Section 4.3), and
	o the presented request does not contain the no-cache pragma		o the presented request does not contain the no-cache pragma
	(Section 3.4), nor the no-cache cache directive (Section 3.2.1),		(Section 7.4), nor the no-cache cache directive (Section 7.2.1),
	unless the stored response is successfully validated		unless the stored response is successfully validated
	(Section 2.4), and		(Section 4.2), and
	o the stored response does not contain the no-cache cache directive		o the stored response does not contain the no-cache cache directive
	(Section 3.2.2), unless it is successfully validated		(Section 7.2.2.3), unless it is successfully validated
	(Section 2.4), and		(Section 4.2), and
	o the stored response is either:		o the stored response is either:
	* fresh (see Section 2.3), or		* fresh (see Section 4.1), or
	* allowed to be served stale (see Section 2.3.3), or		* allowed to be served stale (see Section 4.1.4), or
	* successfully validated (see Section 2.4).		* successfully validated (see Section 4.2).
	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 7.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 7.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 4.1.3.
	A cache MUST write through requests with methods that are unsafe		A cache MUST write through requests with methods that are unsafe
	(Section 6.1.1 of [Part2]) to the origin server; i.e., a cache must		(Section 2.1.1 of [Part2]) to the origin server; i.e., a cache is not
	not generate a reply to such a request before having forwarded the		allowed to generate a reply to such a request before having forwarded
	request and having received a corresponding response.		the 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.6.		responses; see Section 6.
	When more than one suitable response is stored, a cache MUST use the		When more than one suitable response is stored, a cache MUST use the
	most recent response (as determined by the Date header field). It		most recent response (as determined by the Date header field). It
	can also forward a request with "Cache-Control: max-age=0" or "Cache-		can also forward a request with "Cache-Control: max-age=0" or "Cache-
	Control: no-cache" to disambiguate which response to use.		Control: no-cache" to disambiguate which response to use.
	A cache that does not have a clock available MUST NOT use stored		A cache that does not have a clock available MUST NOT use stored
	responses without revalidating them on every use. A cache,		responses without revalidating them on every use. A cache,
	especially a shared cache, SHOULD use a mechanism, such as NTP		especially a shared cache, SHOULD use a mechanism, such as NTP
	[RFC1305], to synchronize its clock with a reliable external		[RFC1305], to synchronize its clock with a reliable external
	standard.		standard.
	2.3. Freshness Model		4.1. Freshness Model
	When a response is "fresh" in the cache, it can be used to satisfy		When a response is "fresh" in the cache, it can be used to satisfy
	subsequent requests without contacting the origin server, thereby		subsequent requests without contacting the origin server, thereby
	improving efficiency.		improving efficiency.
	The primary mechanism for determining freshness is for an origin		The primary mechanism for determining freshness is for an origin
	server to provide an explicit expiration time in the future, using		server to provide an explicit expiration time in the future, using
	either the Expires header field (Section 3.3) or the max-age response		either the Expires header field (Section 7.3) or the max-age response
	cache directive (Section 3.2.2). Generally, origin servers will		cache directive (Section 7.2.2.7). Generally, origin servers will
	assign future explicit expiration times to responses in the belief		assign future explicit expiration times to responses in the belief
	that the representation is not likely to change in a semantically		that the representation is not likely to change in a semantically
	significant way before the expiration time is reached.		significant way before the expiration time is reached.
	If an origin server wishes to force a cache to validate every		If an origin server wishes to force a cache to validate every
	request, it can assign an explicit expiration time in the past to		request, it can assign an explicit expiration time in the past to
	indicate that the response is already stale. Compliant caches will		indicate that the response is already stale. Compliant caches will
	normally validate the cached response before reusing it for		normally validate the cached response before reusing it for
	subsequent requests (see Section 2.3.3).		subsequent requests (see Section 4.1.4).
	Since origin servers do not always provide explicit expiration times,		Since origin servers do not always provide explicit expiration times,
	a cache MAY assign a heuristic expiration time when an explicit time		a cache MAY assign a heuristic expiration time when an explicit time
	is not specified, employing algorithms that use other header field		is not specified, employing algorithms that use other header field
	values (such as the Last-Modified time) to estimate a plausible		values (such as the Last-Modified time) to estimate a plausible
	expiration time. This specification does not provide specific		expiration time. This specification does not provide specific
	algorithms, but does impose worst-case constraints on their results.		algorithms, but does impose worst-case constraints on their results.
	The calculation to determine if a response is fresh is:		The calculation to determine if a response is fresh is:
	response_is_fresh = (freshness_lifetime > current_age)		response_is_fresh = (freshness_lifetime > current_age)
	The freshness_lifetime is defined in Section 2.3.1; the current_age		The freshness_lifetime is defined in Section 4.1.1; the current_age
	is defined in Section 2.3.2.		is defined in Section 4.1.3.
	Additionally, clients can influence freshness calculation -- either		Additionally, clients can influence freshness calculation -- either
	constraining it relaxing it -- by using the max-age and min-fresh		constraining it relaxing it -- by using the max-age and min-fresh
	request cache directives. See Section 3.2.1 for details.		request cache directives. See Section 7.2.1 for details.
	Note that freshness applies only to cache operation; it cannot be		Note that freshness applies only to cache operation; it cannot be
	used to force a user agent to refresh its display or reload a		used to force a user agent to refresh its display or reload a
	resource. See Section 4 for an explanation of the difference between		resource. See Section 8 for an explanation of the difference between
	caches and history mechanisms.		caches and history mechanisms.
	2.3.1. Calculating Freshness Lifetime		4.1.1. Calculating Freshness Lifetime
	A cache can calculate the freshness lifetime (denoted as		A cache can calculate the freshness lifetime (denoted as
	freshness_lifetime) of a response by using the first match of:		freshness_lifetime) of a response by using the first match of:
	o If the cache is shared and the s-maxage response cache directive		o If the cache is shared and the s-maxage response cache directive
	(Section 3.2.2) is present, use its value, or		(Section 7.2.2.8) is present, use its value, or
	o If the max-age response cache directive (Section 3.2.2) is		o If the max-age response cache directive (Section 7.2.2.7) is
	present, use its value, or		present, use its value, or
	o If the Expires response header field (Section 3.3) is present, use		o If the Expires response header field (Section 7.3) is present, use
	its value minus the value of the Date response header field, or		its value minus the value of the Date response header field, or
	o Otherwise, no explicit expiration time is present in the response.		o Otherwise, no explicit expiration time is present in the response.
	A heuristic freshness lifetime might be applicable; see		A heuristic freshness lifetime might be applicable; see
	Section 2.3.1.1.		Section 4.1.2.
	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		When there is more than one value present for a given directive
			(e.g., two Expires header fields, multiple Cache-Control: max-age
			directives), it is considered invalid. Caches are encouraged to
			consider responses that have invalid freshness information to be
			stale.
			4.1.2. 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 7 of [Part2]: 200, 203, 206,		used (including the following in Section 4 of [Part2]: 200 (OK), 203
	300, 301 and 410), a cache MAY calculate a heuristic expiration time.		(Non-Authoritative Information), 206 (Partial Content), 300 (Multiple
	A cache MUST NOT use heuristics to determine freshness for responses		Choices), 301 (Moved Permanently) and 410 (Gone)), a cache MAY
	with status codes that do not explicitly allow it.		calculate a heuristic expiration time. A cache MUST NOT use
			heuristics to determine freshness for responses 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]), caches are encouraged to use a heuristic expiration		of [Part4]), caches are encouraged to use a heuristic expiration
	value that is no more than some fraction of the interval since that		value that is no more than some fraction of the interval since that
	time. A 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: Section 13.9 of [RFC2616] prohibited caches from calculating
	not calculate heuristic freshness for URIs with query components		heuristic freshness for URIs with query components (i.e., those
	(i.e., those containing '?'). In practice, this has not been		containing '?'). In practice, this has not been widely
	widely implemented. Therefore, servers are encouraged to send		implemented. Therefore, servers are encouraged to send explicit
	explicit directives (e.g., Cache-Control: no-cache) if they wish		directives (e.g., Cache-Control: no-cache) if they wish to
	to preclude caching.		preclude caching.
	2.3.2. Calculating Age		4.1.3. Calculating Age
	HTTP/1.1 uses the Age header field to convey the estimated age of the		HTTP/1.1 uses the Age header field to convey the estimated age of the
	response message when obtained from a cache. The Age field value is		response message when obtained from a cache. The Age field value is
	the cache's estimate of the amount of time since the response was		the cache's estimate of the amount of time since the response was
	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 following data is used for the age calculation:		The following data is used for the age calculation:
	age_value		age_value
	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 7.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 10.2 of [Part2] for the definition of the		operations. See Section 9.10 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 24 ¶		skipping to change at page 14, line 36 ¶
	apparent_age = max(0, response_time - date_value);		apparent_age = max(0, response_time - date_value);
	response_delay = response_time - request_time;		response_delay = response_time - request_time;
	corrected_age_value = age_value + response_delay;		corrected_age_value = age_value + response_delay;
	These SHOULD be combined as		These SHOULD be combined as
	corrected_initial_age = max(apparent_age, corrected_age_value);		corrected_initial_age = max(apparent_age, corrected_age_value);
	unless the cache is confident in the value of the Age header (e.g.,		unless the cache is confident in the value of the Age header field
	because there are no HTTP/1.0 hops in the Via header), in which case		(e.g., because there are no HTTP/1.0 hops in the Via header field),
	the corrected_age_value MAY be used as the corrected_initial_age.		in which case the corrected_age_value MAY be used as the
			corrected_initial_age.
	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;
	Additionally, to avoid common problems in date parsing:		Additionally, to avoid common problems in date parsing:
	skipping to change at page 16, line 10 ¶		skipping to change at page 15, line 26 ¶
	proper value.		proper value.
	o All expiration-related calculations MUST be done in GMT. The		o All expiration-related calculations MUST be done in GMT. The
	local time zone MUST NOT influence the calculation or comparison		local time zone MUST NOT influence the calculation or comparison
	of an age or expiration time.		of an age or expiration time.
	o If an HTTP header field incorrectly carries a date value with a		o If an HTTP header field incorrectly carries a date value with a
	time zone other than GMT, it MUST be converted into GMT using the		time zone other than GMT, it MUST be converted into GMT using the
	most conservative possible conversion.		most conservative possible conversion.
	2.3.3. Serving Stale Responses		4.1.4. Serving Stale Responses
	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 4.1.
	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 7.2.2).
	A cache MUST 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 7.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 7.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 can forward it to the requesting client without adding a		the cache can forward it to the requesting client without adding a
	new Warning (but without removing any existing Warning header		new Warning (but without removing any existing Warning header
	fields). A cache shouldn't attempt to validate a response simply		fields). A cache shouldn't attempt to validate a response simply
	because that response became stale in transit.		because that response became stale in transit.
	2.4. Validation Model		4.2. 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.8), it can use the conditional		one cannot be selected; see Section 4.3), it can use the conditional
	request mechanism [Part4] in the forwarded request to give the origin		request mechanism [Part4] in the forwarded request to give the origin
	server an opportunity to both select a valid stored response to be		server an opportunity to both select a valid stored response to be
	used, and to update it. This process is known as "validating" or		used, and to update it. This process is known as "validating" or
	"revalidating" the stored response.		"revalidating" the stored response.
	When sending such a conditional request, a cache adds an If-Modified-		When sending such a conditional request, a cache adds an If-Modified-
	Since header field whose value is that of the Last-Modified header		Since header field whose value is that of the Last-Modified header
	field from the selected (see Section 2.8) stored response, if		field from the selected (see Section 4.3) stored response, if
	available.		available.
	Additionally, a cache can add an If-None-Match header field whose		Additionally, a cache can add an If-None-Match header field whose
	value is that of the ETag header field(s) from all responses stored		value is that of the ETag header field(s) from all responses stored
	for the requested URI, if present. However, if any of the stored		for the requested URI, if present. However, if any of the stored
	responses contains only partial content, the cache shouldn't include		responses contains only partial content, the cache shouldn't include
	its entity-tag in the If-None-Match header field unless the request		its entity-tag in the If-None-Match header field unless the request
	is for a range that would be fully satisfied by that stored response.		is for a range that would be fully satisfied by that stored response.
	Cache handling of a response to a conditional request is dependent		Cache handling of a response to a conditional request is dependent
	upon its status code:		upon its status code:
	o A 304 (Not Modified) response status code indicates that the		o A 304 (Not Modified) response status code indicates that the
	stored response can be updated and reused; see Section 2.4.1.		stored response can be updated and reused; see Section 4.2.1.
	o A full response (i.e., one with a response body) indicates that		o A full response (i.e., one with a response body) indicates that
	none of the stored responses nominated in the conditional request		none of the stored responses nominated in the conditional request
	is suitable. Instead, the cache can use the full response to		is suitable. Instead, the cache can use the full response to
	satisfy the request and MAY replace the stored response(s).		satisfy the request and MAY replace the stored response(s).
	o However, if a cache receives a 5xx response while attempting to		o However, if a cache receives a 5xx (Server Error) response while
	validate a response, it can either forward this response to the		attempting to validate a response, it can either forward this
	requesting client, or act as if the server failed to respond. In		response to the requesting client, or act as if the server failed
	the latter case, it can return a previously stored response (see		to respond. In the latter case, it can return a previously stored
	Section 2.3.3).		response (see Section 4.1.4).
	2.4.1. Freshening Responses with 304 Not Modified		4.2.1. Freshening Responses with 304 Not Modified
	When a cache receives a 304 (Not Modified) response and already has		When a cache receives a 304 (Not Modified) response and already has
	one or more stored 200 (OK) responses for the same cache key, the		one or more stored 200 (OK) responses for the same cache key, the
	cache needs to identify which of the stored responses are updated by		cache needs to identify which of the stored responses are updated by
	this new response and then update the stored response(s) with the new		this new response and then update the stored response(s) with the new
	information provided in the 304 response.		information provided in the 304 response.
	o If the new response contains a strong validator, then that strong		o If the new response contains a strong validator, then that strong
	validator identifies the selected representation. All of the		validator identifies the selected representation. All of the
	stored responses with the same strong validator are selected. If		stored responses with the same strong validator are selected. If
	skipping to change at page 18, line 8 ¶		skipping to change at page 17, line 23 ¶
	corresponds to one of the cache's stored responses, then the most		corresponds to one of the cache's stored responses, then the most
	recent of those matching stored responses is selected.		recent of those matching stored responses is selected.
	o If the new response does not include any form of validator, there		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		is only one stored response, and that stored response also lacks a
	validator, then that stored response is selected.		validator, then that stored response is selected.
	If a stored response is selected for update, the cache MUST:		If a stored response is selected for update, the cache MUST:
	o delete any Warning header fields in the stored response with warn-		o delete any Warning header fields in the stored response with warn-
	code 1xx (see Section 3.6);		code 1xx (see Section 7.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. Updating Caches with HEAD Responses
	A response to the HEAD method is identical to what an equivalent
	request made with a GET would have been, except it lacks a body.
	This property of HEAD responses is used to both invalidate and update
	cached GET responses.
	If one or more stored GET responses can be selected (as per
	Section 2.8) for a HEAD request, and the Content-Length, ETag or
	Last-Modified value of a HEAD response differs from that in a
	selected GET response, the cache MUST consider that selected response
	to be stale.
	If the Content-Length, ETag and Last-Modified values of a HEAD
	response (when present) are the same as that in a selected GET
	response (as per Section 2.8), the cache SHOULD update the remaining
	headers in the stored response using the following rules:
	o delete any Warning header fields in the stored response with warn-
	code 1xx (see Section 3.6);
	o retain any Warning header fields in the stored response with warn-		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 response to replace all		o use other header fields provided in the 304 (Not Modified)
	instances of the corresponding header fields in the stored		response to replace all instances of the corresponding header
	response.		fields in the stored response.
	2.6. Request Methods that Invalidate
	Because unsafe request methods (Section 6.1.1 of [Part2]) such as
	PUT, POST or DELETE have the potential for changing state on the
	origin server, intervening caches can use them to keep their contents
	up-to-date.
	A cache MUST invalidate the effective Request URI (Section 5.5 of
	[Part1]) as well as the URI(s) in the Location and Content-Location
	response header fields (if present) when a non-error response to a
	request with an unsafe method is received.
	However, a cache MUST NOT invalidate a URI from a Location or
	Content-Location response header field if the host part of that URI
	differs from the host part in the effective request URI (Section 5.5
	of [Part1]). This helps prevent denial of service attacks.
	A cache MUST invalidate the effective request URI (Section 5.5 of
	[Part1]) when it receives a non-error response to a request with a
	method whose safety is unknown.
	Here, a "non-error response" is one with a 2xx or 3xx status code.
	"Invalidate" means that the cache will either remove all stored
	responses related to the effective request URI, or will mark these as
	"invalid" and in need of a mandatory validation before they can be
	returned in response to a subsequent request.
	Note that this does not guarantee that all appropriate responses are
	invalidated. For example, the request that caused the change at the
	origin server might not have gone through the cache where a response
	is stored.
	2.7. Shared Caching of Authenticated Responses
	A shared cache MUST NOT use a cached response to a request with an
	Authorization header field (Section 4.1 of [Part7]) to satisfy any
	subsequent request unless a cache directive that allows such
	responses to be stored is present in the response.
	In this specification, the following Cache-Control response
	directives (Section 3.2.2) have such an effect: must-revalidate,
	public, s-maxage.
	Note that cached responses that contain the "must-revalidate" and/or
	"s-maxage" response directives are not allowed to be served stale
	(Section 2.3.3) by shared caches. In particular, a response with
	either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to
	satisfy a subsequent request without revalidating it on the origin
	server.
	2.8. Caching Negotiated Responses		4.3. Using 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 7.5), it MUST NOT use
	that response unless all of the selecting header fields nominated by		that response unless all of the selecting header fields nominated by
	the Vary header field match in both the original request (i.e., that		the Vary header field match in both the original request (i.e., that
	associated with the stored response), and the presented request.		associated with the stored response), and the presented request.
	The selecting header fields from two requests are defined to match if		The selecting header fields from two requests are defined to match if
	and only if those in the first request can be transformed to those in		and only if those in the first request can be transformed to those in
	the second request by applying any of the following:		the second request by applying any of the following:
	o adding or removing whitespace, where allowed in the header field's		o adding or removing whitespace, where allowed in the header field's
	syntax		syntax
	skipping to change at page 20, line 35 ¶		skipping to change at page 18, line 20 ¶
	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 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 4.
	If no selected response is available, the cache can forward the		If no selected response is available, the cache can forward the
	presented request to the origin server in a conditional request; see		presented request to the origin server in a conditional request; see
	Section 2.4.		Section 4.2.
	2.9. Combining Partial Content		4.4. Combining Partial Content
	A response might transfer only a partial representation if the		A response might transfer only a partial representation if the
	connection closed prematurely or if the request used one or more		connection closed prematurely or if the request used one or more
	Range specifiers ([Part5]). After several such transfers, a cache		Range specifiers ([Part5]). After several such transfers, a cache
	might have received several ranges of the same representation. A		might have received several ranges of the same representation. A
	cache MAY combine these ranges into a single stored response, and		cache MAY combine these ranges into a single stored response, and
	reuse that response to satisfy later requests, if they all share the		reuse that response to satisfy later requests, if they all share the
	same strong validator and the cache complies with the client		same strong validator and the cache complies with the client
	requirements in Section 4.2 of [Part5].		requirements in Section 4.2 of [Part5].
	When combining the new response with one or more stored responses, a		When combining the new response with one or more stored responses, a
	cache MUST:		cache MUST:
	o delete any Warning header fields in the stored response with warn-		o delete any Warning header fields in the stored response with warn-
	code 1xx (see Section 3.6);		code 1xx (see Section 7.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.
	3. Header Field Definitions		5. Updating Caches with HEAD Responses
			A response to the HEAD method is identical to what an equivalent
			request made with a GET would have been, except it lacks a body.
			This property of HEAD responses is used to both invalidate and update
			cached GET responses.
			If one or more stored GET responses can be selected (as per
			Section 4.3) for a HEAD request, and the Content-Length, ETag or
			Last-Modified value of a HEAD response differs from that in a
			selected GET response, the cache MUST consider that selected response
			to be stale.
			If the Content-Length, ETag and Last-Modified values of a HEAD
			response (when present) are the same as that in a selected GET
			response (as per Section 4.3), the cache SHOULD update the remaining
			header fields in the stored response using the following rules:
			o delete any Warning header fields in the stored response with warn-
			code 1xx (see Section 7.6);
			o retain any Warning header fields in the stored response with warn-
			code 2xx; and,
			o use other header fields provided in the response to replace all
			instances of the corresponding header fields in the stored
			response.
			6. Request Methods that Invalidate
			Because unsafe request methods (Section 2.1.1 of [Part2]) such as
			PUT, POST or DELETE have the potential for changing state on the
			origin server, intervening caches can use them to keep their contents
			up-to-date.
			A cache MUST invalidate the effective Request URI (Section 5.5 of
			[Part1]) as well as the URI(s) in the Location and Content-Location
			response header fields (if present) when a non-error response to a
			request with an unsafe method is received.
			However, a cache MUST NOT invalidate a URI from a Location or
			Content-Location response header field if the host part of that URI
			differs from the host part in the effective request URI (Section 5.5
			of [Part1]). This helps prevent denial of service attacks.
			A cache MUST invalidate the effective request URI (Section 5.5 of
			[Part1]) when it receives a non-error response to a request with a
			method whose safety is unknown.
			Here, a "non-error response" is one with a 2xx (Successful) or 3xx
			(Redirection) status code. "Invalidate" means that the cache will
			either remove all stored responses related to the effective request
			URI, or will mark these as "invalid" and in need of a mandatory
			validation before they can be returned in response to a subsequent
			request.
			Note that this does not guarantee that all appropriate responses are
			invalidated. For example, the request that caused the change at the
			origin server might not have gone through the cache where a response
			is stored.
			7. 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		7.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
	Section 2.3.2.		Section 4.1.3.
	Age = delta-seconds		Age = delta-seconds
	Age field-values are non-negative integers, representing time in		Age field-values are non-negative integers, representing time in
	seconds (see Section 1.5).		seconds (see Section 1.4.1).
	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 might not implement the Age header field.		HTTP/1.0 caches might not implement the Age header field.
	3.2. Cache-Control		7.2. Cache-Control
	The "Cache-Control" header field is used to specify directives for		The "Cache-Control" header field is used to specify directives for
	caches along the request/response chain. Such cache directives are		caches along the request/response chain. Such cache directives are
	unidirectional in that the presence of a directive in a request does		unidirectional in that the presence of a directive in a request does
	not imply that the same directive is to be given in the response.		not imply that the same directive is to be given in the response.
	A cache MUST obey the requirements of the Cache-Control directives		A cache MUST obey the requirements of the Cache-Control directives
	defined in this section. See Section 3.2.3 for information about how		defined in this section. See Section 7.2.3 for information about how
	Cache-Control directives defined elsewhere are handled.		Cache-Control directives defined elsewhere are handled.
	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 7.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-		Cache directives are identified by a token, to be compared case-
	insensitively, and have an optional argument.		insensitively, and have an optional argument, that can use both token
			and quoted-string syntax. For the directives defined below that
			define arguments, recipients ought to accept both forms, even if one
			is documented to be preferred. For any directive not defined by this
			specification, recipients MUST accept both forms.
	Cache-Control = 1#cache-directive		Cache-Control = 1#cache-directive
	cache-directive = cache-request-directive		cache-directive = token [ "=" ( token / quoted-string ) ]
	/ cache-response-directive
	cache-extension = token [ "=" ( token / quoted-string ) ]		For the cache directives defined below, no argument is defined (nor
			allowed) otherwise stated otherwise.
	3.2.1. Request Cache-Control Directives		7.2.1. Request Cache-Control Directives
	cache-request-directive =		7.2.1.1. no-cache
	"no-cache"
	/ "no-store"
	/ "max-age" "=" delta-seconds
	/ "max-stale" [ "=" delta-seconds ]
	/ "min-fresh" "=" delta-seconds
	/ "no-transform"
	/ "only-if-cached"
	/ cache-extension
	no-cache		The "no-cache" request directive indicates that a cache MUST NOT use
			a stored response to satisfy the request without successful
			validation on the origin server.
	The no-cache request directive indicates that a cache MUST NOT use		7.2.1.2. no-store
	a stored response to satisfy the request without successful
	validation on the origin server.
	no-store		The "no-store" request directive indicates that a cache MUST NOT
			store any part of either this request or any response to it. This
			directive applies to both private and shared caches. "MUST NOT
			store" in this context means that the cache MUST NOT intentionally
			store the information in non-volatile storage, and MUST make a best-
			effort attempt to remove the information from volatile storage as
			promptly as possible after forwarding it.
	The no-store request directive indicates that a cache MUST NOT		This directive is NOT a reliable or sufficient mechanism for ensuring
	store any part of either this request or any response to it. This		privacy. In particular, malicious or compromised caches might not
	directive applies to both private and shared caches. "MUST NOT		recognize or obey this directive, and communications networks might
	store" in this context means that the cache MUST NOT intentionally		be vulnerable to eavesdropping.
	store the information in non-volatile storage, and MUST make a
	best-effort attempt to remove the information from volatile
	storage as promptly as possible after forwarding it.
	This directive is NOT a reliable or sufficient mechanism for		Note that if a request containing this directive is satisfied from a
	ensuring privacy. In particular, malicious or compromised caches		cache, the no-store request directive does not apply to the already
	might not recognize or obey this directive, and communications		stored response.
	networks might be vulnerable to eavesdropping.
	Note that if a request containing this directive is satisfied from		7.2.1.3. max-age
	a cache, the no-store request directive does not apply to the
	already stored response.
	max-age		Argument syntax:
	The max-age request directive indicates that the client is		delta-seconds (see Section 1.4.1)
	unwilling to accept a response whose age is greater than the
	specified number of seconds. Unless the max-stale request
	directive is also present, the client is not willing to accept a
	stale response.
	max-stale		The "max-age" request directive indicates that the client is
			unwilling to accept a response whose age is greater than the
			specified number of seconds. Unless the max-stale request directive
			is also present, the client is not willing to accept a stale
			response.
	The max-stale request directive indicates that the client is		Note: This directive uses the token form of the argument syntax;
	willing to accept a response that has exceeded its expiration		e.g., 'max-age=5', not 'max-age="5"'. Senders SHOULD NOT use the
	time. If max-stale is assigned a value, then the client is		quoted-string form.
	willing to accept a response that has exceeded its expiration time
	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
	stale response of any age.
	min-fresh		7.2.1.4. max-stale
	The min-fresh request directive indicates that the client is		Argument syntax:
	willing to accept a response whose freshness lifetime is no less
	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 specified number of seconds.
	no-transform		delta-seconds (see Section 1.4.1)
	The no-transform request directive indicates that an intermediary		The "max-stale" request directive indicates that the client is
	(whether or not it implements a cache) MUST NOT change the		willing to accept a response that has exceeded its expiration time.
	Content-Encoding, Content-Range or Content-Type request header		If max-stale is assigned a value, then the client is willing to
	fields, nor the request representation.		accept a response that has exceeded its expiration time 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 stale response of
			any age.
	only-if-cached		Note: This directive uses the token form of the argument syntax;
			e.g., 'max-stale=10', not 'max-stale="10"'. Senders SHOULD NOT use
			the quoted-string form.
	The only-if-cached request directive indicates that the client		7.2.1.5. min-fresh
	only wishes to obtain a stored response. If it receives this
	directive, a cache SHOULD either respond using a stored response
	that is consistent with the other constraints of the request, or
	respond with a 504 (Gateway Timeout) status code. If a group of
	caches is being operated as a unified system with good internal
	connectivity, a member cache MAY forward such a request within
	that group of caches.
	3.2.2. Response Cache-Control Directives		Argument syntax:
	cache-response-directive =		delta-seconds (see Section 1.4.1)
	"public"
	/ "private" [ "=" DQUOTE 1#field-name DQUOTE ]
	/ "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]
	/ "no-store"
	/ "no-transform"
	/ "must-revalidate"
	/ "proxy-revalidate"
	/ "max-age" "=" delta-seconds
	/ "s-maxage" "=" delta-seconds
	/ cache-extension
	public		The "min-fresh" request directive indicates that the client is
			willing to accept a response whose freshness lifetime is no less 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
			specified number of seconds.
	The public response directive indicates that a response whose		Note: This directive uses the token form of the argument syntax;
	associated request contains an 'Authentication' header MAY be		e.g., 'min-fresh=20', not 'min-fresh="20"'. Senders SHOULD NOT use
	stored (see Section 2.7).		the quoted-string form.
	private		7.2.1.6. no-transform
	The private response directive indicates that the response message		The "no-transform" request directive indicates that an intermediary
	is intended for a single user and MUST NOT be stored by a shared		(whether or not it implements a cache) MUST NOT change the Content-
	cache. A private cache MAY store the response.		Encoding, Content-Range or Content-Type request header fields, nor
			the request representation.
	If the private response directive specifies one or more field-		7.2.1.7. only-if-cached
	names, this requirement is limited to the field-values associated
	with the listed response header fields. That is, a shared cache
	MUST NOT store the specified field-names(s), whereas it MAY store
	the remainder of the response message.
	Note: This usage of the word "private" only controls where the		The "only-if-cached" request directive indicates that the client only
	response can be stored; it cannot ensure the privacy of the		wishes to obtain a stored response. If it receives this directive, a
	message content. Also, private response directives with field-		cache SHOULD either respond using a stored response that is
	names are often handled by implementations as if an unqualified		consistent with the other constraints of the request, or respond with
	private directive was received; i.e., the special handling for the		a 504 (Gateway Timeout) status code. If a group of caches is being
	qualified form is not widely implemented.		operated as a unified system with good internal connectivity, a
			member cache MAY forward such a request within that group of caches.
	no-cache		7.2.2. Response Cache-Control Directives
	The no-cache response directive indicates that the response MUST		7.2.2.1. public
	NOT be used to satisfy a subsequent request without successful
	validation on the origin server. This allows an origin server to
	prevent a cache from using it to satisfy a request without
	contacting it, even by caches that have been configured to return
	stale responses.
	If the no-cache response directive specifies one or more field-		The "public" response directive indicates that a response whose
	names, then a cache MAY use the response to satisfy a subsequent		associated request contains an 'Authentication' header MAY be stored
	request, subject to any other restrictions on caching. However,		(see Section 3.2).
	any header fields in the response that have the field-name(s)
	listed MUST NOT be sent in the response to a subsequent request
	without successful revalidation with the origin server. This
	allows an origin server to prevent the re-use of certain header
	fields in a response, while still allowing caching of the rest of
	the response.
	Note: Most HTTP/1.0 caches will not recognize or obey this		7.2.2.2. private
	directive. Also, no-cache response directives with field-names
	are often handled by implementations as if an unqualified no-cache
	directive was received; i.e., the special handling for the
	qualified form is not widely implemented.
	no-store		Argument syntax:
	The no-store response directive indicates that a cache MUST NOT		#field-name
	store any part of either the immediate request or response. This
	directive applies to both private and shared caches. "MUST NOT
	store" in this context means that the cache MUST NOT intentionally
	store the information in non-volatile storage, and MUST make a
	best-effort attempt to remove the information from volatile
	storage as promptly as possible after forwarding it.
	This directive is NOT a reliable or sufficient mechanism for		The "private" response directive indicates that the response message
	ensuring privacy. In particular, malicious or compromised caches		is intended for a single user and MUST NOT be stored by a shared
	might not recognize or obey this directive, and communications		cache. A private cache MAY store the response.
	networks might be vulnerable to eavesdropping.
	must-revalidate		If the private response directive specifies one or more field-names,
			this requirement is limited to the field-values associated with the
			listed response header fields. That is, a shared cache MUST NOT
			store the specified field-names(s), whereas it MAY store the
			remainder of the response message.
	The must-revalidate response directive indicates that once it has		The field-names given are not limited to the set of standard header
	become stale, a cache MUST NOT use the response to satisfy		fields defined by this specification. Field names are case-
	subsequent requests without successful validation on the origin		insensitive.
	server.
	The must-revalidate directive is necessary to support reliable		Note: This usage of the word "private" only controls where the
	operation for certain protocol features. In all circumstances a		response can be stored; it cannot ensure the privacy of the message
	cache MUST obey the must-revalidate directive; in particular, if a		content. Also, private response directives with field-names are
	cache cannot reach the origin server for any reason, it MUST		often handled by implementations as if an unqualified private
	generate a 504 (Gateway Timeout) response.		directive was received; i.e., the special handling for the qualified
			form is not widely implemented.
	The must-revalidate directive ought to be used by servers if and		Note: This directive uses the quoted-string form of the argument
	only if failure to validate a request on the representation could		syntax. Senders SHOULD NOT use the token form (even if quoting
	result in incorrect operation, such as a silently unexecuted		appears not to be needed for single-entry lists).
	financial transaction.
	proxy-revalidate		7.2.2.3. no-cache
	The proxy-revalidate response directive has the same meaning as		Argument syntax:
	the must-revalidate response directive, except that it does not
	apply to private caches.
	max-age		#field-name
	The max-age response directive indicates that the response is to		The "no-cache" response directive indicates that the response MUST
	be considered stale after its age is greater than the specified		NOT be used to satisfy a subsequent request without successful
	number of seconds.		validation on the origin server. This allows an origin server to
			prevent a cache from using it to satisfy a request without contacting
			it, even by caches that have been configured to return stale
			responses.
	s-maxage		If the no-cache response directive specifies one or more field-names,
			then a cache MAY use the response to satisfy a subsequent request,
			subject to any other restrictions on caching. However, any header
			fields in the response that have the field-name(s) listed MUST NOT be
			sent in the response to a subsequent request without successful
			revalidation with the origin server. This allows an origin server to
			prevent the re-use of certain header fields in a response, while
			still allowing caching of the rest of the response.
	The s-maxage response directive indicates that, in shared caches,		The field-names given are not limited to the set of standard header
	the maximum age specified by this directive overrides the maximum		fields defined by this specification. Field names are case-
	age specified by either the max-age directive or the Expires		insensitive.
	header field. The s-maxage directive also implies the semantics
	of the proxy-revalidate response directive.
	no-transform		Note: Many HTTP/1.0 caches will not recognize or obey this directive.
			Also, no-cache response directives with field-names are often handled
			by implementations as if an unqualified no-cache directive was
			received; i.e., the special handling for the qualified form is not
			widely implemented.
	The no-transform response directive indicates that an intermediary		Note: This directive uses the quoted-string form of the argument
	(regardless of whether it implements a cache) MUST NOT change the		syntax. Senders SHOULD NOT use the token form (even if quoting
	Content-Encoding, Content-Range or Content-Type response header		appears not to be needed for single-entry lists).
	fields, nor the response representation.
	3.2.3. Cache Control Extensions		7.2.2.4. no-store
			The "no-store" response directive indicates that a cache MUST NOT
			store any part of either the immediate request or response. This
			directive applies to both private and shared caches. "MUST NOT
			store" in this context means that the cache MUST NOT intentionally
			store the information in non-volatile storage, and MUST make a best-
			effort attempt to remove the information from volatile storage as
			promptly as possible after forwarding it.
			This directive is NOT a reliable or sufficient mechanism for ensuring
			privacy. In particular, malicious or compromised caches might not
			recognize or obey this directive, and communications networks might
			be vulnerable to eavesdropping.
			7.2.2.5. must-revalidate
			The "must-revalidate" response directive indicates that once it has
			become stale, a cache MUST NOT use the response to satisfy subsequent
			requests without successful validation on the origin server.
			The must-revalidate directive is necessary to support reliable
			operation for certain protocol features. In all circumstances a
			cache MUST obey the must-revalidate directive; in particular, if a
			cache cannot reach the origin server for any reason, it MUST generate
			a 504 (Gateway Timeout) response.
			The must-revalidate directive ought to be used by servers if and only
			if failure to validate a request on the representation could result
			in incorrect operation, such as a silently unexecuted financial
			transaction.
			7.2.2.6. proxy-revalidate
			The "proxy-revalidate" response directive has the same meaning as the
			must-revalidate response directive, except that it does not apply to
			private caches.
			7.2.2.7. max-age
			Argument syntax:
			delta-seconds (see Section 1.4.1)
			The "max-age" response directive indicates that the response is to be
			considered stale after its age is greater than the specified number
			of seconds.
			Note: This directive uses the token form of the argument syntax;
			e.g., 'max-age=5', not 'max-age="5"'. Senders SHOULD NOT use the
			quoted-string form.
			7.2.2.8. s-maxage
			Argument syntax:
			delta-seconds (see Section 1.4.1)
			The "s-maxage" response directive indicates that, in shared caches,
			the maximum age specified by this directive overrides the maximum age
			specified by either the max-age directive or the Expires header
			field. The s-maxage directive also implies the semantics of the
			proxy-revalidate response directive.
			Note: This directive uses the token form of the argument syntax;
			e.g., 's-maxage=10', not 's-maxage="10"'. Senders SHOULD NOT use the
			quoted-string form.
			7.2.2.9. no-transform
			The "no-transform" response directive indicates that an intermediary
			(regardless of whether it implements a cache) MUST NOT change the
			Content-Encoding, Content-Range or Content-Type response header
			fields, nor the response representation.
			7.2.3. Cache Control Extensions
	The Cache-Control header field can be extended through the use of one		The Cache-Control header field can be extended through the use of one
	or more cache-extension tokens, each with an optional value.		or more cache-extension tokens, each with an optional value.
	Informational extensions (those that do not require a change in cache		Informational extensions (those that do not require a change in cache
	behavior) can be added without changing the semantics of other		behavior) can be added without changing the semantics of other
	directives. Behavioral extensions are designed to work by acting as		directives. Behavioral extensions are designed to work by acting as
	modifiers to the existing base of cache directives. Both the new		modifiers to the existing base of cache directives. Both the new
	directive and the standard directive are supplied, such that		directive and the standard directive are supplied, such that
	applications that do not understand the new directive will default to		applications that do not understand the new directive will default to
	the behavior specified by the standard directive, and those that		the behavior specified by the standard directive, and those that
	skipping to change at page 27, line 9 ¶		skipping to change at page 27, line 9 ¶
	This extension mechanism depends on an HTTP cache obeying all of the		This extension mechanism depends on an HTTP cache obeying all of the
	cache-control directives defined for its native HTTP-version, obeying		cache-control directives defined for its native HTTP-version, obeying
	certain extensions, and ignoring all directives that it does not		certain extensions, and ignoring all directives that it does not
	understand.		understand.
	For example, consider a hypothetical new response directive called		For example, consider a hypothetical new response directive called
	"community" that acts as a modifier to the private directive. We		"community" that acts as a modifier to the private directive. We
	define this new directive to mean that, in addition to any private		define this new directive to mean that, in addition to any private
	cache, any cache that is shared only by members of the community		cache, any cache that is shared only by members of the community
	named within its value may cache the response. An origin server		named within its value is allowed to cache the response. An origin
	wishing to allow the UCI community to use an otherwise private		server wishing to allow the UCI community to use an otherwise private
	response in their shared cache(s) could do so by including		response in their shared cache(s) could do so by including
	Cache-Control: private, community="UCI"		Cache-Control: private, community="UCI"
	A cache seeing this header field will act correctly even if the cache		A cache seeing this header field will act correctly even if the cache
	does not understand the community cache-extension, since it will also		does not understand the community cache-extension, since it will also
	see and understand the private directive and thus default to the safe		see and understand the private directive and thus default to the safe
	behavior.		behavior.
	A cache MUST ignore unrecognized cache directives; it is assumed that		A cache MUST ignore unrecognized cache directives; it is assumed that
	any cache directive likely to be unrecognized by an HTTP/1.1 cache		any cache directive likely to be unrecognized by an HTTP/1.1 cache
	will be combined with standard directives (or the response's default		will 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).
			New extension directives ought to consider defining:
			o What it means for a directive to be specified multiple times,
			o When the directive does not take an argument, what it means when
			an argument is present,
			o When the directive requires an argument, what it means when it is
			missing.
	The HTTP Cache Directive Registry defines the name space for the		The HTTP Cache Directive Registry defines the name space for the
	cache directives.		cache directives.
	A registration MUST include the following fields:		A registration MUST include the following fields:
	o Cache Directive Name		o Cache Directive Name
	o Pointer to specification text		o Pointer to specification text
	Values to be added to this name space require IETF Review (see		Values to be added to this name space require IETF Review (see
	[RFC5226], Section 4.1).		[RFC5226], Section 4.1).
	The registry itself is maintained at		The registry itself is maintained at
	<http://www.iana.org/assignments/http-cache-directives>.		<http://www.iana.org/assignments/http-cache-directives>.
	3.3. Expires		7.3. Expires
	The "Expires" header field gives the date/time after which the		The "Expires" header field gives the date/time after which the
	response is considered stale. See Section 2.3 for further discussion		response is considered stale. See Section 4.1 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 8 of [Part2]; a sender MUST use the rfc1123-date format.		in Section 5.1 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").
	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 7.2.2.7), that directive overrides the
	Expires field. Likewise, the s-maxage directive overrides Expires		Expires field. Likewise, the s-maxage directive (Section 7.2.2.8)
	in shared caches.		overrides the Expires header fieldin 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 many 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		An origin server without a clock MUST NOT assign Expires values to a
	response unless these values were associated with the resource by 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		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		that is known, at or before server configuration time, to be in the
	past (this allows "pre-expiration" of responses without storing		past (this allows "pre-expiration" of responses without storing
	separate Expires values for each resource).		separate Expires values for each resource).
	3.4. Pragma		7.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 field 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 field is not present in a request, the
	cache request pragma-directive MUST have the same effect on caches as		no-cache request pragma-directive MUST have the same effect on caches
	if "Cache-Control: no-cache" were present (see Section 3.2.1).		as if "Cache-Control: no-cache" were present (see Section 7.2.1).
	When sending a no-cache request, a client ought to include both the		When sending a no-cache request, a client ought to include both the
	pragma and cache-control directives, unless Cache-Control: no-cache		pragma and cache-control directives, unless Cache-Control: no-cache
	is 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.
	Note: Because the meaning of "Pragma: no-cache" in responses is		Note: Because the meaning of "Pragma: no-cache" in responses is
	not specified, it does not provide a reliable replacement for		not specified, it does not provide a reliable replacement for
	"Cache-Control: no-cache" in them.		"Cache-Control: no-cache" in them.
	3.5. Vary		7.5. Vary
	The "Vary" header field conveys the set of header fields that were		The "Vary" header field conveys the set of header fields that were
	used to select the representation.		used to select the representation.
	Caches use this information, in part, to determine whether a stored		Caches use this information, in part, to determine whether a stored
	response can be used to satisfy a given request; see Section 2.8.		response can be used to satisfy a given request; see Section 4.3.
	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.8.
	In uncacheable or stale responses, the Vary field value advises the		In uncacheable or stale responses, the Vary field value advises the
	user agent about the criteria that were used to select the		user agent about the criteria that were used to select the
	representation.		representation.
	Vary = "*" / 1#field-name		Vary = "*" / 1#field-name
	The set of header fields named by the Vary field value is known as		The set of header fields named by the Vary field value is known as
	the selecting header fields.		the selecting header fields.
	skipping to change at page 30, line 15 ¶		skipping to change at page 30, line 25 ¶
	A Vary field value of "*" signals that unspecified parameters not		A Vary field value of "*" signals that unspecified parameters not
	limited to the header fields (e.g., the network address of the		limited to the header fields (e.g., the network address of the
	client), play a role in the selection of the response representation;		client), play a role in the selection of the response representation;
	therefore, a cache cannot determine whether this response is		therefore, a cache cannot determine whether this response is
	appropriate. A proxy MUST NOT generate the "*" value.		appropriate. A proxy MUST NOT generate the "*" value.
	The field-names given are not limited to the set of standard header		The field-names given are not limited to the set of standard header
	fields defined by this specification. Field names are case-		fields defined by this specification. Field names are case-
	insensitive.		insensitive.
	3.6. Warning		7.6. Warning
	The "Warning" header field is used to carry additional information		The "Warning" header field is used to carry additional information
	about the status or transformation of a message that might not be		about the status or transformation of a message that might not be
	reflected in the message. This information is typically used to warn		reflected in the message. This information is typically used to warn
	about possible incorrectness introduced by caching operations or		about possible incorrectness introduced by caching operations or
	transformations applied to the payload of the message.		transformations applied to the payload of the 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,
	distinguishes these responses from true failures.		distinguishes these responses from true failures.
	skipping to change at page 30, line 52 ¶		skipping to change at page 31, line 14 ¶
	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 are encouraged		Systems that generate multiple Warning header fields are encouraged
	to order them with this user agent behavior in mind. New Warning		to order them with this user agent behavior in mind. New Warning
	header fields are added after any existing Warning headers fields.		header fields are added after any existing Warning header 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 31, line 36 ¶		skipping to change at page 31, line 47 ¶
	warn-date, and that warn-date is different from the Date value in the		warn-date, and that warn-date is different from the Date value in the
	response, then that warning-value MUST be deleted from the message		response, then that warning-value MUST be deleted from the message
	before storing, forwarding, or using it. (preventing the consequences		before storing, forwarding, or using it. (preventing the consequences
	of naive caching of Warning header fields.) If all of the warning-		of naive caching of Warning header fields.) If all of the warning-
	values are deleted for this reason, the Warning header field MUST be		values are deleted for this reason, the Warning header field MUST be
	deleted as well.		deleted as well.
	The following warn-codes are defined by this specification, each with		The following warn-codes are defined by this specification, each with
	a recommended warn-text in English, and a description of its meaning.		a recommended warn-text in English, and a description of its meaning.
	3.6.1. 110 Response is Stale		7.6.1. 110 Response is Stale
	A cache SHOULD include this whenever the returned response is stale.		A cache SHOULD include this whenever the returned response is stale.
	3.6.2. 111 Revalidation Failed		7.6.2. 111 Revalidation Failed
	A cache SHOULD include this when returning a stale response because		A cache SHOULD include this when returning a stale response because
	an attempt to validate the response failed, due to an inability to		an attempt to validate the response failed, due to an inability to
	reach the server.		reach the server.
	3.6.3. 112 Disconnected Operation		7.6.3. 112 Disconnected Operation
	A cache SHOULD include this if it is intentionally disconnected from		A cache SHOULD include this if it is intentionally disconnected from
	the rest of the network for a period of time.		the rest of the network for a period of time.
	3.6.4. 113 Heuristic Expiration		7.6.4. 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 than		lifetime greater than 24 hours and the response's age is greater than
	24 hours.		24 hours.
	3.6.5. 199 Miscellaneous Warning		7.6.5. 199 Miscellaneous Warning
	The warning text can include arbitrary information to be presented to		The warning text can include arbitrary information to be presented to
	a human user, or logged. A system receiving this warning MUST NOT		a human user, or logged. A system receiving this warning MUST NOT
	take any automated action, besides presenting the warning to the		take any automated action, besides presenting the warning to the
	user.		user.
	3.6.6. 214 Transformation Applied		7.6.6. 214 Transformation Applied
	MUST be added by a proxy if it applies any transformation to the		MUST be added by a proxy if it applies any transformation to the
	representation, such as changing the content-coding, media-type, or		representation, such as changing the content-coding, media-type, or
	modifying the representation data, unless this Warning code already		modifying the representation data, unless this Warning code already
	appears in the response.		appears in the response.
	3.6.7. 299 Miscellaneous Persistent Warning		7.6.7. 299 Miscellaneous Persistent Warning
	The warning text can include arbitrary information to be presented to		The warning text can include arbitrary information to be presented to
	a human user, or logged. A system receiving this warning MUST NOT		a human user, or logged. A system receiving this warning MUST NOT
	take any automated action.		take any automated action.
	3.6.8. Warn Code Extensions		7.6.8. Warn Code Extensions
	The HTTP Warn Code Registry defines the name space for warn codes.		The HTTP Warn Code Registry defines the name space for warn codes.
	A registration MUST include the following fields:		A registration MUST include the following fields:
	o Warn Code (3 digits)		o Warn Code (3 digits)
	o Short Description		o Short Description
	o Pointer to specification text		o Pointer to specification text
	Values to be added to this name space require IETF Review (see		Values to be added to this name space require IETF Review (see
	[RFC5226], Section 4.1).		[RFC5226], Section 4.1).
	The registry itself is maintained at		The registry itself is maintained at
	<http://www.iana.org/assignments/http-warn-codes>.		<http://www.iana.org/assignments/http-warn-codes>.
	4. History Lists		8. History Lists
	User agents often have history mechanisms, such as "Back" buttons and		User agents often have history mechanisms, such as "Back" buttons and
	history lists, that can be used to redisplay a representation		history lists, that can be used to redisplay a representation
	retrieved earlier in a session.		retrieved earlier in a session.
	The freshness model (Section 2.3) does not necessarily apply to		The freshness model (Section 4.1) does not necessarily apply to
	history mechanisms. I.e., a history mechanism can display a previous		history mechanisms. I.e., a history mechanism can display a previous
	representation even if it has expired.		representation even if it has expired.
	This does not prohibit the history mechanism from telling the user		This does not prohibit the history mechanism from telling the user
	that a view might be stale, or from honoring cache directives (e.g.,		that a view might be stale, or from honoring cache directives (e.g.,
	Cache-Control: no-store).		Cache-Control: no-store).
	5. IANA Considerations		9. IANA Considerations
	5.1. Cache Directive Registry		9.1. Cache Directive Registry
	The registration procedure for HTTP Cache Directives is defined by		The registration procedure for HTTP Cache Directives is defined by
	Section 3.2.3 of this document.		Section 7.2.3 of this document.
	The HTTP Cache Directive Registry shall be created at		The HTTP Cache Directive Registry shall be created at
	<http://www.iana.org/assignments/http-cache-directives> and be		<http://www.iana.org/assignments/http-cache-directives> and be
	populated with the registrations below:		populated with the registrations below:
	+------------------------+------------------------------+		+------------------------+----------------------------------+
	| Cache Directive | Reference |		| Cache Directive | Reference |
	+------------------------+------------------------------+		+------------------------+----------------------------------+
	| max-age | Section 3.2.1, Section 3.2.2 |		| max-age | Section 7.2.1.3, Section 7.2.2.7 |
	| max-stale | Section 3.2.1 |		| max-stale | Section 7.2.1.4 |
	| min-fresh | Section 3.2.1 |		| min-fresh | Section 7.2.1.5 |
	| must-revalidate | Section 3.2.2 |		| must-revalidate | Section 7.2.2.5 |
	| no-cache | Section 3.2.1, Section 3.2.2 |		| no-cache | Section 7.2.1.1, Section 7.2.2.3 |
	| no-store | Section 3.2.1, Section 3.2.2 |		| no-store | Section 7.2.1.2, Section 7.2.2.4 |
	| no-transform | Section 3.2.1, Section 3.2.2 |		| no-transform | Section 7.2.1.6, Section 7.2.2.9 |
	| only-if-cached | Section 3.2.1 |		| only-if-cached | Section 7.2.1.7 |
	| private | Section 3.2.2 |		| private | Section 7.2.2.2 |
	| proxy-revalidate | Section 3.2.2 |		| proxy-revalidate | Section 7.2.2.6 |
	| public | Section 3.2.2 |		| public | Section 7.2.2.1 |
	| s-maxage | Section 3.2.2 |		| s-maxage | Section 7.2.2.8 |
	| stale-if-error | [RFC5861], Section 4 |		| stale-if-error | [RFC5861], Section 4 |
	| stale-while-revalidate | [RFC5861], Section 3 |		| stale-while-revalidate | [RFC5861], Section 3 |
	+------------------------+------------------------------+		+------------------------+----------------------------------+
	5.2. Warn Code Registry		9.2. Warn Code Registry
	The registration procedure for HTTP Warn Codes is defined by		The registration procedure for HTTP Warn Codes is defined by
	Section 3.6.8 of this document.		Section 7.6.8 of this document.
	The HTTP Warn Code Registry shall be created at		The HTTP Warn Code Registry shall be created at
	<http://www.iana.org/assignments/http-cache-directives> and be		<http://www.iana.org/assignments/http-cache-directives> and be
	populated with the registrations below:		populated with the registrations below:
	+-----------+----------------------------------+---------------+		+-----------+----------------------------------+---------------+
	| Warn Code | Short Description | Reference |		| Warn Code | Short Description | Reference |
	+-----------+----------------------------------+---------------+		+-----------+----------------------------------+---------------+
	| 110 | Response is Stale | Section 3.6.1 |		| 110 | Response is Stale | Section 7.6.1 |
	| 111 | Revalidation Failed | Section 3.6.2 |		| 111 | Revalidation Failed | Section 7.6.2 |
	| 112 | Disconnected Operation | Section 3.6.3 |		| 112 | Disconnected Operation | Section 7.6.3 |
	| 113 | Heuristic Expiration | Section 3.6.4 |		| 113 | Heuristic Expiration | Section 7.6.4 |
	| 199 | Miscellaneous Warning | Section 3.6.5 |		| 199 | Miscellaneous Warning | Section 7.6.5 |
	| 214 | Transformation Applied | Section 3.6.6 |		| 214 | Transformation Applied | Section 7.6.6 |
	| 299 | Miscellaneous Persistent Warning | Section 3.6.7 |		| 299 | Miscellaneous Persistent Warning | Section 7.6.7 |
	+-----------+----------------------------------+---------------+		+-----------+----------------------------------+---------------+
	5.3. Header Field Registration		9.3. Header Field Registration
	The Message Header Field Registry located at <http://www.iana.org/		The Message Header Field Registry located at <http://www.iana.org/
	assignments/message-headers/message-header-index.html> shall be		assignments/message-headers/message-header-index.html> shall be
	updated with the permanent registrations below (see [RFC3864]):		updated with the permanent registrations below (see [RFC3864]):
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Age | http | standard | Section 3.1 |		| Age | http | standard | Section 7.1 |
	| Cache-Control | http | standard | Section 3.2 |		| Cache-Control | http | standard | Section 7.2 |
	| Expires | http | standard | Section 3.3 |		| Expires | http | standard | Section 7.3 |
	| Pragma | http | standard | Section 3.4 |		| Pragma | http | standard | Section 7.4 |
	| Vary | http | standard | Section 3.5 |		| Vary | http | standard | Section 7.5 |
	| Warning | http | standard | Section 3.6 |		| Warning | http | standard | Section 7.6 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	6. Security Considerations		10. Security Considerations
	Caches expose additional potential vulnerabilities, since the		Caches expose additional potential vulnerabilities, since the
	contents of the cache represent an attractive target for malicious		contents of the cache represent an attractive target for malicious
	exploitation. Because cache contents persist after an HTTP request		exploitation. Because cache contents persist after an HTTP request
	is complete, an attack on the cache can reveal information long after		is complete, an attack on the cache can reveal information long after
	a user believes that the information has been removed from the		a user believes that the information has been removed from the
	network. Therefore, cache contents need to be protected as sensitive		network. Therefore, cache contents need to be protected as sensitive
	information.		information.
	7. Acknowledgments		11. Acknowledgments
	See Section 9 of [Part1].		See Section 9 of [Part1].
	8. References		12. References
	8.1. Normative References
			12.1. Normative References
	[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 1: URIs, Connections, and Message		"HTTP/1.1, part 1: Message Routing and Syntax"",
	Parsing", draft-ietf-httpbis-p1-messaging-19 (work in		draft-ietf-httpbis-p1-messaging-20 (work in progress),
	progress), March 2012.		July 2012.
	[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 2: Message Semantics",		"HTTP/1.1, part 2: Semantics and Payloads",
	draft-ietf-httpbis-p2-semantics-19 (work in progress),		draft-ietf-httpbis-p2-semantics-20 (work in progress),
	March 2012.		July 2012.
	[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 4: Conditional Requests",		"HTTP/1.1, part 4: Conditional Requests",
	draft-ietf-httpbis-p4-conditional-19 (work in progress),		draft-ietf-httpbis-p4-conditional-20 (work in progress),
	March 2012.		July 2012.
	[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 5: Range Requests and Partial Responses",		"HTTP/1.1, part 5: Range Requests",
	draft-ietf-httpbis-p5-range-19 (work in progress),		draft-ietf-httpbis-p5-range-20 (work in progress),
	March 2012.		July 2012.
	[Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part7] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 7: Authentication",		"HTTP/1.1, part 7: Authentication",
	draft-ietf-httpbis-p7-auth-19 (work in progress),		draft-ietf-httpbis-p7-auth-20 (work in progress),
	March 2012.		July 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	8.2. Informative References		12.2. Informative References
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation", RFC 1305, March 1992.		Specification, Implementation", RFC 1305, March 1992.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	skipping to change at page 36, line 12 ¶		skipping to change at page 36, line 42 ¶
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale		[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
	Content", RFC 5861, April 2010.		Content", RFC 5861, April 2010.
	Appendix A. Changes from RFC 2616		Appendix A. Changes from RFC 2616
	Make the specified age calculation algorithm less conservative.		Make the specified age calculation algorithm less conservative.
	(Section 2.3.2)		(Section 4.1.3)
	Remove requirement to consider Content-Location in successful		Remove requirement to consider Content-Location in successful
	responses in order to determine the appropriate response to use.		responses in order to determine the appropriate response to use.
	(Section 2.4)		(Section 4.2)
	Clarify denial of service attack avoidance requirement.		Clarify denial of service attack avoidance requirement. (Section 6)
	(Section 2.6)
	Change ABNF productions for header fields to only define the field		Change ABNF productions for header fields to only define the field
	value. (Section 3)		value. (Section 7)
	Do not mention RFC 2047 encoding and multiple languages in Warning		Do not mention RFC 2047 encoding and multiple languages in Warning
	header fields anymore, as these aspects never were implemented.		header fields anymore, as these aspects never were implemented.
	(Section 3.6)		(Section 7.6)
	Appendix B. Collected ABNF		Introduce Cache Directive and Warn Code Registries. (Section 7.2.3
			and Section 7.6.8)
			Appendix B. Imported ABNF
			The following core rules are included by reference, as defined in
			Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
			CRLF (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 sequence of data), SP (space), and VCHAR (any visible US-ASCII
			character).
			The rules below are defined in [Part1]:
			OWS = <OWS, defined in [Part1], Section 3.2.1>
			field-name = <field-name, defined in [Part1], Section 3.2>
			quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
			token = <token, defined in [Part1], Section 3.2.4>
			port = <port, defined in [Part1], Section 2.8>
			pseudonym = <pseudonym, defined in [Part1], Section 6.2>
			uri-host = <uri-host, defined in [Part1], Section 2.8>
			The rules below are defined in other parts:
			HTTP-date = <HTTP-date, defined in [Part2], Section 5.1>
			Appendix C. Collected ABNF
	Age = delta-seconds		Age = delta-seconds
	Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS		Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
	cache-directive ] )		cache-directive ] )
	Expires = HTTP-date		Expires = HTTP-date
	HTTP-date = <HTTP-date, defined in [Part2], Section 8>		HTTP-date = <HTTP-date, defined in [Part2], Section 5.1>
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS		Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
	pragma-directive ] )		pragma-directive ] )
	Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]		Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
	) )		) )
	Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]		Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
	)		)
	cache-directive = cache-request-directive / cache-response-directive		cache-directive = token [ "=" ( token / quoted-string ) ]
	cache-extension = token [ "=" ( token / quoted-string ) ]
	cache-request-directive = "no-cache" / "no-store" / ( "max-age="
	delta-seconds ) / ( "max-stale" [ "=" delta-seconds ] ) / (
	"min-fresh=" delta-seconds ) / "no-transform" / "only-if-cached" /
	cache-extension
	cache-response-directive = "public" / ( "private" [ "=" DQUOTE *( ","
	OWS ) field-name *( OWS "," [ OWS field-name ] ) DQUOTE ] ) / (
	"no-cache" [ "=" DQUOTE *( "," OWS ) field-name *( OWS "," [ OWS
	field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" /
	"must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds
	) / ( "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.8>
	pragma-directive = "no-cache" / extension-pragma		pragma-directive = "no-cache" / extension-pragma
	pseudonym = <pseudonym, defined in [Part1], Section 6.2>		pseudonym = <pseudonym, defined in [Part1], Section 6.2>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
	token = <token, defined in [Part1], Section 3.2.4>		token = <token, defined in [Part1], Section 3.2.4>
	uri-host = <uri-host, defined in [Part1], Section 2.7>		uri-host = <uri-host, defined in [Part1], Section 2.8>
	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:		Appendix D. Change Log (to be removed by RFC Editor before publication)
	; Age defined but not used
	; Cache-Control defined but not used
	; Expires defined but not used
	; Pragma defined but not used
	; Vary defined but not used
	; Warning defined but not used
	Appendix C. Change Log (to be removed by RFC Editor before publication)
	C.1. Since RFC 2616
	Extracted relevant partitions from [RFC2616].
	C.2. Since draft-ietf-httpbis-p6-cache-00
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/9>: "Trailer"
	(<http://purl.org/NET/http-errata#trailer-hop>)
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/12>: "Invalidation
	after Update or Delete"
	(<http://purl.org/NET/http-errata#invalidupd>)
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
	Informative references"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/48>: "Date reference
	typo"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/49>: "Connection
	header text"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
	references"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
	Reference"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
	to-date references"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/87>: "typo in
	13.2.2"
	Other changes:
	o Use names of RFC4234 core rules DQUOTE and HTAB (work in progress
	on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
	C.3. Since draft-ietf-httpbis-p6-cache-01
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/82>: "rel_path not
	used"
	Other changes:
	o Get rid of duplicate BNF rule names ("host" -> "uri-host") (work
	in progress on <http://tools.ietf.org/wg/httpbis/trac/ticket/36>)
	o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.
	C.4. Since draft-ietf-httpbis-p6-cache-02
	Ongoing work on IANA Message Header Field Registration
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	o Reference RFC 3984, and update header field registrations for
	header fields defined in this document.
	C.5. Since draft-ietf-httpbis-p6-cache-03
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/106>: "Vary header
	classification"
	C.6. Since draft-ietf-httpbis-p6-cache-04
	Ongoing work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Use "/" instead of "|" for alternatives.
	o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
	whitespace ("OWS") and required whitespace ("RWS").
	o Rewrite ABNFs to spell out whitespace rules, factor out header
	field value format definitions.
	C.7. Since draft-ietf-httpbis-p6-cache-05
	This is a total rewrite of this part of the specification.
	Affected 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/60>: "Placement of
	13.5.1 and 13.5.2"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/138>: "The role of
	Warning and Semantic Transparency in Caching"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and
	Caching"
	In addition: Final work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Add appendix containing collected and expanded ABNF, reorganize
	ABNF introduction.
	C.8. Since draft-ietf-httpbis-p6-cache-06
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
	numeric protocol elements"
	Affected issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: "Vary and non-
	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"
	C.10. Since draft-ietf-httpbis-p6-cache-08
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/147>: "serving
	negotiated responses from cache: header-specific canonicalization"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/197>: "Effect of CC
	directives on history lists"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/291>: "Cache
	Extensions can override no-store, etc."
	Affected issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes
	and caching
	Partly resolved issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
	13.5.1 and 13.5.2"
	C.11. Since draft-ietf-httpbis-p6-cache-09
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/29>: "Age
	calculation"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/168>: "Clarify
	differences between / requirements for request and response CC
	directives"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/174>: "Caching
	authenticated responses"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/208>: "IANA registry
	for cache-control directives"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/211>: "Heuristic
	caching of URLs with query components"
	Partly resolved issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
	requested resource's URI"
	C.12. Since draft-ietf-httpbis-p6-cache-10
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
	entity / representation / variant terminology"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
	removing the 'changes from 2068' sections"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
	heuristic caching for new status codes"
	o Clean up TODOs and prose in "Combining Responses."
	C.13. Since draft-ietf-httpbis-p6-cache-11
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about
	clock requirement for caches belongs in p6"
	C.14. Since draft-ietf-httpbis-p6-cache-12
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
	Classification"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/268>: "Clarify
	'public'"
	C.15. Since draft-ietf-httpbis-p6-cache-13
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
	ABNFs for header fields"
	C.16. Since draft-ietf-httpbis-p6-cache-14
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/38>: "Mismatch Vary"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/235>: "Cache
	Invalidation only happens upon successful responses"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
	minimum sizes for protocol elements"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/289>: "Proxies don't
	'understand' methods"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/291>: "Cache
	Extensions can override no-store, etc."
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma"
	C.17. Since draft-ietf-httpbis-p6-cache-15
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one-
	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		Changes up to the first Working Group Last Call draft are summarized
	directive case sensitivity"		in <http://trac.tools.ietf.org/html/
			draft-ietf-httpbis-p6-cache-19#appendix-C>.
	C.19. Since draft-ietf-httpbis-p6-cache-17		D.1. Since draft-ietf-httpbis-p6-cache-19
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/293>: "Interaction		o <http://tools.ietf.org/wg/httpbis/trac/ticket/307>: "untangle
	of request and response Cache-Control"		Cache-Control ABNF"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/212>: "Refining age		o <http://tools.ietf.org/wg/httpbis/trac/ticket/353>: "Multiple
	for 1.1 proxy chains"		values in Cache-Control header fields"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/274>: "warn-code		o <http://tools.ietf.org/wg/httpbis/trac/ticket/355>: "Case
	registry"		sensitivity of header fields in CC values"
	C.20. Since draft-ietf-httpbis-p6-cache-18		o <http://tools.ietf.org/wg/httpbis/trac/ticket/356>: "Spurious
			'MAYs'"
	Closed issues:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/360>: "enhance
			considerations for new cache control directives"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/227>: "Combining		o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
	HEAD responses"		requirements for recipients"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/337>: "Field names		o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
	in cache-control header arguments"		introduction of new IANA registries as normative changes"
	Index		Index
	1		1
	110 Response is Stale (warn code) 31		110 Response is Stale (warn code) 31
	111 Revalidation Failed (warn code) 31		111 Revalidation Failed (warn code) 32
	112 Disconnected Operation (warn code) 31		112 Disconnected Operation (warn code) 32
	113 Heuristic Expiration (warn code) 32		113 Heuristic Expiration (warn code) 32
	199 Miscellaneous Warning (warn code) 32		199 Miscellaneous Warning (warn code) 32
	2		2
	214 Transformation Applied (warn code) 32		214 Transformation Applied (warn code) 32
	299 Miscellaneous Persistent Warning (warn code) 32		299 Miscellaneous Persistent Warning (warn code) 32
	A		A
	age 6		age 5
	Age header field 21		Age header field 20
	C		C
	cache 5		cache 4
	Cache Directives		Cache Directives
	max-age 23, 26		max-age 22, 25
	max-stale 23		max-stale 22
	min-fresh 23		min-fresh 22
	must-revalidate 25		must-revalidate 25
	no-cache 22, 24		no-cache 21, 24
	no-store 22, 25		no-store 21, 25
	no-transform 23, 26		no-transform 23, 26
	only-if-cached 23		only-if-cached 23
	private 24		private 23
	proxy-revalidate 26		proxy-revalidate 25
	public 24		public 23
	s-maxage 26		s-maxage 26
	cache entry 8		cache entry 7
	cache key 8		cache key 7
	Cache-Control header field 21		Cache-Control header field 20
	cacheable 5		cacheable 4
	E		E
	Expires header field 27		Expires header field 28
	explicit expiration time 6		explicit expiration time 5
	F		F
	first-hand 6		first-hand 5
	fresh 6		fresh 5
	freshness lifetime 6		freshness lifetime 5
	G		G
	Grammar		Grammar
	Age 21		Age 20
	Cache-Control 22		Cache-Control 21
	cache-extension 22		cache-directive 21
	cache-request-directive 22		delta-seconds 7
	cache-response-directive 24
	delta-seconds 8
	Expires 28		Expires 28
	extension-pragma 28		extension-pragma 29
	Pragma 28		Pragma 29
	pragma-directive 28		pragma-directive 29
	Vary 29		Vary 29
	warn-agent 30		warn-agent 30
	warn-code 30		warn-code 30
	warn-date 30		warn-date 30
	warn-text 30		warn-text 30
	Warning 30		Warning 30
	warning-value 30		warning-value 30
	H		H
	Header Fields		Header Fields
	Age 21		Age 20
	Cache-Control 21		Cache-Control 20
	Expires 27		Expires 28
	Pragma 28		Pragma 28
	Vary 29		Vary 29
	Warning 30		Warning 30
	heuristic expiration time 6		heuristic expiration time 5
	M		M
	max-age		max-age
	Cache Directive 23, 26		Cache Directive 22, 25
	max-stale		max-stale
	Cache Directive 23		Cache Directive 22
	min-fresh		min-fresh
	Cache Directive 23		Cache Directive 22
	must-revalidate		must-revalidate
	Cache Directive 25		Cache Directive 25
	N		N
	no-cache		no-cache
	Cache Directive 22, 24		Cache Directive 21, 24
	no-store		no-store
	Cache Directive 22, 25		Cache Directive 21, 25
	no-transform		no-transform
	Cache Directive 23, 26		Cache Directive 23, 26
	O		O
	only-if-cached		only-if-cached
	Cache Directive 23		Cache Directive 23
	P		P
	Pragma header field 28		Pragma header field 28
	private		private
	Cache Directive 24		Cache Directive 23
	private cache 5		private cache 4
	proxy-revalidate		proxy-revalidate
	Cache Directive 26		Cache Directive 25
	public		public
	Cache Directive 24		Cache Directive 23
	S		S
	s-maxage		s-maxage
	Cache Directive 26		Cache Directive 26
	shared cache 5		shared cache 4
	stale 6		stale 5
	strong validator 7		strong validator 6
	V		V
	validator 6		validator 5
	strong 7		strong 6
	Vary header field 29		Vary header field 29
	W		W
	Warn Codes		Warn Codes
	110 Response is Stale 31		110 Response is Stale 31
	111 Revalidation Failed 31		111 Revalidation Failed 32
	112 Disconnected Operation 31		112 Disconnected Operation 32
	113 Heuristic Expiration 32		113 Heuristic Expiration 32
	199 Miscellaneous Warning 32		199 Miscellaneous Warning 32
	214 Transformation Applied 32		214 Transformation Applied 32
	299 Miscellaneous Persistent Warning 32		299 Miscellaneous Persistent Warning 32
	Warning header field 30		Warning header field 30
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	skipping to change at page 47, line 19 ¶		skipping to change at page 43, line 4 ¶
	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		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
	Phone: +49 251 2807760
	Fax: +49 251 2807761
	EMail: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
End of changes. 229 change blocks.
	922 lines changed or deleted		693 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/