frankenRFC723x_cache.txt		draft-ietf-httpbis-cache-06.txt
	Internet Engineering Task Force (IETF) R. Fielding, Ed.		HTTP Working Group R. Fielding, Ed.
	Request for Comments: 7234 Adobe		Internet-Draft Adobe
	Obsoletes: 2616 M. Nottingham, Ed.		Obsoletes: 7234 (if approved) M. Nottingham, Ed.
	Category: Standards Track Akamai		Intended status: Standards Track Fastly
	ISSN: 2070-1721 J. Reschke, Ed.		Expires: May 7, 2020 J. Reschke, Ed.
	greenbytes		greenbytes
	June 2014		November 4, 2019
	Hypertext Transfer Protocol (HTTP/1.1): Caching		HTTP Caching
			draft-ietf-httpbis-cache-06
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level protocol for distributed, collaborative, hypertext information		level protocol for distributed, collaborative, hypertext information
	systems. This document defines HTTP caches and the associated header		systems. This document defines HTTP caches and the associated header
	fields that control cache behavior or indicate cacheable response		fields that control cache behavior or indicate cacheable response
	messages.		messages.
			This document obsoletes RFC 7234.
			Editorial Note
			This note is to be removed before publishing as an RFC.
			Discussion of this draft takes place on the HTTP working group
			mailing list (ietf-http-wg@w3.org), which is archived at
			<https://lists.w3.org/Archives/Public/ietf-http-wg/>.
			Working Group information can be found at <https://httpwg.org/>;
			source code and issues list for this draft can be found at
			<https://github.com/httpwg/http-core>.
			The changes in this draft are summarized in Appendix C.7.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This Internet-Draft is submitted in full conformance with the
			provisions of BCP 78 and BCP 79.
	This document is a product of the Internet Engineering Task Force		Internet-Drafts are working documents of the Internet Engineering
	(IETF). It represents the consensus of the IETF community. It has		Task Force (IETF). Note that other groups may also distribute
	received public review and has been approved for publication by the		working documents as Internet-Drafts. The list of current Internet-
	Internet Engineering Steering Group (IESG). Further information on		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet Standards is available in Section 2 of RFC 5741.
	Information about the current status of this document, any errata,		Internet-Drafts are draft documents valid for a maximum of six months
	and how to provide feedback on it may be obtained at		and may be updated, replaced, or obsoleted by other documents at any
	http://www.rfc-editor.org/info/rfc7234.		time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
			This Internet-Draft will expire on May 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2019 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		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	skipping to change at line 63 ¶		skipping to change at page 2, line 38 ¶
	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 ....................................................4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling .............................4		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
	1.2. Syntax Notation ............................................4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
	1.2.1. Delta Seconds .......................................5		1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 6
	2. Overview of Cache Operation .....................................5		2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6
	3. Storing Responses in Caches .....................................6		3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7
	3.1. Storing Incomplete Responses ...............................7		3.1. Storing Incomplete Responses . . . . . . . . . . . . . . 8
	3.2. Storing Responses to Authenticated Requests ................7		3.2. Storing Responses to Authenticated Requests . . . . . . . 9
	3.3. Combining Partial Content ..................................8		3.3. Combining Partial Content . . . . . . . . . . . . . . . . 9
	4. Constructing Responses from Caches ..............................8		4. Constructing Responses from Caches . . . . . . . . . . . . . 9
	4.1. Calculating Secondary Keys with Vary .......................9		4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 10
	4.2. Freshness .................................................11		4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2.1. Calculating Freshness Lifetime .....................12		4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 13
	4.2.2. Calculating Heuristic Freshness ....................13		4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 14
	4.2.3. Calculating Age ....................................13		4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 14
	4.2.4. Serving Stale Responses ............................15		4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 16
	4.3. Validation ................................................16		4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 16
	4.3.1. Sending a Validation Request .......................16		4.3.1. Sending a Validation Request . . . . . . . . . . . . 16
	4.3.2. Handling a Received Validation Request .............16		4.3.2. Handling a Received Validation Request . . . . . . . 17
	4.3.3. Handling a Validation Response .....................18		4.3.3. Handling a Validation Response . . . . . . . . . . . 19
	4.3.4. Freshening Stored Responses upon Validation ........18		4.3.4. Freshening Stored Responses upon Validation . . . . . 19
	4.3.5. Freshening Responses via HEAD ......................19		4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20
	4.4. Invalidation ..............................................20		4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 20
	5. Header Field Definitions .......................................21		5. Header Field Definitions . . . . . . . . . . . . . . . . . . 21
	5.1. Age .......................................................21		5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.2. Cache-Control .............................................21		5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 22
	5.2.1. Request Cache-Control Directives ...................22		5.2.1. Request Cache-Control Directives . . . . . . . . . . 23
	5.2.2. Response Cache-Control Directives ..................24		5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 23
	5.2.3. Cache Control Extensions ...........................27		5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 23
	5.3. Expires ...................................................28		5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 24
	5.4. Pragma ....................................................29		5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 24
	5.5. Warning ...................................................29		5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 24
	5.5.1. Warning: 110 - "Response is Stale" .................31		5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 25
	5.5.2. Warning: 111 - "Revalidation Failed" ...............31		5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 25
	5.5.3. Warning: 112 - "Disconnected Operation" ............31		5.2.2. Response Cache-Control Directives . . . . . . . . . . 25
	5.5.4. Warning: 113 - "Heuristic Expiration" ..............31		5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 25
	5.5.5. Warning: 199 - "Miscellaneous Warning" .............32		5.2.2.2. no-cache . . . . . . . . . . . . . . . . . . . . 26
	5.5.6. Warning: 214 - "Transformation Applied" ............32		5.2.2.3. no-store . . . . . . . . . . . . . . . . . . . . 26
	5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32		5.2.2.4. no-transform . . . . . . . . . . . . . . . . . . 27
	6. History Lists ..................................................32		5.2.2.5. public . . . . . . . . . . . . . . . . . . . . . 27
	7. IANA Considerations ............................................32		5.2.2.6. private . . . . . . . . . . . . . . . . . . . . . 27
	7.1. Cache Directive Registry ..................................32		5.2.2.7. proxy-revalidate . . . . . . . . . . . . . . . . 28
	7.1.1. Procedure ..........................................32		5.2.2.8. max-age . . . . . . . . . . . . . . . . . . . . . 28
	7.1.2. Considerations for New Cache Control Directives ....33		5.2.2.9. s-maxage . . . . . . . . . . . . . . . . . . . . 28
	7.1.3. Registrations ......................................33		5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 29
	7.2. Warn Code Registry ........................................34		5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 30
	7.2.1. Procedure ..........................................34		5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 30
	7.2.2. Registrations ......................................34		5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 31
	7.3. Header Field Registration .................................34		5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 31
	8. Security Considerations ........................................35		6. Relationship to Applications . . . . . . . . . . . . . . . . 31
	9. Acknowledgments ................................................36		7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	10. References ....................................................36		7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 32
	10.1. Normative References .....................................36		7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 32
	10.2. Informative References ...................................37		7.3. Caching of Sensitive Information . . . . . . . . . . . . 33
	Appendix A. Changes from RFC 2616 .................................38		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
	Appendix B. Imported ABNF .........................................39		8.1. Header Field Registration . . . . . . . . . . . . . . . . 33
	Appendix C. Collected ABNF ........................................39		8.2. Cache Directive Registration . . . . . . . . . . . . . . 33
	Index .............................................................41		8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 33
			9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
			9.1. Normative References . . . . . . . . . . . . . . . . . . 33
			9.2. Informative References . . . . . . . . . . . . . . . . . 34
			Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
			Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 36
			Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36
			C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 36
			C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 37
			C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 37
			C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 37
			C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 38
			C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 38
			C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 38
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
			The Hypertext Transfer Protocol (HTTP) is a stateless application-
			level request/response protocol that uses extensible semantics and
			self-descriptive messages for flexible interaction with network-based
			hypertext information systems. HTTP is defined by a series of
			documents that collectively form the HTTP/1.1 specification:
			o "HTTP Semantics" [Semantics]
			o "HTTP Caching" (this document)
			o "HTTP/1.1 Messaging" [Messaging]
	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 related to caching and reusing
	response messages.		response messages.
	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 storage, retrieval, and deletion of messages in it. A		that controls storage, retrieval, and deletion of messages in it. A
	cache stores cacheable responses in order to reduce the response time		cache stores cacheable responses in order to reduce the response time
	and network bandwidth consumption on future, equivalent requests.		and network bandwidth consumption on future, equivalent requests.
	Any client or server MAY employ a cache, though a cache cannot be		Any client or server MAY employ a cache, though a cache cannot be
	used by a server that is acting as a tunnel.		used by a server that is acting as a tunnel.
	A shared cache is a cache that stores responses to be reused by more		A shared cache is a cache that stores responses to be reused by more
	than one user; shared caches are usually (but not always) deployed as		than one user; shared caches are usually (but not always) deployed as
	a part of an intermediary. A private cache, in contrast, is		a part of an intermediary. A private cache, in contrast, is
	dedicated to a single user; often, they are deployed as a component		dedicated to a single user; often, they are deployed as a component
	of a user agent.		of a user agent.
	The goal of caching in HTTP/1.1 is to significantly improve		The goal of caching in HTTP is to significantly improve performance
	performance by reusing a prior response message to satisfy a current		by reusing a prior response message to satisfy a current request. A
	request. A stored response is considered "fresh", as defined in		stored response is considered "fresh", as defined in Section 4.2, if
	Section 4.2, if the response can be reused without "validation"		the response can be reused without "validation" (checking with the
	(checking with the origin server to see if the cached response		origin server to see if the cached response remains valid for this
	remains valid for this request). A fresh response can therefore		request). A fresh response can therefore reduce both latency and
	reduce both latency and network overhead each time it is reused.		network overhead each time it is reused. When a cached response is
	When a cached response is not fresh, it might still be reusable if it		not fresh, it might still be reusable if it can be freshened by
	can be freshened by validation (Section 4.3) or if the origin is		validation (Section 4.3) or if the origin is unavailable
	unavailable (Section 4.2.4).		(Section 4.2.4).
	1.1. Conformance and Error Handling		This document obsoletes RFC 7234, with the changes being summarized
			in Appendix B.
			1.1. Requirements Notation
	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].
	Conformance criteria and considerations regarding error handling are		Conformance criteria and considerations regarding error handling are
	defined in Section 2.5 of [RFC7230].		defined in Section 3 of [Semantics].
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] with a list extension, defined in Section 7 of		notation of [RFC5234], extended with the notation for case-
	[RFC7230], that allows for compact definition of comma-separated		sensitivity in strings defined in [RFC7405].
	lists using a '#' operator (similar to how the '*' operator indicates
	repetition). Appendix B describes rules imported from other
	documents. Appendix C shows the collected grammar with all list
	operators expanded to standard ABNF notation.
	Appendix B. Imported ABNF		It also uses a list extension, defined in Section 12 of [Semantics],
			that allows for compact definition of comma-separated lists using a
			'#' operator (similar to how the '*' operator indicates repetition).
			Appendix A shows the collected grammar with all list operators
			expanded to standard ABNF notation.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any		HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
	8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII		feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
	character).		visible [USASCII] character).
	The rules below are defined in [RFC7230]:
	OWS = <OWS, see [RFC7230], Section 3.2.3>
	field-name = <field-name, see [RFC7230], Section 3.2>
	quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
	token = <token, see [RFC7230], Section 3.2.6>
	port = <port, see [RFC7230], Section 2.7>
	pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
	uri-host = <uri-host, see [RFC7230], Section 2.7>
	The rules below are defined in other parts:		The rules below are defined in [Semantics]:
	HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>		HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1>
			OWS = <OWS, see [Semantics], Section 11.1>
			field-name = <field-name, see [Semantics], Section 4.1>
			quoted-string = <quoted-string, see [Semantics], Section 4.2.3.2>
			token = <token, see [Semantics], Section 4.2.3.1>
	1.2.1. Delta Seconds		1.3. 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
	A recipient parsing a delta-seconds value and converting it to binary		A recipient parsing a delta-seconds value and converting it to binary
	form ought to use an arithmetic type of at least 31 bits of		form ought to use an arithmetic type of at least 31 bits of non-
	non-negative integer range. If a cache receives a delta-seconds		negative integer range. If a cache receives a delta-seconds value
	value greater than the greatest integer it can represent, or if any		greater than the greatest integer it can represent, or if any of its
	of its subsequent calculations overflows, the cache MUST consider the		subsequent calculations overflows, the cache MUST consider the value
	value to be either 2147483648 (2^31) or the greatest positive integer		to be either 2147483648 (2^31) or the greatest positive integer it
	it can conveniently represent.		can conveniently represent.
	Note: The value 2147483648 is here for historical reasons,		Note: The value 2147483648 is here for historical reasons,
	effectively represents infinity (over 68 years), and does not need		effectively represents infinity (over 68 years), and does not need
	to be stored in binary form; an implementation could produce it as		to be stored in binary form; an implementation could produce it as
	a canned string if any overflow occurs, even if the calculations		a canned string if any overflow occurs, even if the calculations
	are performed with an arithmetic type incapable of directly		are performed with an arithmetic type incapable of directly
	representing that number. What matters here is that an overflow		representing that number. What matters here is that an overflow
	be detected and not treated as a negative value in later		be detected and not treated as a negative value in later
	calculations.		calculations.
	2. Overview of 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
	([RFC7231]) while eliminating the transfer of information already		([Semantics]) while reducing the transfer of information already held
	held in the cache. Although caching is an entirely OPTIONAL feature		in the cache. Although caching is an entirely OPTIONAL feature of
	of HTTP, it can be assumed that reusing a cached response is		HTTP, it can be assumed that reusing a cached response is desirable
	desirable and that such reuse is the default behavior when no		and that such reuse is the default behavior when no requirement or
	requirement or local configuration prevents it. Therefore, HTTP		local configuration prevents it. Therefore, HTTP cache requirements
	cache requirements are focused on preventing a cache from either		are focused on preventing a cache from either storing a non-reusable
	storing a non-reusable response or reusing a stored response		response or reusing a stored response inappropriately, rather than
	inappropriately, rather than mandating that caches always store and		mandating that caches always store and reuse particular responses.
	reuse particular responses.
	Each cache entry consists of a cache key and one or more HTTP		The base cache key consists of the request method and target URI used
	responses corresponding to prior requests that used the same key.		to retrieve the stored response; the method determines under which
	The most common form of cache entry is a successful result of a		circumstances that response can be used to satisfy a request.
	retrieval request: i.e., a 200 (OK) response to a GET request, which		However, many HTTP caches in common use today only cache GET
	contains a representation of the resource identified by the request		responses, and therefore only use the URI as the cache key,
	target (Section 4.3.1 of [RFC7231]). However, it is also possible to		forwarding other methods.
	cache permanent redirects, negative results (e.g., 404 (Not Found)),
	incomplete results (e.g., 206 (Partial Content)), and responses to
	methods other than GET if the method's definition allows such caching
	and defines something suitable for use as a cache key.
	The primary cache key consists of the request method and target URI.		If a request target is subject to content negotiation, the cache
	However, since HTTP caches in common use today are typically limited		might store multiple responses for it. Caches differentiate these
	to caching responses to GET, many caches simply decline other methods		responses by incorporating values of the original request's selecting
	and use only the URI as the primary cache key.		header fields into the cache key as well, as per Section 4.1.
	If a request target is subject to content negotiation, its cache		Furthermore, caches might incorporate additional material into the
	entry might consist of multiple stored responses, each differentiated		cache key. For example, user agent caches might include the
	by a secondary key for the values of the original request's selecting		referring site's identity, thereby "double keying" the cache to avoid
	header fields (Section 4.1).		some privacy risks (see Section 7.2).
			Most commonly, caches store the successful result of a retrieval
			request: i.e., a 200 (OK) response to a GET request, which contains a
			representation of the resource identified by the request target
			(Section 7.3.1 of [Semantics]). However, it is also possible to
			store redirects, negative results (e.g., 404 (Not Found)), incomplete
			results (e.g., 206 (Partial Content)), and responses to methods other
			than GET if the method's definition allows such caching and defines
			something suitable for use as a cache key.
			A cache is disconnected when it cannot contact the origin server or
			otherwise find a forward path for a given request. A disconnected
			cache can serve stale responses in some circumstances
			(Section 4.2.4).
	3. Storing Responses in Caches		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
	cacheable, and
			o the response status code is final (see Section 9.3 of
			[Messaging]), 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 5.2) does not appear		o the "no-store" cache directive (see Section 5.2) does not appear
	in request or response header fields, and		in the response, and
	o the "private" response directive (see Section 5.2.2.6) does not		o the "private" response directive (see Section 5.2.2.6) does not
	appear in the response, if the cache is shared, and		appear in the response, if the cache is shared, and
	o the Authorization header field (see Section 4.2 of [RFC7235]) does		o the Authorization header field (see Section 8.5.3 of [Semantics])
	not appear in the request, if the cache is shared, unless the		does not appear in the request, if the cache is shared, unless the
	response explicitly allows it (see Section 3.2), 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 5.3), or		* contains an Expires header field (see Section 5.3), or
	* contains a max-age response directive (see Section 5.2.2.8), or		* contains a max-age response directive (see Section 5.2.2.8), or
	* contains a s-maxage response directive (see Section 5.2.2.9)		* contains a s-maxage response directive (see Section 5.2.2.9)
	and the cache is shared, or		and the cache is shared, or
	* contains a Cache Control Extension (see Section 5.2.3) that		* contains a Cache Control Extension (see Section 5.2.3) that
	allows it to be cached, or		allows it to be cached, or
	* has a status code that is defined as cacheable by default (see		* has a status code that is defined as heuristically cacheable
	Section 4.2.2), or		(see Section 4.2.2), or
	* contains a public response directive (see Section 5.2.2.5).		* contains a public response directive (see Section 5.2.2.5).
	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 5.2.3.		cache-control extension; see Section 5.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 all specified		response status code if it recognizes it and implements all specified
	caching-related behavior.		caching-related behavior.
	Note that, in normal operation, some caches will not store a response		Note that, in normal operation, some 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		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 ([RFC7230]) are received prior to		indicated by its framing are available. Note that, when no explicit
	the connection being closed. If the request method is GET, the		framing is provided, a response message that is ended by the
	response status code is 200 (OK), and the entire response header		connection's close is considered complete even though it might be
	section has been received, a cache MAY store an incomplete response		indistinguishable from an incomplete response (see [Messaging],
	message body if the cache entry is recorded as incomplete. Likewise,		Section 6.3). A cache SHOULD consider a close-terminated response
	a 206 (Partial Content) response MAY be stored as if it were an		incomplete if the connection termination is detected to be an error.
	incomplete 200 (OK) cache entry. However, a cache MUST NOT store		A server that wishes to avoid premature termination resulting in an
	incomplete or partial-content responses if it does not support the		incorrect cached response SHOULD send the response with explicit
	Range and Content-Range header fields or if it does not understand		framing.
	the range units used in those fields.
			If the request method is GET, the response status code is 200 (OK),
			and the entire response header section has been received, a cache MAY
			store an incomplete response message body if the stored response is
			recorded as incomplete. Likewise, a 206 (Partial Content) response
			MAY be stored as if it were an incomplete 200 (OK) response.
			However, a cache MUST NOT store incomplete or partial-content
			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.
	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 ([RFC7233]) and combining the successful		subsequent range request (Section 8.3 of [Semantics]) and combining
	response with the stored entry, as defined in Section 3.3. A cache		the successful response with the stored response, as defined in
	MUST NOT use an incomplete response to answer requests unless the		Section 3.3. A cache MUST NOT use an incomplete response to answer
	response has been made complete or the request is partial and		requests unless the response has been made complete or the request is
	specifies a range that is wholly within the incomplete response. A		partial and specifies a range that is wholly within the incomplete
	cache MUST NOT send a partial response to a client without explicitly		response. A cache MUST NOT send a partial response to a client
	marking it as such using the 206 (Partial Content) status code.		without explicitly marking it as such using the 206 (Partial Content)
			status code.
	3.2. Storing Responses to Authenticated Requests		3.2. Storing Responses to Authenticated Requests
	A shared cache MUST NOT use a cached response to a request with an		A shared cache MUST NOT use a cached response to a request with an
	Authorization header field (Section 4.2 of [RFC7235]) to satisfy any		Authorization header field (Section 8.5.3 of [Semantics]) to satisfy
	subsequent request unless a cache directive that allows such		any subsequent request unless a response directive that allows such
	responses to be stored is present in the response.		responses to be stored is present.
	In this specification, the following Cache-Control response		In this specification, the following Cache-Control response
	directives (Section 5.2.2) have such an effect: must-revalidate,		directives (Section 5.2.2) have such an effect: must-revalidate,
	public, and s-maxage.		public, and 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.2.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.
	3.3. Combining Partial Content		3.3. 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 ([RFC7233]). After several such transfers, a cache		Range specifiers (Section 8.3 of [Semantics]). After several such
	might have received several ranges of the same representation. A		transfers, a cache might have received several ranges of the same
	cache MAY combine these ranges into a single stored response, and		representation. A cache MAY combine these ranges into a single
	reuse that response to satisfy later requests, if they all share the		stored response, and reuse that response to satisfy later requests,
	same strong validator and the cache complies with the client		if they all share the same strong validator and the cache complies
	requirements in Section 4.3 of [RFC7233].		with the client requirements in Section 9.3.7.3 of [Semantics].
	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 use the header fields provided in the new response, aside
			from Content-Range, to replace all instances of the corresponding
	o delete any Warning header fields in the stored response with		header fields in the stored response.
	warn-code 1xx (see Section 5.5);
	o retain any Warning header fields in the stored response with
	warn-code 2xx; and,
	o use other header fields provided in the new response, aside from
	Content-Range, to replace all instances of the corresponding
	header fields in the stored response.
	4. Constructing Responses from Caches		4. Constructing Responses from Caches
	When presented with a request, a cache MUST NOT reuse a stored		When presented with a request, a cache MUST NOT reuse a stored
	response, unless:		response, unless:
	o The presented effective request URI (Section 5.5 of [RFC7230]) and		o The presented effective request URI (Section 5.3 of [Semantics])
	that of the stored response match, and		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 4.1), and		match those presented (see Section 4.1), and
	o the presented request does not contain the no-cache pragma
	(Section 5.4), nor the no-cache cache directive (Section 5.2.1),
	unless the stored response is successfully validated
	(Section 4.3), 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 5.2.2.2), unless it is successfully validated		(Section 5.2.2.2), unless it is successfully validated
	(Section 4.3), and		(Section 4.3), and
	o the stored response is either:		o the stored response is either:
	* fresh (see Section 4.2), or		* fresh (see Section 4.2), or
	* allowed to be served stale (see Section 4.2.4), or		* allowed to be served stale (see Section 4.2.4), or
	skipping to change at line 407 ¶		skipping to change at page 10, line 29 ¶
	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 5.2.3.		cache-control extension; see Section 5.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 generate an Age header field (Section 5.1),		validation, a cache MUST generate an Age header field (Section 5.1),
	replacing any present in the response with a value equal to the		replacing any present in the response with a value equal to the
	stored response's current_age; see Section 4.2.3.		stored response's current_age; see Section 4.2.3.
	A cache MUST write through requests with methods that are unsafe		A cache MUST write through requests with methods that are unsafe
	(Section 4.2.1 of [RFC7231]) to the origin server; i.e., a cache is		(Section 7.2.1 of [Semantics]) to the origin server; i.e., a cache is
	not allowed to generate a reply to such a request before having		not allowed to generate a reply to such a request before having
	forwarded the request and having received a corresponding response.		forwarded 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 4.4.		responses; see Section 4.4.
	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 one (as determined by the Date header field). It can
	can also forward the request with "Cache-Control: max-age=0" or		also forward the request with "Cache-Control: max-age=0" or "Cache-
	"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 upon every use.		responses without revalidating them upon every use.
	4.1. Calculating Secondary Keys with Vary		4.1. Calculating Cache Keys with Vary
	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 7.1.4 of [RFC7231]),		response that has a Vary header field (Section 10.1.4 of
	it MUST NOT use that response unless all of the selecting header		[Semantics]), it MUST NOT use that response unless all of the
	fields nominated by the Vary header field match in both the original		selecting header fields nominated by the Vary header field match in
	request (i.e., that associated with the stored response), and the		both the original request (i.e., that associated with the stored
	presented request.		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
	o combining multiple header fields with the same field name (see		o combining multiple header fields with the same field name (see
	Section 3.2 of [RFC7230])		Section 4.2 of [Semantics])
	o normalizing both header field values in a way that is known to		o normalizing both header field values in a way that is known to
	have identical semantics, according to the header field's		have identical semantics, according to the header field's
	specification (e.g., reordering field values when order is not		specification (e.g., reordering field values when order is not
	significant; case-normalization, where values are defined to be		significant; case-normalization, where values are defined to be
	case-insensitive)		case-insensitive)
	If (after any normalization that might take place) a header field is		If (after any normalization that might take place) a header field is
	absent from a request, it can only match another request if it is		absent from a request, it can only match another request if it is
	also absent there.		also absent there.
	skipping to change at line 464 ¶		skipping to change at page 11, line 41 ¶
	the selected response.		the selected response.
	If multiple selected responses are available (potentially including		If multiple selected responses are available (potentially including
	responses without a Vary header field), the cache will need to choose		responses without a Vary header field), the cache will need to choose
	one to use. When a selecting header field has a known mechanism for		one to use. When a selecting header field has a known mechanism for
	doing so (e.g., qvalues on Accept and similar request header fields),		doing so (e.g., qvalues on Accept and similar request header fields),
	that mechanism MAY be used to select preferred responses; of the		that mechanism MAY be used to select preferred responses; of the
	remainder, the most recent response (as determined by the Date header		remainder, the most recent response (as determined by the Date header
	field) is used, as per Section 4.		field) is used, as per Section 4.
			Note that in practice, some resources might send the Vary header
			field on responses inconsistently. When a cache has multiple
			responses for a given target URI, and one or more omits the Vary
			header field, it SHOULD use the most recent non-empty value available
			to select an appropriate response for the request.
	If no selected response is available, the cache cannot satisfy the		If no selected response is available, the cache cannot satisfy the
	presented request. Typically, it is forwarded to the origin server		presented request. Typically, it is forwarded to the origin server
	in a (possibly conditional; see Section 4.3) request.		in a (possibly conditional; see Section 4.3) request.
	4.2. Freshness		4.2. Freshness
	A fresh response is one whose age has not yet exceeded its freshness		A fresh response is one whose age has not yet exceeded its freshness
	lifetime. Conversely, a stale response is one where it has.		lifetime. Conversely, a stale response is one where it has.
	A response's freshness lifetime is the length of time between its		A response's freshness lifetime is the length of time between its
	skipping to change at line 512 ¶		skipping to change at page 12, line 49 ¶
	caches are also allowed to use a heuristic to determine an expiration		caches are also allowed to use a heuristic to determine an expiration
	time under certain circumstances (see Section 4.2.2).		time under certain circumstances (see Section 4.2.2).
	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)
	freshness_lifetime is defined in Section 4.2.1; current_age is		freshness_lifetime is defined in Section 4.2.1; current_age is
	defined in Section 4.2.3.		defined in Section 4.2.3.
	Clients can send the max-age or min-fresh cache directives in a		Clients can send the max-age or min-fresh request directives
	request to constrain or relax freshness calculations for the		(Section 5.2.1) to constrain or relax freshness calculations for the
	corresponding response (Section 5.2.1).		corresponding response. However, caches are not required to honor
			them.
	When calculating freshness, to avoid common problems in date parsing:		When calculating freshness, to avoid common problems in date parsing:
	o Although all date formats are specified to be case-sensitive, a		o Although all date formats are specified to be case-sensitive, a
	cache recipient SHOULD match day, week, and time-zone names		cache recipient SHOULD match day, week, and time-zone names case-
	case-insensitively.		insensitively.
	o If a cache recipient's internal implementation of time has less		o If a cache recipient's internal implementation of time has less
	resolution than the value of an HTTP-date, the recipient MUST		resolution than the value of an HTTP-date, the recipient MUST
	internally represent a parsed Expires date as the nearest time		internally represent a parsed Expires date as the nearest time
	equal to or earlier than the received value.		equal to or earlier than the received value.
	o A cache recipient MUST NOT allow local time zones to influence the		o A cache recipient MUST NOT allow local time zones to influence the
	calculation or comparison of an age or expiration time.		calculation or comparison of an age or expiration time.
	o A cache recipient SHOULD consider a date with a zone abbreviation		o A cache recipient SHOULD consider a date with a zone abbreviation
	skipping to change at line 579 ¶		skipping to change at page 14, line 20 ¶
	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.
	A cache MUST NOT use heuristics to determine freshness when an		A cache MUST NOT use heuristics to determine freshness when an
	explicit expiration time is present in the stored response. Because		explicit expiration time is present in the stored response. Because
	of the requirements in Section 3, this means that, effectively,		of the requirements in Section 3, this means that, effectively,
	heuristics can only be used on responses without explicit freshness		heuristics can only be used on responses without explicit freshness
	whose status codes are defined as cacheable by default (see Section		whose status codes are defined as "heuristically cacheable" (e.g.,
	6.1 of [RFC7231]), and those responses without explicit freshness		see Section 9.1 of [Semantics]), and those responses without explicit
	that have been marked as explicitly cacheable (e.g., with a "public"		freshness that have been marked as explicitly cacheable (e.g., with a
	response directive).		"public" response directive).
	If the response has a Last-Modified header field (Section 2.2 of		Note that in previous specifications heuristically cacheable response
	[RFC7232]), caches are encouraged to use a heuristic expiration value		status codes were called "cacheable by default."
	that is no more than some fraction of the interval since that time.
	A typical setting of this fraction might be 10%.
	When a heuristic is used to calculate freshness lifetime, a cache		If the response has a Last-Modified header field (Section 10.2.2 of
	SHOULD generate a Warning header field with a 113 warn-code (see		[Semantics]), caches are encouraged to use a heuristic expiration
	Section 5.5.4) in the response if its current_age is more than 24		value that is no more than some fraction of the interval since that
	hours and such a warning is not already present.		time. A typical setting of this fraction might be 10%.
	Note: Section 13.9 of [RFC2616] prohibited caches from calculating		Note: Section 13.9 of [RFC2616] prohibited caches from calculating
	heuristic freshness for URIs with query components (i.e., those		heuristic freshness for URIs with query components (i.e., those
	containing '?'). In practice, this has not been widely		containing '?'). In practice, this has not been widely
	implemented. Therefore, origin servers are encouraged to send		implemented. Therefore, origin servers are encouraged to send
	explicit directives (e.g., Cache-Control: no-cache) if they wish		explicit directives (e.g., Cache-Control: no-cache) if they wish
	to preclude caching.		to preclude caching.
	4.2.3. Calculating Age		4.2.3. Calculating Age
	The Age header field is used to convey an estimated age of the		The Age header field is used to convey an 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 number of seconds since the response was		the cache's estimate of the number of seconds 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 (Section 5.1), in a form appropriate for arithmetic
	The term "age_value" denotes the value of the Age header field		operation; or 0, if not available.
	(Section 5.1), in a form appropriate for arithmetic operation; or
	0, if not available.
	date_value
	The term "date_value" denotes the value of the Date header field,
	in a form appropriate for arithmetic operations. See Section
	7.1.1.2 of [RFC7231] for the definition of the Date header field,
	and for requirements regarding responses without it.
	now		date_value The term "date_value" denotes the value of the Date
			header field, in a form appropriate for arithmetic operations.
			See Section 10.1.1.2 of [Semantics] for the definition of the Date
			header field, and for requirements regarding responses without it.
	The term "now" means "the current value of the clock at the host		now The term "now" means "the current value of the clock at the host
	performing the calculation". A host ought to use NTP ([RFC5905])		performing the calculation". A host ought to use NTP ([RFC5905])
	or some similar protocol to synchronize its clocks to Coordinated		or some similar protocol to synchronize its clocks to Coordinated
	Universal Time.		Universal Time.
	request_time		request_time The current value of the clock at the host at the time
			the request resulting in the stored response was made.
	The current value of the clock at the host at the time the request
	resulting in the stored response was made.
	response_time
	The current value of the clock at the host at the time the		response_time The current value of the clock at the host at the time
	response was received.		the response was received.
	A response's age can be calculated in two entirely independent ways:		A response's age can be calculated in two entirely independent ways:
	1. the "apparent_age": response_time minus date_value, if the local		1. the "apparent_age": response_time minus date_value, if the local
	clock is reasonably well synchronized to the origin server's		clock is reasonably well synchronized to the origin server's
	clock. If the result is negative, the result is replaced by		clock. If the result is negative, the result is replaced by
	zero.		zero.
	2. the "corrected_age_value", if all of the caches along the		2. the "corrected_age_value", if all of the caches along the
	response path implement HTTP/1.1. A cache MUST interpret this		response path implement HTTP/1.1 or greater. A cache MUST
	value relative to the time the request was initiated, not the		interpret this value relative to the time the request was
	time that the response was received.		initiated, not the time that the response was received.
	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 are combined as		These are combined as
	corrected_initial_age = max(apparent_age, corrected_age_value);		corrected_initial_age = max(apparent_age, corrected_age_value);
	skipping to change at line 688 ¶		skipping to change at page 16, line 24 ¶
	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 4.2.		according to the calculations in Section 4.2.
	A cache MUST NOT generate a stale response if it is prohibited by an		A cache MUST NOT generate 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 5.2.2).		see Section 5.2.2).
	A cache MUST NOT send stale responses unless it is disconnected		A cache MUST NOT generate a stale response unless it is disconnected
	(i.e., it cannot contact the origin server or otherwise find a		or doing so is explicitly permitted by the client or origin server
	forward path) or doing so is explicitly allowed (e.g., by the		(e.g., by the max-stale request directive in Section 5.2.1, by
	max-stale request directive; see Section 5.2.1).		extension directives such as those defined in [RFC5861], or by
			configuration in accordance with an out-of-band contract).
	A cache SHOULD generate a Warning header field with the 110 warn-code
	(see Section 5.5.1) in stale responses. Likewise, a cache SHOULD
	generate a 112 warn-code (see Section 5.5.3) in stale responses if
	the cache is disconnected.
	A cache SHOULD NOT generate a new Warning header field when
	forwarding a response that does not have an Age header field, even if
	the response is already stale. A cache need not validate a response
	that merely became stale in transit.
	4.3. Validation		4.3. Validation
	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 4.1), it can use the conditional		one cannot be selected; see Section 4.1), it can use the conditional
	request mechanism [RFC7232] in the forwarded request to give the next		request mechanism Section 8.2 of [Semantics] in the forwarded request
	inbound server an opportunity to select a valid stored response to		to give the next inbound server an opportunity to select a valid
	use, updating the stored metadata in the process, or to replace the		stored response to use, updating the stored metadata in the process,
	stored response(s) with a new response. This process is known as		or to replace the stored response(s) with a new response. This
	"validating" or "revalidating" the stored response.		process is known as "validating" or "revalidating" the stored
			response.
	4.3.1. Sending a Validation Request		4.3.1. Sending a Validation Request
	When sending a conditional request for cache validation, a cache		When generating a conditional request for validation, a cache starts
	sends one or more precondition header fields containing validator		with either a request it is attempting to satisfy, or -- if it is
	metadata from its stored response(s), which is then compared by		initiating the request independently -- it synthesises a request
	recipients to determine whether a stored response is equivalent to a		using a stored response by copying the method, request-target, and
	current representation of the resource.		request header fields identified by the Vary header field
			Section 4.1.
			It then updates that request with one or more precondition header
			fields. These contain validator metadata sourced from stored
			response(s) that have the same cache key.
			The precondition header fields are then compared by recipients to
			determine whether any stored response is equivalent to a current
			representation of the resource.
	One such validator is the timestamp given in a Last-Modified header		One such validator is the timestamp given in a Last-Modified header
	field (Section 2.2 of [RFC7232]), which can be used in an		field (Section 10.2.2 of [Semantics]), which can be used in an If-
	If-Modified-Since header field for response validation, or in an		Modified-Since header field for response validation, or in an If-
	If-Unmodified-Since or If-Range header field for representation		Unmodified-Since or If-Range header field for representation
	selection (i.e., the client is referring specifically to a previously		selection (i.e., the client is referring specifically to a previously
	obtained representation with that timestamp).		obtained representation with that timestamp).
	Another validator is the entity-tag given in an ETag header field		Another validator is the entity-tag given in an ETag header field
	(Section 2.3 of [RFC7232]). One or more entity-tags, indicating one		(Section 10.2.3 of [Semantics]). One or more entity-tags, indicating
	or more stored responses, can be used in an If-None-Match header		one or more stored responses, can be used in an If-None-Match header
	field for response validation, or in an If-Match or If-Range header		field for response validation, or in an If-Match or If-Range header
	field for representation selection (i.e., the client is referring		field for representation selection (i.e., the client is referring
	specifically to one or more previously obtained representations with		specifically to one or more previously obtained representations with
	the listed entity-tags).		the listed entity-tags).
	4.3.2. Handling a Received Validation Request		4.3.2. Handling a Received Validation Request
	Each client in the request chain may have its own cache, so it is		Each client in the request chain may have its own cache, so it is
	common for a cache at an intermediary to receive conditional requests		common for a cache at an intermediary to receive conditional requests
	from other (outbound) caches. Likewise, some user agents make use of		from other (outbound) caches. Likewise, some user agents make use of
	skipping to change at line 759 ¶		skipping to change at page 17, line 50 ¶
	received in that request with respect to the corresponding validators		received in that request with respect to the corresponding validators
	contained within the selected response. A cache MUST NOT evaluate		contained within the selected response. A cache MUST NOT evaluate
	conditional header fields that are only applicable to an origin		conditional header fields that are only applicable to an origin
	server, found in a request with semantics that cannot be satisfied		server, found in a request with semantics that cannot be satisfied
	with a cached response, or applied to a target resource for which it		with a cached response, or applied to a target resource for which it
	has no stored responses; such preconditions are likely intended for		has no stored responses; such preconditions are likely intended for
	some other (inbound) server.		some other (inbound) server.
	The proper evaluation of conditional requests by a cache depends on		The proper evaluation of conditional requests by a cache depends on
	the received precondition header fields and their precedence, as		the received precondition header fields and their precedence, as
	defined in Section 6 of [RFC7232]. The If-Match and		defined in Section 8.2.2 of [Semantics]. The If-Match and If-
	If-Unmodified-Since conditional header fields are not applicable to a		Unmodified-Since conditional header fields are not applicable to a
	cache.		cache.
	A request containing an If-None-Match header field (Section 3.2 of		A request containing an If-None-Match header field (Section 8.2.4 of
	[RFC7232]) indicates that the client wants to validate one or more of		[Semantics]) indicates that the client wants to validate one or more
	its own stored responses in comparison to whichever stored response		of its own stored responses in comparison to whichever stored
	is selected by the cache. If the field-value is "*", or if the		response is selected by the cache. If the field-value is "*", or if
	field-value is a list of entity-tags and at least one of them matches		the field-value is a list of entity-tags and at least one of them
	the entity-tag of the selected stored response, a cache recipient		matches the entity-tag of the selected stored response, a cache
	SHOULD generate a 304 (Not Modified) response (using the metadata of		recipient SHOULD generate a 304 (Not Modified) response (using the
	the selected stored response) instead of sending that stored		metadata of the selected stored response) instead of sending that
	response.		stored response.
	When a cache decides to revalidate its own stored responses for a		When a cache decides to revalidate its own stored responses for a
	request that contains an If-None-Match list of entity-tags, the cache		request that contains an If-None-Match list of entity-tags, the cache
	MAY combine the received list with a list of entity-tags from its own		MAY combine the received list with a list of entity-tags from its own
	stored set of responses (fresh or stale) and send the union of the		stored set of responses (fresh or stale) and send the union of the
	two lists as a replacement If-None-Match header field value in the		two lists as a replacement If-None-Match header field value in the
	forwarded request. If a stored response contains only partial		forwarded request. If a stored response contains only partial
	content, the cache MUST NOT include its entity-tag in the union		content, the cache MUST NOT include its entity-tag in the union
	unless the request is for a range that would be fully satisfied by		unless the request is for a range that would be fully satisfied by
	that partial stored response. If the response to the forwarded		that partial stored response. If the response to the forwarded
	request is 304 (Not Modified) and has an ETag header field value with		request is 304 (Not Modified) and has an ETag header field value with
	an entity-tag that is not in the client's list, the cache MUST		an entity-tag that is not in the client's list, the cache MUST
	generate a 200 (OK) response for the client by reusing its		generate a 200 (OK) response for the client by reusing its
	corresponding stored response, as updated by the 304 response		corresponding stored response, as updated by the 304 response
	metadata (Section 4.3.4).		metadata (Section 4.3.4).
	If an If-None-Match header field is not present, a request containing		If an If-None-Match header field is not present, a request containing
	an If-Modified-Since header field (Section 3.3 of [RFC7232])		an If-Modified-Since header field (Section 8.2.5 of [Semantics])
	indicates that the client wants to validate one or more of its own		indicates that the client wants to validate one or more of its own
	stored responses by modification date. A cache recipient SHOULD		stored responses by modification date. A cache recipient SHOULD
	generate a 304 (Not Modified) response (using the metadata of the		generate a 304 (Not Modified) response (using the metadata of the
	selected stored response) if one of the following cases is true: 1)		selected stored response) if one of the following cases is true: 1)
	the selected stored response has a Last-Modified field-value that is		the selected stored response has a Last-Modified field-value that is
	earlier than or equal to the conditional timestamp; 2) no		earlier than or equal to the conditional timestamp; 2) no Last-
	Last-Modified field is present in the selected stored response, but		Modified field is present in the selected stored response, but it has
	it has a Date field-value that is earlier than or equal to the		a Date field-value that is earlier than or equal to the conditional
	conditional timestamp; or, 3) neither Last-Modified nor Date is		timestamp; or, 3) neither Last-Modified nor Date is present in the
	present in the selected stored response, but the cache recorded it as		selected stored response, but the cache recorded it as having been
	having been received at a time earlier than or equal to the		received at a time earlier than or equal to the conditional
	conditional timestamp.		timestamp.
	A cache that implements partial responses to range requests, as		A cache that implements partial responses to range requests, as
	defined in [RFC7233], also needs to evaluate a received If-Range		defined in Section 8.3 of [Semantics], also needs to evaluate a
	header field (Section 3.2 of [RFC7233]) with respect to its selected		received If-Range header field (Section 8.2.7 of [Semantics]) with
	stored response.		respect to its selected stored response.
	4.3.3. Handling a Validation Response		4.3.3. Handling a Validation 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 4.3.4.		stored response can be updated and reused; see Section 4.3.4.
	o A full response (i.e., one with a payload body) indicates that		o A full response (i.e., one with a payload body) indicates that
	skipping to change at line 830 ¶		skipping to change at page 19, line 27 ¶
	o However, if a cache receives a 5xx (Server Error) response while		o However, if a cache receives a 5xx (Server Error) response while
	attempting to validate a response, it can either forward this		attempting to validate a response, it can either forward this
	response to the requesting client, or act as if the server failed		response to the requesting client, or act as if the server failed
	to respond. In the latter case, the cache MAY send a previously		to respond. In the latter case, the cache MAY send a previously
	stored response (see Section 4.2.4).		stored response (see Section 4.2.4).
	4.3.4. Freshening Stored Responses upon Validation		4.3.4. Freshening Stored Responses upon Validation
	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 applicable cache key,
	cache needs to identify which of the stored responses are updated by		the cache needs to identify which (if any) are to be updated by the
	this new response and then update the stored response(s) with the new		new information provided, and then do so.
	information provided in the 304 response.
	The stored response to update is identified by using the first match		The stored response(s) to update are identified by using the first
	(if any) of the following:		match (if any) of the following:
	o If the new response contains a strong validator (see Section 2.1		o If the new response contains a strong validator (see
	of [RFC7232]), then that strong validator identifies the selected		Section 10.2.1 of [Semantics]), then that strong validator
	representation for update. All of the stored responses with the		identifies the selected representation for update. All of the
	same strong validator are selected. If none of the stored		stored responses with the same strong validator are identified for
	responses contain the same strong validator, then the cache MUST		update. If none of the stored responses contain the same strong
	NOT use the new response to update any stored responses.		validator, then the cache MUST NOT use the new response to update
			any stored responses.
	o If the new response contains a weak validator and that validator		o If the new response contains a weak validator and that validator
	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 for update.		recent of those matching stored responses is identified for
			update.
	o If the new response does not include any form of validator (such		o If the new response does not include any form of validator (such
	as in the case where a client generates an If-Modified-Since		as in the case where a client generates an If-Modified-Since
	request from a source other than the Last-Modified response header		request from a source other than the Last-Modified response header
	field), and there is only one stored response, and that stored		field), and there is only one stored response, and that stored
	response also lacks a validator, then that stored response is		response also lacks a validator, then that stored response is
	selected for update.		identified for update.
	If a stored response is selected for update, the cache MUST:
	o delete any Warning header fields in the stored response with
	warn-code 1xx (see Section 5.5);
	o retain any Warning header fields in the stored response with
	warn-code 2xx; and,
	o use other header fields provided in the 304 (Not Modified)		For each stored response identified for update, the cache MUST use
	response to replace all instances of the corresponding header		the header fields provided in the 304 (Not Modified) response to
	fields in the stored response.		replace all instances of the corresponding header fields in the
			stored response.
	4.3.5. Freshening Responses via HEAD		4.3.5. Freshening Responses with HEAD
	A response to the HEAD method is identical to what an equivalent		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.		request made with a GET would have been, except it lacks a body.
	This property of HEAD responses can be used to invalidate or update a		This property of HEAD responses can be used to invalidate or update a
	cached GET response if the more efficient conditional GET request		cached GET response if the more efficient conditional GET request
	mechanism is not available (due to no validators being present in the		mechanism is not available (due to no validators being present in the
	stored response) or if transmission of the representation body is not		stored response) or if transmission of the representation body is not
	desired even if it has changed.		desired even if it has changed.
	When a cache makes an inbound HEAD request for a given request target		When a cache makes an inbound HEAD request for a given request target
	and receives a 200 (OK) response, the cache SHOULD update or		and receives a 200 (OK) response, the cache SHOULD update or
	invalidate each of its stored GET responses that could have been		invalidate each of its stored GET responses that could have been
	selected for that request (see Section 4.1).		selected for that request (see Section 4.1).
	For each of the stored responses that could have been selected, if		For each of the stored responses that could have been selected, if
	the stored response and HEAD response have matching values for any		the stored response and HEAD response have matching values for any
	received validator fields (ETag and Last-Modified) and, if the HEAD		received validator fields (ETag and Last-Modified) and, if the HEAD
	response has a Content-Length header field, the value of		response has a Content-Length header field, the value of Content-
	Content-Length matches that of the stored response, the cache SHOULD		Length matches that of the stored response, the cache SHOULD update
	update the stored response as described below; otherwise, the cache		the stored response as described below; otherwise, the cache SHOULD
	SHOULD consider the stored response to be stale.		consider the stored response to be stale.
	If a cache updates a stored response with the metadata provided in a		If a cache updates a stored response with the metadata provided in a
	HEAD response, the cache MUST:		HEAD response, the cache MUST use the header fields provided in the
			HEAD response to replace all instances of the corresponding header
	o delete any Warning header fields in the stored response with		fields in the stored response and append new header fields to the
	warn-code 1xx (see Section 5.5);		stored response's header section unless otherwise restricted by the
			Cache-Control header field.
	o retain any Warning header fields in the stored response with
	warn-code 2xx; and,
	o use other header fields provided in the HEAD response to replace
	all instances of the corresponding header fields in the stored
	response and append new header fields to the stored response's
	header section unless otherwise restricted by the Cache-Control
	header field.
	4.4. Invalidation		4.4. Invalidation
	Because unsafe request methods (Section 4.2.1 of [RFC7231]) such as		Because unsafe request methods (Section 7.2.1 of [Semantics]) such as
	PUT, POST or DELETE have the potential for changing state on the		PUT, POST or DELETE have the potential for changing state on the
	origin server, intervening caches can use them to keep their contents		origin server, intervening caches can use them to keep their contents
	up to date.		up to date.
	A cache MUST invalidate the effective Request URI (Section 5.5 of		A cache MUST invalidate the effective Request URI (Section 5.3 of
	[RFC7230]) as well as the URI(s) in the Location and Content-Location		[Semantics]) as well as the URI(s) in the Location and Content-
	response header fields (if present) when a non-error status code is		Location response header fields (if present) when a non-error status
	received in response to an unsafe request method.		code is received in response to an unsafe request method.
	However, a cache MUST NOT invalidate a URI from a Location or		However, a cache MUST NOT invalidate a URI from a Location or
	Content-Location response header field if the host part of that URI		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		differs from the host part in the effective request URI (Section 5.3
	of [RFC7230]). This helps prevent denial-of-service attacks.		of [Semantics]). This helps prevent denial-of-service attacks.
	A cache MUST invalidate the effective request URI (Section 5.5 of		A cache MUST invalidate the effective request URI (Section 5.3 of
	[RFC7230]) when it receives a non-error response to a request with a		[Semantics]) when it receives a non-error response to a request with
	method whose safety is unknown.		a method whose safety is unknown.
	Here, a "non-error response" is one with a 2xx (Successful) or 3xx		Here, a "non-error response" is one with a 2xx (Successful) or 3xx
	(Redirection) status code. "Invalidate" means that the cache will		(Redirection) status code. "Invalidate" means that the cache will
	either remove all stored responses related to the effective request		either remove all stored responses related to the effective request
	URI or will mark these as "invalid" and in need of a mandatory		URI or will mark these as "invalid" and in need of a mandatory
	validation before they can be sent in response to a subsequent		validation before they can be sent in response to a subsequent
	request.		request.
	Note that this does not guarantee that all appropriate responses are		Note that this does not guarantee that all appropriate responses are
	invalidated. For example, a state-changing request might invalidate		invalidated. For example, a state-changing request might invalidate
	responses in the caches it travels through, but relevant responses		responses in the caches it travels through, but relevant responses
	still might be stored in other caches that it has not.		still might be stored in other caches that it has not.
	5. Header Field Definitions		5. Header Field Definitions
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP header fields
	fields related to caching.		related to caching.
	+-------------------+----------+----------+-------------+		+-------------------+-----------+--------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Status | Reference |
	+-------------------+----------+----------+-------------+		+-------------------+-----------+--------------+
	| Age | http | standard | Section 5.1 |		| Age | standard | Section 5.1 |
	| Cache-Control | http | standard | Section 5.2 |		| Cache-Control | standard | Section 5.2 |
	| Expires | http | standard | Section 5.3 |		| Expires | standard | Section 5.3 |
	| Pragma | http | standard | Section 5.4 |		| Pragma | standard | Section 5.4 |
	| Warning | http | standard | Section 5.5 |		| Warning | obsoleted | Section 5.5 |
	+-------------------+----------+----------+-------------+		+-------------------+-----------+--------------+
			Table 1
	5.1. Age		5.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 4.2.3.		Section 4.2.3.
	Age = delta-seconds		Age = delta-seconds
	The Age field-value is a non-negative integer, representing time in		The Age field-value is a non-negative integer, representing time in
	seconds (see Section 1.2.1).		seconds (see Section 1.3).
	The presence of an Age header field implies that the response was not		The presence of an Age header field implies that the response was not
	generated or validated by the origin server for this request.		generated or validated by the origin server for this request.
	However, lack of an Age header field does not imply the origin was		However, lack of an Age header field does not imply the origin was
	contacted, since the response might have been received from an		contacted, since the response might have been received from an
	HTTP/1.0 cache that does not implement Age.		HTTP/1.0 cache that does not implement Age.
	5.2. Cache-Control		5.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 present in the response, or to
			be repeated in it.
	A cache MUST obey the requirements of the Cache-Control directives		See Section 5.2.3 for information about how Cache-Control directives
	defined in this section. See Section 5.2.3 for information about how		defined elsewhere are handled.
	Cache-Control directives defined elsewhere are handled.
	Note: Some HTTP/1.0 caches might not implement Cache-Control.		Note: Some HTTP/1.0 caches might not implement Cache-Control.
	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		Cache directives are identified by a token, to be compared case-
	case-insensitively, and have an optional argument, that can use both		insensitively, and have an optional argument, that can use both token
	token and quoted-string syntax. For the directives defined below		and quoted-string syntax. For the directives defined below that
	that define arguments, recipients ought to accept both forms, even if		define arguments, recipients ought to accept both forms, even if one
	one is documented to be preferred. For any directive not defined by		is documented to be preferred. For any directive not defined by this
	this specification, a recipient MUST accept both forms.		specification, a recipient MUST accept both forms.
	Cache-Control = 1#cache-directive		Cache-Control = 1#cache-directive
	cache-directive = token [ "=" ( token / quoted-string ) ]		cache-directive = token [ "=" ( token / quoted-string ) ]
	For the cache directives defined below, no argument is defined (nor		For the cache directives defined below, no argument is defined (nor
	allowed) unless stated otherwise.		allowed) unless stated otherwise.
	+------------------------+----------------------------------+		+------------------+-----------------------------------+
	| Cache Directive | Reference |		| Cache Directive | Reference |
	+------------------------+----------------------------------+		+------------------+-----------------------------------+
	| max-age | Section 5.2.1.1, Section 5.2.2.8 |		| max-age | Section 5.2.1.1, Section 5.2.2.8 |
	| max-stale | Section 5.2.1.2 |		| max-stale | Section 5.2.1.2 |
	| min-fresh | Section 5.2.1.3 |		| min-fresh | Section 5.2.1.3 |
	| must-revalidate | Section 5.2.2.1 |		| must-revalidate | Section 5.2.2.1 |
	| no-cache | Section 5.2.1.4, Section 5.2.2.2 |		| no-cache | Section 5.2.1.4, Section 5.2.2.2 |
	| no-store | Section 5.2.1.5, Section 5.2.2.3 |		| no-store | Section 5.2.1.5, Section 5.2.2.3 |
	| no-transform | Section 5.2.1.6, Section 5.2.2.4 |		| no-transform | Section 5.2.1.6, Section 5.2.2.4 |
	| only-if-cached | Section 5.2.1.7 |		| only-if-cached | Section 5.2.1.7 |
	| private | Section 5.2.2.6 |		| private | Section 5.2.2.6 |
	| proxy-revalidate | Section 5.2.2.7 |		| proxy-revalidate | Section 5.2.2.7 |
	| public | Section 5.2.2.5 |		| public | Section 5.2.2.5 |
	| s-maxage | Section 5.2.2.9 |		| s-maxage | Section 5.2.2.9 |
	| stale-if-error | [RFC5861], Section 4 |		+------------------+-----------------------------------+
	| stale-while-revalidate | [RFC5861], Section 3 |
	+------------------------+----------------------------------+		Table 2
	5.2.1. Request Cache-Control Directives		5.2.1. Request Cache-Control Directives
			This section defines cache request directives. They are advisory;
			caches MAY implement them, but are not required to.
	5.2.1.1. max-age		5.2.1.1. max-age
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.3)
	The "max-age" request directive indicates that the client is		The "max-age" request directive indicates that the client prefers a
	unwilling to accept a response whose age is greater than the		response whose age is less than or equal to the specified number of
	specified number of seconds. Unless the max-stale request directive		seconds. Unless the max-stale request directive is also present, the
	is also present, the client is not willing to accept a stale		client does not wish to receive a stale response.
	response.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the		'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the
	quoted-string form.		quoted-string form.
	5.2.1.2. max-stale		5.2.1.2. max-stale
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.3)
	The "max-stale" request directive indicates that the client is		The "max-stale" request directive indicates that the client is
	willing to accept a response that has exceeded its freshness		willing to accept a response that has exceeded its freshness
	lifetime. If max-stale is assigned a value, then the client is		lifetime. If a value is present, then the client is willing to
	willing to accept a response that has exceeded its freshness lifetime		accept a response that has exceeded its freshness lifetime by no more
	by no more than the specified number of seconds. If no value is		than the specified number of seconds. If no value is assigned to
	assigned to max-stale, then the client is willing to accept a stale		max-stale, then the client is willing to accept a stale response of
	response of any age.		any age.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate		'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate
	the quoted-string form.		the quoted-string form.
	5.2.1.3. min-fresh		5.2.1.3. min-fresh
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.3)
	The "min-fresh" request directive indicates that the client is		The "min-fresh" request directive indicates that the client prefers a
	willing to accept a response whose freshness lifetime is no less than		response whose freshness lifetime is no less than its current age
	its current age plus the specified time in seconds. That is, the		plus the specified time in seconds. That is, the client wants a
	client wants a response that will still be fresh for at least the		response that will still be fresh for at least the specified number
	specified number of seconds.		of seconds.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate		'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate
	the quoted-string form.		the quoted-string form.
	5.2.1.4. no-cache		5.2.1.4. no-cache
	The "no-cache" request directive indicates that a cache MUST NOT use		The "no-cache" request directive indicates that the client prefers
	a stored response to satisfy the request without successful		stored response not be used to satisfy the request without successful
	validation on the origin server.		validation on the origin server.
	5.2.1.5. no-store		5.2.1.5. no-store
	The "no-store" request directive indicates that a cache MUST NOT		The "no-store" request directive indicates that a cache MUST NOT
	store any part of either this request or any response to it. This		store any part of either this request or any response to it. This
	directive applies to both private and shared caches. "MUST NOT		directive applies to both private and shared caches. "MUST NOT
	store" in this context means that the cache MUST NOT intentionally		store" in this context means that the cache MUST NOT intentionally
	store the information in non-volatile storage, and MUST make a		store the information in non-volatile storage, and MUST make a best-
	best-effort attempt to remove the information from volatile storage		effort attempt to remove the information from volatile storage as
	as promptly as possible after forwarding it.		promptly as possible after forwarding it.
	This directive is NOT a reliable or sufficient mechanism for ensuring		This directive is NOT a reliable or sufficient mechanism for ensuring
	privacy. In particular, malicious or compromised caches might not		privacy. In particular, malicious or compromised caches might not
	recognize or obey this directive, and communications networks might		recognize or obey this directive, and communications networks might
	be vulnerable to eavesdropping.		be vulnerable to eavesdropping.
	Note that if a request containing this directive is satisfied from a		Note that if a request containing this directive is satisfied from a
	cache, the no-store request directive does not apply to the already		cache, the no-store request directive does not apply to the already
	stored response.		stored response.
	5.2.1.6. no-transform		5.2.1.6. no-transform
	The "no-transform" request directive indicates that an intermediary		The "no-transform" request directive indicates that the client is
	(whether or not it implements a cache) MUST NOT transform the		asking for intermediares (whether or not they implement a cache) to
	payload, as defined in Section 5.7.2 of [RFC7230].		avoid transforming the payload, as defined in Section 5.5.2 of
			[Semantics].
	5.2.1.7. only-if-cached		5.2.1.7. only-if-cached
	The "only-if-cached" request directive indicates that the client only		The "only-if-cached" request directive indicates that the client only
	wishes to obtain a stored response. If it receives this directive, a		wishes to obtain a stored response. Caches that honor this request
	cache SHOULD either respond using a stored response that is		directive SHOULD, upon receiving it, either respond using a stored
	consistent with the other constraints of the request, or respond with		response that is consistent with the other constraints of the
	a 504 (Gateway Timeout) status code. If a group of caches is being		request, or respond with a 504 (Gateway Timeout) status code.
	operated as a unified system with good internal connectivity, a
	member cache MAY forward such a request within that group of caches.
	5.2.2. Response Cache-Control Directives		5.2.2. Response Cache-Control Directives
			This section defines cache response directives. A cache MUST obey
			the requirements of the Cache-Control directives defined in this
			section.
	5.2.2.1. must-revalidate		5.2.2.1. must-revalidate
	The "must-revalidate" response directive indicates that once it has		The "must-revalidate" response directive indicates that once it has
	become stale, a cache MUST NOT use the response to satisfy subsequent		become stale, the response MUST NOT be used to satisfy any other
	requests without successful validation on the origin server.		request without forwarding it for validation and receiving a
			successful response; see Section 4.3.
	The must-revalidate directive is necessary to support reliable		The must-revalidate directive is necessary to support reliable
	operation for certain protocol features. In all circumstances a		operation for certain protocol features. In all circumstances a
	cache MUST obey the must-revalidate directive; in particular, if a		cache MUST obey the must-revalidate directive; in particular, if a
	cache cannot reach the origin server for any reason, it MUST generate		cache is disconnected, it MUST generate a 504 (Gateway Timeout)
	a 504 (Gateway Timeout) response.		response.
	The must-revalidate directive ought to be used by servers if and only		The must-revalidate directive ought to be used by servers if and only
	if failure to validate a request on the representation could result		if failure to validate a request on the representation could result
	in incorrect operation, such as a silently unexecuted financial		in incorrect operation, such as a silently unexecuted financial
	transaction.		transaction.
			The must-revalidate directive also has the effect of allowing a
			stored response to be used to satisfy a request with an Authorization
			header field; see Section 3.2.
	5.2.2.2. no-cache		5.2.2.2. no-cache
	Argument syntax:		Argument syntax:
	#field-name		#field-name
	The "no-cache" response directive indicates that the response MUST		The "no-cache" response directive indicates that the response MUST
	NOT be used to satisfy a subsequent request without successful		NOT be used to satisfy any other request without forwarding it for
	validation on the origin server. This allows an origin server to		validation and receiving a successful response; see Section 4.3.
	prevent a cache from using it to satisfy a request without contacting
	it, even by caches that have been configured to send stale responses.		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 send stale responses.
	If the no-cache response directive specifies one or more field-names,		If the no-cache response directive specifies one or more field-names,
	then a cache MAY use the response to satisfy a subsequent request,		then a cache MAY use the response to satisfy a subsequent request,
	subject to any other restrictions on caching. However, any header		subject to any other restrictions on caching. However, any header
	fields in the response that have the field-name(s) listed MUST NOT be		fields in the response that have the field-name(s) listed MUST NOT be
	sent in the response to a subsequent request without successful		sent in the response to a subsequent request without successful
	revalidation with the origin server. This allows an origin server to		revalidation with the origin server. This allows an origin server to
	prevent the re-use of certain header fields in a response, while		prevent the re-use of certain header fields in a response, while
	still allowing caching of the rest of the response.		still allowing caching of the rest of the response.
	The field-names given are not limited to the set of header fields		The field-names given are not limited to the set of header fields
	defined by this specification. Field names are case-insensitive.		defined by this specification. Field names are case-insensitive.
	This directive uses the quoted-string form of the argument syntax. A		This directive uses the quoted-string form of the argument syntax. A
	sender SHOULD NOT generate the token form (even if quoting appears		sender SHOULD NOT generate the token form (even if quoting appears
	not to be needed for single-entry lists).		not to be needed for single-entry lists).
	Note: Although it has been back-ported to many implementations, some		Note: Although it has been back-ported to many implementations, some
	HTTP/1.0 caches will not recognize or obey this directive. Also,		HTTP/1.0 caches will not recognize or obey this directive. Also, no-
	no-cache response directives with field-names are often handled by		cache response directives with field-names are often handled by
	caches as if an unqualified no-cache directive was received; i.e.,		caches as if an unqualified no-cache directive was received; i.e.,
	the special handling for the qualified form is not widely		the special handling for the qualified form is not widely
	implemented.		implemented.
	5.2.2.3. no-store		5.2.2.3. no-store
	The "no-store" response directive indicates that a cache MUST NOT		The "no-store" response directive indicates that a cache MUST NOT
	store any part of either the immediate request or response. This		store any part of either the immediate request or response, and MUST
	directive applies to both private and shared caches. "MUST NOT		NOT use the response to satisfy any other request.
			This directive applies to both private and shared caches. "MUST NOT
	store" in this context means that the cache MUST NOT intentionally		store" in this context means that the cache MUST NOT intentionally
	store the information in non-volatile storage, and MUST make a		store the information in non-volatile storage, and MUST make a best-
	best-effort attempt to remove the information from volatile storage		effort attempt to remove the information from volatile storage as
	as promptly as possible after forwarding it.		promptly as possible after forwarding it.
	This directive is NOT a reliable or sufficient mechanism for ensuring		This directive is NOT a reliable or sufficient mechanism for ensuring
	privacy. In particular, malicious or compromised caches might not		privacy. In particular, malicious or compromised caches might not
	recognize or obey this directive, and communications networks might		recognize or obey this directive, and communications networks might
	be vulnerable to eavesdropping.		be vulnerable to eavesdropping.
	5.2.2.4. no-transform		5.2.2.4. no-transform
	The "no-transform" response directive indicates that an intermediary		The "no-transform" response directive indicates that an intermediary
	(regardless of whether it implements a cache) MUST NOT transform the		(regardless of whether it implements a cache) MUST NOT transform the
	payload, as defined in Section 5.7.2 of [RFC7230].		payload, as defined in Section 5.5.2 of [Semantics].
	5.2.2.5. public		5.2.2.5. public
	The "public" response directive indicates that any cache MAY store		The "public" response directive indicates that any cache MAY store
	the response, even if the response would normally be non-cacheable or		the response, even if the response would normally be non-cacheable or
	cacheable only within a private cache. (See Section 3.2 for		cacheable only within a private cache. (See Section 3.2 for
	additional details related to the use of public in response to a		additional details related to the use of public in response to a
	request containing Authorization, and Section 3 for details of how		request containing Authorization, and Section 3 for details of how
	public affects responses that would normally not be stored, due to		public affects responses that would normally not be stored, due to
	their status codes not being defined as cacheable by default; see		their status codes not being defined as heuristically cacheable; see
	Section 4.2.2.)		Section 4.2.2.)
	5.2.2.6. private		5.2.2.6. private
	Argument syntax:		Argument syntax:
	#field-name		#field-name
	The "private" response directive indicates that the response message		The "private" response directive indicates that the response message
	is intended for a single user and MUST NOT be stored by a shared		is intended for a single user and MUST NOT be stored by a shared
	skipping to change at line 1244 ¶		skipping to change at page 28, line 19 ¶
	5.2.2.7. proxy-revalidate		5.2.2.7. proxy-revalidate
	The "proxy-revalidate" response directive has the same meaning as the		The "proxy-revalidate" response directive has the same meaning as the
	must-revalidate response directive, except that it does not apply to		must-revalidate response directive, except that it does not apply to
	private caches.		private caches.
	5.2.2.8. max-age		5.2.2.8. max-age
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.3)
	The "max-age" response directive indicates that the response is to be		The "max-age" response directive indicates that the response is to be
	considered stale after its age is greater than the specified number		considered stale after its age is greater than the specified number
	of seconds.		of seconds.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the		'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the
	quoted-string form.		quoted-string form.
	5.2.2.9. s-maxage		5.2.2.9. s-maxage
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.3)
	The "s-maxage" response directive indicates that, in shared caches,		The "s-maxage" response directive indicates that, in shared caches,
	the maximum age specified by this directive overrides the maximum age		the maximum age specified by this directive overrides the maximum age
	specified by either the max-age directive or the Expires header		specified by either the max-age directive or the Expires header
	field. The s-maxage directive also implies the semantics of the		field. The s-maxage directive also implies the semantics of the
	proxy-revalidate response directive.		proxy-revalidate response directive.
			The must-revalidate directive also has the effect of allowing a
			stored response to be used to satisfy a request with an Authorization
			header field; see Section 3.2.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the		's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the
	quoted-string form.		quoted-string form.
	5.2.3. Cache Control Extensions		5.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. A cache		or more cache-extension tokens, each with an optional value. A cache
	MUST ignore unrecognized cache directives.		MUST ignore unrecognized cache directives.
	skipping to change at line 1303 ¶		skipping to change at page 29, line 38 ¶
	server 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 that recognizes such a community cache-extension could		A cache that recognizes such a community cache-extension could
	broaden its behavior in accordance with that extension. A cache that		broaden its behavior in accordance with that extension. A cache that
	does not recognize the community cache-extension would ignore it and		does not recognize the community cache-extension would ignore it and
	adhere to the private directive.		adhere to the private directive.
	7.1.2. Considerations for New Cache Control Directives
	New extension directives ought to consider defining:		New extension directives ought to consider defining:
	o What it means for a directive to be specified multiple times,		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		o When the directive does not take an argument, what it means when
	an argument is present,		an argument is present,
	o When the directive requires an argument, what it means when it is		o When the directive requires an argument, what it means when it is
	missing,		missing,
	o Whether the directive is specific to requests, responses, or able		o Whether the directive is specific to requests, responses, or able
	to be used in either.		to be used in either.
	See also Section 5.2.3.		5.2.4. Cache Directive Registry
	7.1. Cache Directive Registry
	The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry"		The "Hypertext Transfer Protocol (HTTP) Cache Directive Registry"
	defines the namespace for the cache directives. It has been created		defines the namespace for the cache directives. It has been created
	and is now maintained at		and is now maintained at <https://www.iana.org/assignments/http-
	<http://www.iana.org/assignments/http-cache-directives>.		cache-directives>.
	7.1.1. Procedure
	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 namespace require IETF Review (see		Values to be added to this namespace require IETF Review (see
	[RFC5226], Section 4.1).		[RFC8126], Section 4.8).
	5.3. Expires		5.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 4.2 for further discussion		response is considered stale. See Section 4.2 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 Expires value is an HTTP-date timestamp, as defined in Section		The Expires value is an HTTP-date timestamp, as defined in
	7.1.1.1 of [RFC7231].		Section 10.1.1.1 of [Semantics].
	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 recipient MUST interpret invalid date formats, especially the		A cache recipient MUST interpret invalid date formats, especially the
	value "0", as representing a time in the past (i.e., "already		value "0", as representing a time in the past (i.e., "already
	expired").		expired").
	skipping to change at line 1382 ¶		skipping to change at page 31, line 16 ¶
	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 many caches will evict a response far sooner		for time values), and many caches will evict a response far sooner
	than that.		than that.
	5.4. Pragma		5.4. Pragma
	The "Pragma" header field allows backwards compatibility with		The "Pragma" header field was defined for HTTP/1.0 caches, so that
	HTTP/1.0 caches, so that clients can specify a "no-cache" request		clients could specify a "no-cache" request (as Cache-Control was not
	that they will understand (as Cache-Control was not defined until		defined until HTTP/1.1).
	HTTP/1.1). When the Cache-Control header field is also present and
	understood in a request, Pragma is ignored.
	In HTTP/1.0, Pragma was defined as an extensible field for
	implementation-specified directives for recipients. This
	specification deprecates such extensions to improve interoperability.
	Pragma = 1#pragma-directive
	pragma-directive = "no-cache" / extension-pragma
	extension-pragma = token [ "=" ( token / quoted-string ) ]
	When the Cache-Control header field is not present in a request,
	caches MUST consider the no-cache request pragma-directive as having
	the same effect as if "Cache-Control: no-cache" were present (see
	Section 5.2.1).
	When sending a no-cache request, a client ought to include both the
	pragma and cache-control directives, unless Cache-Control: no-cache
	is purposefully omitted to target other Cache-Control response
	directives at HTTP/1.1 caches. For example:
	GET / HTTP/1.1
	Host: www.example.com
	Cache-Control: max-age=30
	Pragma: no-cache
	will constrain HTTP/1.1 caches to serve a response no older than 30		However, support for Cache-Control is now widespread. As a result,
	seconds, while precluding implementations that do not understand		this specification deprecates Pragma.
	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 was
	not specified, it does not provide a reliable replacement for		never specified, it does not provide a reliable replacement for
	"Cache-Control: no-cache" in them.		"Cache-Control: no-cache" in them.
	5.5. Warning		5.5. Warning
	The "Warning" header field is used to carry additional information		The "Warning" header field was 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 status code. This information is typically used to		reflected in the status code. This specification obsoletes it, as it
	warn about possible incorrectness introduced by caching operations or		is not widely generated or surfaced to users. The information it
	transformations applied to the payload of the message.		carried can be gleaned from examining other header fields, such as
			Age.
	Warnings can be used for other purposes, both cache-related and
	otherwise. The use of a warning, rather than an error status code,
	distinguishes these responses from true failures.
	Warning header fields can in general be applied to any message,
	however some warn-codes are specific to caches and can only be
	applied to response messages.
	Warning = 1#warning-value
	warning-value = warn-code SP warn-agent SP warn-text
	[ SP warn-date ]
	warn-code = 3DIGIT
	warn-agent = ( uri-host [ ":" port ] ) / pseudonym
	; the name or pseudonym of the server adding
	; the Warning header field, for use in debugging
	; a single "-" is recommended when agent unknown
	warn-text = quoted-string
	warn-date = DQUOTE HTTP-date DQUOTE
	Multiple warnings can be generated in a response (either by the
	origin server or by a cache), including multiple warnings with the
	same warn-code number that only differ in warn-text.
	A user agent that receives one or more Warning header fields SHOULD
	inform the user of as many of them as possible, in the order that
	they appear in the response. Senders that generate multiple Warning
	header fields are encouraged to order them with this user agent
	behavior in mind. A sender that generates new Warning header fields
	MUST append them after any existing Warning header fields.
	Warnings are assigned three digit warn-codes. The first digit
	indicates whether the Warning is required to be deleted from a stored
	response after validation:
	o 1xx warn-codes describe the freshness or validation status of the
	response, and so they MUST be deleted by a cache after validation.
	They can only be generated by a cache when validating a cached
	entry, and MUST NOT be generated in any other situation.
	o 2xx warn-codes describe some aspect of the representation that is
	not rectified by a validation (for example, a lossy compression of
	the representation) and they MUST NOT be deleted by a cache after
	validation, unless a full response is sent, in which case they
	MUST be.
	If a sender generates one or more 1xx warn-codes in a message to be
	sent to a recipient known to implement only HTTP/1.0, the sender MUST
	include in each corresponding warning-value a warn-date that matches
	the Date header field in the message. For example:
	HTTP/1.1 200 OK
	Date: Sat, 25 Aug 2012 23:34:45 GMT
	Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
	Warnings have accompanying warn-text that describes the error, e.g.,
	for logging. It is advisory only, and its content does not affect
	interpretation of the warn-code.
	If a recipient that uses, evaluates, or displays Warning header
	fields receives a warn-date that is different from the Date value in
	the same message, the recipient MUST exclude the warning-value
	containing that warn-date before storing, forwarding, or using the
	message. This allows recipients to exclude warning-values that were
	improperly retained after a cache validation. If all of the
	warning-values are excluded, the recipient MUST exclude the Warning
	header field as well.
	The following warn-codes are defined by this specification, each with
	a recommended warn-text in English, and a description of its meaning.
	The procedure for defining additional warn codes is described in
	Section 7.2.1.
	+-----------+----------------------------------+---------------+
	| Warn Code | Short Description | Reference |
	+-----------+----------------------------------+---------------+
	| 110 | Response is Stale | Section 5.5.1 |
	| 111 | Revalidation Failed | Section 5.5.2 |
	| 112 | Disconnected Operation | Section 5.5.3 |
	| 113 | Heuristic Expiration | Section 5.5.4 |
	| 199 | Miscellaneous Warning | Section 5.5.5 |
	| 214 | Transformation Applied | Section 5.5.6 |
	| 299 | Miscellaneous Persistent Warning | Section 5.5.7 |
	+-----------+----------------------------------+---------------+
	5.5.1. Warning: 110 - "Response is Stale"
	A cache SHOULD generate this whenever the sent response is stale.
	5.5.2. Warning: 111 - "Revalidation Failed"
	A cache SHOULD generate this when sending a stale response because an
	attempt to validate the response failed, due to an inability to reach
	the server.
	5.5.3. Warning: 112 - "Disconnected Operation"
	A cache SHOULD generate this if it is intentionally disconnected from
	the rest of the network for a period of time.
	5.5.4. Warning: 113 - "Heuristic Expiration"
	A cache SHOULD generate this if it heuristically chose a freshness
	lifetime greater than 24 hours and the response's age is greater than
	24 hours.
	5.5.5. Warning: 199 - "Miscellaneous Warning"
	The warning text can include arbitrary information to be presented to
	a human user or logged. A system receiving this warning MUST NOT
	take any automated action, besides presenting the warning to the
	user.
	5.5.6. Warning: 214 - "Transformation Applied"
	This Warning code MUST be added by a proxy if it applies any
	transformation to the representation, such as changing the
	content-coding, media-type, or modifying the representation data,
	unless this Warning code already appears in the response.
	5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"
	The warning text can include arbitrary information to be presented to
	a human user or logged. A system receiving this warning MUST NOT
	take any automated action.
	7.2. Warn Code Registry
	The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines
	the namespace for warn codes. It has been created and is now
	maintained at <http://www.iana.org/assignments/http-warn-codes>.
	7.2.1. Procedure
	A registration MUST include the following fields:
	o Warn Code (3 digits)
	o Short Description
	o Pointer to specification text
	Values to be added to this namespace require IETF Review (see
	[RFC5226], Section 4.1).
	6. History Lists		6. Relationship to Applications
	User agents often have history mechanisms, such as "Back" buttons and		Applications using HTTP often specify additional forms of caching.
	history lists, that can be used to redisplay a representation		For example, Web browsers often have history mechanisms such as
			"Back" buttons that can be used to redisplay a representation
	retrieved earlier in a session.		retrieved earlier in a session.
	The freshness model (Section 4.2) does not necessarily apply to		Likewise, some Web browsers implement caching of images and other
	history mechanisms. That is, a history mechanism can display a		assets within a page view; they may or may not honor HTTP caching
	previous representation even if it has expired.		semantics.
	This does not prohibit the history mechanism from telling the user		The requirements in this specification do not necessarily apply to
	that a view might be stale or from honoring cache directives (e.g.,		how applications use data after it is retrieved from a HTTP cache.
	Cache-Control: no-store).		That is, a history mechanism can display a previous representation
			even if it has expired, and an application can use cached data in
			other ways beyond its freshness lifetime.
	8. Security Considerations		This does not prohibit the application from taking HTTP caching into
			account; for example, a history mechanism might tell the user that a
			view is stale, or it might honor cache directives (e.g., Cache-
			Control: no-store).
			7. Security Considerations
	This section is meant to inform developers, information providers,		This section is meant to inform developers, information providers,
	and users of known security concerns specific to HTTP caching. More		and users of known security concerns specific to HTTP caching. More
	general security considerations are addressed in HTTP messaging		general security considerations are addressed in HTTP messaging
	[RFC7230] and semantics [RFC7231].		[Messaging] and semantics [Semantics].
	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.
	In particular, various attacks might be amplified by being stored in		7.1. Cache Poisoning
	a shared cache; such "cache poisoning" attacks use the cache to
	distribute a malicious payload to many clients, and are especially		Various attacks might be amplified by being stored in a shared cache.
	effective when an attacker can use implementation flaws, elevated		Such "cache poisoning" attacks use the cache to distribute a
	privileges, or other techniques to insert such a response into a		malicious payload to many clients, and are especially effective when
	cache. One common attack vector for cache poisoning is to exploit		an attacker can use implementation flaws, elevated privileges, or
			other techniques to insert such a response into a cache.
			One common attack vector for cache poisoning is to exploit
	differences in message parsing on proxies and in user agents; see		differences in message parsing on proxies and in user agents; see
	Section 3.3.3 of [RFC7230] for the relevant requirements.		Section 6.3 of [Messaging] for the relevant requirements regarding
			HTTP/1.1.
	Likewise, implementation flaws (as well as misunderstanding of cache		7.2. Timing Attacks
	operation) might lead to caching of sensitive information (e.g.,
	authentication credentials) that is thought to be private, exposing
	it to unauthorized parties.
	Furthermore, the very use of a cache can bring about privacy		Because one of the primary uses of a cache is to optimise
	concerns. For example, if two users share a cache, and the first one		performance, its use can "leak" information about what resources have
	browses to a site, the second may be able to detect that the other		been previously requested.
	has been to that site, because the resources from it load more
	quickly, thanks to the cache.		For example, if a user visits a site and their browser caches some of
			its responses, and then navigates to a second site, that site can
			attempt to load responses that it knows exists on the first site. If
			they load very quickly, it can be assumed that the user has visited
			that site, or even a specific page on it.
			Such "timing attacks" can be mitigated by adding more information to
			the cache key, such as the identity of the referring site (to prevent
			the attack described above). This is sometimes called "double
			keying."
			7.3. Caching of Sensitive Information
			Implementation and deployment flaws (as well as misunderstanding of
			cache operation) might lead to caching of sensitive information
			(e.g., authentication credentials) that is thought to be private,
			exposing it to unauthorized parties.
	Note that the Set-Cookie response header field [RFC6265] does not		Note that the Set-Cookie response header field [RFC6265] does not
	inhibit caching; a cacheable response with a Set-Cookie header field		inhibit caching; a cacheable response with a Set-Cookie header field
	can be (and often is) used to satisfy subsequent requests to caches.		can be (and often is) used to satisfy subsequent requests to caches.
	Servers who wish to control caching of these responses are encouraged		Servers who wish to control caching of these responses are encouraged
	to emit appropriate Cache-Control response header fields.		to emit appropriate Cache-Control response header fields.
	7. IANA Considerations		8. IANA Considerations
	The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".
	7.3. Header Field Registration
	HTTP header fields are registered within the "Message Headers"		The change controller for the following registrations is: "IETF
	registry maintained at		(iesg@ietf.org) - Internet Engineering Task Force".
	<http://www.iana.org/assignments/message-headers/>.
	This document defines the following HTTP header fields, so the		8.1. Header Field Registration
	"Permanent Message Header Field Names" registry has been updated
	accordingly (see [BCP90]).
	7.1.3. [Cache Directive] Registrations		Please update the "Hypertext Transfer Protocol (HTTP) Header Field
			Registry" registry at <https://www.iana.org/assignments/http-headers>
			with the header field names listed in the two tables of Section 5.
	The registry has been populated with the registrations below:		8.2. Cache Directive Registration
	7.2.2. [Warn Code] Registrations		Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive
			Registry" at <https://www.iana.org/assignments/http-cache-directives>
			with the registration procedure of Section 5.2.4 and the cache
			directive names summarized in the table of Section 5.2.
	The registry has been populated with the registrations below:		8.3. Warn Code Registry
	9. Acknowledgments		Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn
			Codes" registry at <https://www.iana.org/assignments/http-warn-codes>
			to the effect that Warning is obsoleted.
	See Section 10 of [RFC7230].		9. References
	10. References		9.1. Normative References
	10.1. Normative References		[Messaging]
			Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
			Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-06
			(work in progress), November 2019.
	[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,
			DOI 10.17487/RFC2119, March 1997,
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		<https://www.rfc-editor.org/info/rfc2119>.
	Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, June 2014.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Resource Identifier (URI): Generic Syntax", STD 66,
	June 2014.		RFC 3986, DOI 10.17487/RFC3986, January 2005,
			<https://www.rfc-editor.org/info/rfc3986>.
	[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Protocol (HTTP/1.1): Conditional Requests", RFC 7232,		Specifications: ABNF", STD 68, RFC 5234,
	June 2014.		DOI 10.17487/RFC5234, January 2008,
			<https://www.rfc-editor.org/info/rfc5234>.
	[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
	"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",		RFC 7405, DOI 10.17487/RFC7405, December 2014,
	RFC 7233, June 2014.		<https://www.rfc-editor.org/info/rfc7405>.
	[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Semantics]
	Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
			Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-06
			(work in progress), November 2019.
	10.2. Informative References		[USASCII] American National Standards Institute, "Coded Character
			Set -- 7-bit American Standard Code for Information
			Interchange", ANSI X3.4, 1986.
	[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration		9.2. Informative References
	Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.
	[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,
			DOI 10.17487/RFC2616, June 1999,
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		<https://www.rfc-editor.org/info/rfc2616>.
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	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, DOI 10.17487/RFC5861, April 2010,
			<https://www.rfc-editor.org/info/rfc5861>.
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, June 2010.		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
			<https://www.rfc-editor.org/info/rfc5905>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	April 2011.		DOI 10.17487/RFC6265, April 2011,
			<https://www.rfc-editor.org/info/rfc6265>.
	Appendix C. Collected ABNF		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
			Ed., "Hypertext Transfer Protocol (HTTP): Caching",
			RFC 7234, DOI 10.17487/RFC7234, June 2014,
			<https://www.rfc-editor.org/info/rfc7234>.
	In the collected ABNF below, list rules are expanded as per Section		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	1.2 of [RFC7230].		Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	Age = delta-seconds		Appendix A. Collected ABNF
	Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS		In the collected ABNF below, list rules are expanded as per
	cache-directive ] )		Section 12 of [Semantics].
	Expires = HTTP-date		Age = delta-seconds
	HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>		Cache-Control = [ cache-directive ] *( OWS "," OWS [ cache-directive
			] )
	OWS = <OWS, see [RFC7230], Section 3.2.3>		Expires = HTTP-date
	Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS		HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1>
	pragma-directive ] )
	Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]		OWS = <OWS, see [Semantics], Section 4.3>
	)
	cache-directive = token [ "=" ( token / quoted-string ) ]		cache-directive = token [ "=" ( token / quoted-string ) ]
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	extension-pragma = token [ "=" ( token / quoted-string ) ]		field-name = <field-name, see [Semantics], Section 4.2>
	field-name = <field-name, see [RFC7230], Section 3.2>		quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
	port = <port, see [RFC7230], Section 2.7>		token = <token, see [Semantics], Section 4.2.3>
	pragma-directive = "no-cache" / extension-pragma
	pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
	quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>		Appendix B. Changes from RFC 7234
	token = <token, see [RFC7230], Section 3.2.6>		The Warning response header was obsoleted. Much of the information
			supported by Warning could be gleaned by examining the response), and
			the remaining warn-codes -- although potentially useful -- were
			entirely advisory, and in practice were not added by caches or
			intermediaries. (Section 5.5)
	uri-host = <uri-host, see [RFC7230], Section 2.7>		Appendix C. Change Log
	warn-agent = ( uri-host [ ":" port ] ) / pseudonym		This section is to be removed before publishing as an RFC.
	warn-code = 3DIGIT
	warn-date = DQUOTE HTTP-date DQUOTE
	warn-text = quoted-string
	warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
	]
	Appendix A. Changes from RFC 2616		C.1. Between RFC7234 and draft 00
	The specification has been substantially rewritten for clarity.		The changes were purely editorial:
	The conditions under which an authenticated response can be cached		o Change boilerplate and abstract to indicate the "draft" status,
	have been clarified. (Section 3.2)		and update references to ancestor specifications.
	New status codes can now define that caches are allowed to use		o Remove version "1.1" from document title, indicating that this
	heuristic freshness with them. Caches are now allowed to calculate		specification applies to all HTTP versions.
	heuristic freshness for URIs with query components. (Section 4.2.2)
	The algorithm for calculating age is now less conservative. Caches		o Adjust historical notes.
	are now required to handle dates with time zones as if they're
	invalid, because it's not possible to accurately guess.
	(Section 4.2.3)
	The Content-Location response header field is no longer used to		o Update links to sibling specifications.
	determine the appropriate response to use when validating.
	(Section 4.3)
	The algorithm for selecting a cached negotiated response to use has		o Replace sections listing changes from RFC 2616 by new empty
	been clarified in several ways. In particular, it now explicitly		sections referring to RFC 723x.
	allows header-specific canonicalization when processing selecting
	header fields. (Section 4.1)
	Requirements regarding denial-of-service attack avoidance when		o Remove acknowledgements specific to RFC 723x.
	performing invalidation have been clarified. (Section 4.4)
	Cache invalidation only occurs when a successful response is		o Move "Acknowledgements" to the very end and make them unnumbered.
	received. (Section 4.4)
	Cache directives are explicitly defined to be case-insensitive.		C.2. Since draft-ietf-httpbis-cache-00
	Handling of multiple instances of cache directives when only one is
	expected is now defined. (Section 5.2)
	The "no-store" request directive doesn't apply to responses; i.e., a		The changes are purely editorial:
	cache can satisfy a request with no-store on it and does not
	invalidate it. (Section 5.2.1.5)
	The qualified forms of the private and no-cache cache directives are		o Moved all extensibility tips, registration procedures, and
	noted to not be widely implemented; for example, "private=foo" is		registry tables from the IANA considerations to normative
	interpreted by many caches as simply "private". Additionally, the		sections, reducing the IANA considerations to just instructions
	meaning of the qualified form of no-cache has been clarified.		that will be removed prior to publication as an RFC.
	(Section 5.2.2)
	The "no-cache" response directive's meaning has been clarified.		C.3. Since draft-ietf-httpbis-cache-01
	(Section 5.2.2.2)
	The one-year limit on Expires header field values has been removed;		o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
	instead, the reasoning for using a sensible value is given.		http-core/issues/75>)
	(Section 5.3)
	The Pragma header field is now only defined for backwards		o In Section 5.4, misleading statement about the relation between
	compatibility; future pragmas are deprecated. (Section 5.4)		Pragma and Cache-Control (<https://github.com/httpwg/http-core/
			issues/92>, <https://www.rfc-editor.org/errata/eid4674>)
	Some requirements regarding production and processing of the Warning		C.4. Since draft-ietf-httpbis-cache-02
	header fields have been relaxed, as it is not widely implemented.
	Furthermore, the Warning header field no longer uses RFC 2047
	encoding, nor does it allow multiple languages, as these aspects were
	not implemented. (Section 5.5)
	This specification introduces the Cache Directive and Warn Code		o In Section 3, explain that only final responses are cacheable
	Registries, and defines considerations for new cache directives.		(<https://github.com/httpwg/http-core/issues/29>)
	(Section 7.1 and Section 7.2)
	Index		o In Section 5.2.2, clarify what responses various directives apply
			to (<https://github.com/httpwg/http-core/issues/52>)
	1		o In Section 4.3.1, clarify the source of validators in conditional
	110 (warn-code) 31		requests (<https://github.com/httpwg/http-core/issues/110>)
	111 (warn-code) 31
	112 (warn-code) 31
	113 (warn-code) 31
	199 (warn-code) 32
	2		o Revise Section 6 to apply to more than just History Lists
	214 (warn-code) 32		(<https://github.com/httpwg/http-core/issues/126>)
	299 (warn-code) 32
			o In Section 5.5, deprecated "Warning" header field
			(<https://github.com/httpwg/http-core/issues/139>)
			o In Section 3.2, remove a spurious note
			(<https://github.com/httpwg/http-core/issues/141>)
			C.5. Since draft-ietf-httpbis-cache-03
			o In Section 2, define what a disconnected cache is
			(<https://github.com/httpwg/http-core/issues/5>)
			o In Section 4, clarify language around how to select a response
			when more than one matches (<https://github.com/httpwg/http-core/
			issues/23>)
			o in Section 4.2.4, mention stale-while-revalidate and stale-if-
			error (<https://github.com/httpwg/http-core/issues/122>)
			o Remove requirements around cache request directives
			(<https://github.com/httpwg/http-core/issues/129>)
			o Deprecate Pragma (<https://github.com/httpwg/http-core/
			issues/140>)
			o In Section 3.2 and Section 5.2.2, note effect of some directives
			on authenticated requests (<https://github.com/httpwg/http-core/
			issues/161>)
			C.6. Since draft-ietf-httpbis-cache-04
			o In Section 5.2, remove the registrations for stale-if-error and
			stale-while-revalidate which happened in RFC 7234
			(<https://github.com/httpwg/http-core/issues/207>)
			C.7. Since draft-ietf-httpbis-cache-05
			o In Section 3.1, clarify how weakly framed content is considered
			for purposes of completeness (<https://github.com/httpwg/http-
			core/issues/25>)
			o Througout, describe Vary and cache key operations more clearly
			(<https://github.com/httpwg/http-core/issues/28>)
			o In Section 3, remove concept of "cacheable methods" in favor of
			prose (<https://github.com/httpwg/http-core/issues/54>)
			o Refactored Section 7, and added a section on timing attacks
			(<https://github.com/httpwg/http-core/issues/233>)
			o Changed "cacheable by default" to "heuristically cacheable"
			throughout (<https://github.com/httpwg/http-core/issues/242>)
			Index
	A		A
	age 11
	Age header field 21		Age header field 21
			age 12
	C		C
			Cache-Control header field 22
	cache 4		cache 4
	cache entry 5		cache key 6
	cache key 5-6
	Cache-Control header field 21
	D
	Disconnected Operation (warn-text) 31
	E		E
	Expires header field 28		Expires header field 30
	explicit expiration time 11		explicit expiration time 12
	F		F
	fresh 11		fresh 12
	freshness lifetime 11		freshness lifetime 12
	G		G
	Grammar		Grammar
	Age 21		Age 21
			ALPHA 5
	Cache-Control 22		Cache-Control 22
	cache-directive 22		cache-directive 22
	delta-seconds 5		CR 5
	Expires 28		CRLF 5
	extension-pragma 29		CTL 5
	Pragma 29		delta-seconds 6
	pragma-directive 29		DIGIT 5
	warn-agent 29		DQUOTE 5
	warn-code 29		Expires 30
	warn-date 29		HEXDIG 5
	warn-text 29		HTAB 5
	Warning 29		LF 5
	warning-value 29		OCTET 5
			SP 5
			VCHAR 5
	H		H
	Heuristic Expiration (warn-text) 31		heuristic expiration time 12
	heuristic expiration time 11		heuristically cacheable 14
	M		M
	max-age (cache directive) 22, 26		max-age (cache directive) 23, 28
	max-stale (cache directive) 22		max-stale (cache directive) 23
	min-fresh (cache directive) 22		min-fresh (cache directive) 24
	Miscellaneous Persistent Warning (warn-text) 32		must-revalidate (cache directive) 25
	Miscellaneous Warning (warn-text) 32
	must-revalidate (cache directive) 24
	N		N
	no-cache (cache directive) 23, 25		no-cache (cache directive) 24, 26
	no-store (cache directive) 23, 24		no-store (cache directive) 24, 26
	no-transform (cache directive) 23, 25		no-transform (cache directive) 25, 27
	O		O
	only-if-cached (cache directive) 23		only-if-cached (cache directive) 25
	P		P
	Pragma header field 29		Pragma header field 31
	private (cache directive) 25		private (cache directive) 27
	private cache 4		private cache 4
	proxy-revalidate (cache directive) 26		proxy-revalidate (cache directive) 28
	public (cache directive) 25		public (cache directive) 27
	R
	Response is Stale (warn-text) 30
	Revalidation Failed (warn-text) 31
	S		S
	s-maxage (cache directive) 27		s-maxage (cache directive) 28
	shared cache 4		shared cache 4
	stale 11		stale 12
	strong validator 18		strong validator 19
	T
	Transformation Applied (warn-text) 32
	V		V
	validator 16		validator 16
	W		W
	Warning header field 29		Warning header field 31
			Acknowledgments
			See Appendix "Acknowledgments" of [Semantics].
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		United States of America
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: https://roy.gbiv.com/
	Mark Nottingham (editor)		Mark Nottingham (editor)
	Akamai		Fastly
	EMail: mnot@mnot.net		EMail: mnot@mnot.net
	URI: http://www.mnot.net/		URI: https://www.mnot.net/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster 48155
	Germany		Germany
	EMail: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: https://greenbytes.de/tech/webdav/
End of changes. 212 change blocks.
	869 lines changed or deleted		789 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/