frankenRFC723x_cache.txt		draft-ietf-httpbis-cache-01.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: December 2, 2018 J. Reschke, Ed.
	greenbytes		greenbytes
	June 2014		May 31, 2018
	Hypertext Transfer Protocol (HTTP/1.1): Caching		HTTP Caching
			draft-ietf-httpbis-cache-01
	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.2.
	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 December 2, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . 8
	3.3. Combining Partial Content ..................................8		3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8
	4. Constructing Responses from Caches ..............................8		4. Constructing Responses from Caches . . . . . . . . . . . . . 9
	4.1. Calculating Secondary Keys with Vary .......................9		4.1. Calculating Secondary Keys with Vary . . . . . . . . . . 10
	4.2. Freshness .................................................11		4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.2.1. Calculating Freshness Lifetime .....................12		4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 12
	4.2.2. Calculating Heuristic Freshness ....................13		4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . 15
	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 . . . . . . . . . . . 18
	4.3.4. Freshening Stored Responses upon Validation ........18		4.3.4. Freshening Stored Responses upon Validation . . . . . 18
	4.3.5. Freshening Responses via HEAD ......................19		4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 19
	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.2. Response Cache-Control Directives . . . . . . . . . . 25
	5.2.3. Cache Control Extensions ...........................27		5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 28
	5.3. Expires ...................................................28		5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 29
	5.4. Pragma ....................................................29		5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 29
	5.5. Warning ...................................................29		5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 30
	5.5.1. Warning: 110 - "Response is Stale" .................31		5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 31
	5.5.2. Warning: 111 - "Revalidation Failed" ...............31		5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . 33
	5.5.3. Warning: 112 - "Disconnected Operation" ............31		5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . 33
	5.5.4. Warning: 113 - "Heuristic Expiration" ..............31		5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 33
	5.5.5. Warning: 199 - "Miscellaneous Warning" .............32		5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 34
	5.5.6. Warning: 214 - "Transformation Applied" ............32		5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . 34
	5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32		5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 34
	6. History Lists ..................................................32		5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 34
	7. IANA Considerations ............................................32		5.5.8. Warn Code Registry . . . . . . . . . . . . . . . . . 34
	7.1. Cache Directive Registry ..................................32		6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 34
	7.1.1. Procedure ..........................................32		7. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	7.1.2. Considerations for New Cache Control Directives ....33		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	7.1.3. Registrations ......................................33		8.1. Header Field Registration . . . . . . . . . . . . . . . . 36
	7.2. Warn Code Registry ........................................34		8.2. Cache Directive Registration . . . . . . . . . . . . . . 36
	7.2.1. Procedure ..........................................34		8.3. Warn Code Registration . . . . . . . . . . . . . . . . . 36
	7.2.2. Registrations ......................................34		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	7.3. Header Field Registration .................................34		9.1. Normative References . . . . . . . . . . . . . . . . . . 36
	8. Security Considerations ........................................35		9.2. Informative References . . . . . . . . . . . . . . . . . 37
	9. Acknowledgments ................................................36		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 38
	10. References ....................................................36		Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 39
	10.1. Normative References .....................................36		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 39
	10.2. Informative References ...................................37		C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 39
	Appendix A. Changes from RFC 2616 .................................38		C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 39
	Appendix B. Imported ABNF .........................................39		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	Appendix C. Collected ABNF ........................................39		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42
	Index .............................................................41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
	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
	skipping to change at line 153 ¶		skipping to change at page 4, line 48 ¶
	performance by reusing a prior response message to satisfy a current		performance by reusing a prior response message to satisfy a current
	request. A stored response is considered "fresh", as defined in		request. A stored response is considered "fresh", as defined in
	Section 4.2, if the response can be reused without "validation"		Section 4.2, if the response can be reused without "validation"
	(checking with the origin server to see if the cached response		(checking with the origin server to see if the cached response
	remains valid for this request). A fresh response can therefore		remains valid for this request). A fresh response can therefore
	reduce both latency and network overhead each time it is reused.		reduce both latency and network overhead each time it is reused.
	When a cached response is not fresh, it might still be reusable if it		When a cached response is not fresh, it might still be reusable if it
	can be freshened by validation (Section 4.3) or if the origin is		can be freshened by validation (Section 4.3) or if the origin is
	unavailable (Section 4.2.4).		unavailable (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] with a list extension, defined in Section 11 of
	[RFC7230], that allows for compact definition of comma-separated		[Semantics], that allows for compact definition of comma-separated
	lists using a '#' operator (similar to how the '*' operator indicates		lists using a '#' operator (similar to how the '*' operator indicates
	repetition). Appendix B describes rules imported from other		repetition). Appendix A shows the collected grammar with all list
	documents. Appendix C shows the collected grammar with all list
	operators expanded to standard ABNF notation.		operators expanded to standard ABNF notation.
	Appendix B. Imported ABNF
	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 4.3>
			field-name = <field-name, see [Semantics], Section 4.2>
			quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
			token = <token, see [Semantics], Section 4.2.3>
			uri-host = <host, see [RFC3986], Section 3.2.2>
			port = <port, see [RFC3986], Section 3.2.3>
			pseudonym = <pseudonym, see [Semantics], Section 5.6.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 eliminating the transfer of information already
	held in the cache. Although caching is an entirely OPTIONAL feature		held in the cache. Although caching is an entirely OPTIONAL feature
	of HTTP, it can be assumed that reusing a cached response is		of HTTP, it can be assumed that reusing a cached response is
	desirable and that such reuse is the default behavior when no		desirable and that such reuse is the default behavior when no
	requirement or local configuration prevents it. Therefore, HTTP		requirement or local configuration prevents it. Therefore, HTTP
	cache requirements are focused on preventing a cache from either		cache requirements are focused on preventing a cache from either
	storing a non-reusable response or reusing a stored response		storing a non-reusable response or reusing a stored response
	inappropriately, rather than mandating that caches always store and		inappropriately, rather than 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		Each cache entry consists of a cache key and one or more HTTP
	responses corresponding to prior requests that used the same key.		responses corresponding to prior requests that used the same key.
	The most common form of cache entry is a successful result of a		The most common form of cache entry is a successful result of a
	retrieval request: i.e., a 200 (OK) response to a GET request, which		retrieval request: i.e., a 200 (OK) response to a GET request, which
	contains a representation of the resource identified by the request		contains a representation of the resource identified by the request
	target (Section 4.3.1 of [RFC7231]). However, it is also possible to		target (Section 7.3.1 of [Semantics]). However, it is also possible
	cache permanent redirects, negative results (e.g., 404 (Not Found)),		to cache permanent redirects, negative results (e.g., 404 (Not
	incomplete results (e.g., 206 (Partial Content)), and responses to		Found)), incomplete results (e.g., 206 (Partial Content)), and
	methods other than GET if the method's definition allows such caching		responses to methods other than GET if the method's definition allows
	and defines something suitable for use as a cache key.		such caching and defines something suitable for use as a cache key.
	The primary cache key consists of the request method and target URI.		The primary cache key consists of the request method and target URI.
	However, since HTTP caches in common use today are typically limited		However, since HTTP caches in common use today are typically limited
	to caching responses to GET, many caches simply decline other methods		to caching responses to GET, many caches simply decline other methods
	and use only the URI as the primary cache key.		and use only the URI as the primary cache key.
	If a request target is subject to content negotiation, its cache		If a request target is subject to content negotiation, its cache
	entry might consist of multiple stored responses, each differentiated		entry might consist of multiple stored responses, each differentiated
	by a secondary key for the values of the original request's selecting		by a secondary key for the values of the original request's selecting
	header fields (Section 4.1).		header fields (Section 4.1).
	skipping to change at line 269 ¶		skipping to change at page 7, line 20 ¶
	cacheable, and		cacheable, and
	o the response status code is understood by the cache, and		o the response status code is understood by the cache, and
	o the "no-store" cache directive (see Section 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 request or response header fields, 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
	skipping to change at line 305 ¶		skipping to change at page 8, line 8 ¶
	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 the message framing ([Messaging]) are received prior to
	the connection being closed. If the request method is GET, the		the connection being closed. If the request method is GET, the
	response status code is 200 (OK), and the entire response header		response status code is 200 (OK), and the entire response header
	section has been received, a cache MAY store an incomplete response		section has been received, a cache MAY store an incomplete response
	message body if the cache entry is recorded as incomplete. Likewise,		message body if the cache entry is recorded as incomplete. Likewise,
	a 206 (Partial Content) response MAY be stored as if it were an		a 206 (Partial Content) response MAY be stored as if it were an
	incomplete 200 (OK) cache entry. However, a cache MUST NOT store		incomplete 200 (OK) cache entry. However, a cache MUST NOT store
	incomplete or partial-content responses if it does not support the		incomplete or partial-content responses if it does not support the
	Range and Content-Range header fields or if it does not understand		Range and Content-Range header fields or if it does not understand
	the range units used in those fields.		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 entry, 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 cache directive that allows such
	responses to be stored is present in the response.		responses to be stored is present in the response.
	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		Note that cached responses that contain the "must-revalidate" and/or
	"s-maxage" response directives are not allowed to be served stale		"s-maxage" response directives are not allowed to be served stale
	(Section 4.2.4) by shared caches. In particular, a response with		(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		either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to
	satisfy a subsequent request without revalidating it on the origin		satisfy a subsequent request without revalidating it on the origin
	server.		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:
	o delete any Warning header fields in the stored response with		o delete any Warning header fields in the stored response with warn-
	warn-code 1xx (see Section 5.5);		code 1xx (see Section 5.5);
	o retain any Warning header fields in the stored response with		o retain any Warning header fields in the stored response with warn-
	warn-code 2xx; and,		code 2xx; and,
	o use other header fields provided in the new response, aside from		o use other header fields provided in the new response, aside from
	Content-Range, to replace all instances of the corresponding		Content-Range, to replace all instances of the corresponding
	header fields in the stored response.		header fields in the stored response.
	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		o the presented request does not contain the no-cache pragma
	(Section 5.4), nor the no-cache cache directive (Section 5.2.1),		(Section 5.4), nor the no-cache cache directive (Section 5.2.1),
	unless the stored response is successfully validated		unless the stored response is successfully validated
	skipping to change at line 407 ¶		skipping to change at page 10, line 14 ¶
	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 response (as determined by the Date header field). It
	can also forward the request with "Cache-Control: max-age=0" or		can also forward the request with "Cache-Control: max-age=0" or
	"Cache-Control: no-cache" to disambiguate which response to use.		"Cache-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 Secondary 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 519 ¶		skipping to change at page 12, line 29 ¶
	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 cache directives in a
	request to constrain or relax freshness calculations for the		request to constrain or relax freshness calculations for the
	corresponding response (Section 5.2.1).		corresponding response (Section 5.2.1).
	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 13, line 40 ¶
	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 cacheable by default (see
	6.1 of [RFC7231]), and those responses without explicit freshness		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		If the response has a Last-Modified header field (Section 10.2.2 of
	[RFC7232]), caches are encouraged to use a heuristic expiration value		[Semantics]), caches are encouraged to use a heuristic expiration
	that is no more than some fraction of the interval since that time.		value that is no more than some fraction of the interval since that
	A typical setting of this fraction might be 10%.		time. A typical setting of this fraction might be 10%.
	When a heuristic is used to calculate freshness lifetime, a cache		When a heuristic is used to calculate freshness lifetime, a cache
	SHOULD generate a Warning header field with a 113 warn-code (see		SHOULD generate a Warning header field with a 113 warn-code (see
	Section 5.5.4) in the response if its current_age is more than 24		Section 5.5.4) in the response if its current_age is more than 24
	hours and such a warning is not already present.		hours and such a warning is not already present.
	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
	skipping to change at line 614 ¶		skipping to change at page 14, line 27 ¶
	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		The term "age_value" denotes the value of the Age header field
	(Section 5.1), in a form appropriate for arithmetic operation; or		(Section 5.1), in a form appropriate for arithmetic operation; or
	0, if not available.		0, if not available.
	date_value		date_value
	The term "date_value" denotes the value of the Date header field,		The term "date_value" denotes the value of the Date header field,
	in a form appropriate for arithmetic operations. See Section		in a form appropriate for arithmetic operations. See
	7.1.1.2 of [RFC7231] for the definition of the Date header field,		Section 10.1.1.2 of [Semantics] for the definition of the Date
	and for requirements regarding responses without it.		header field, and for requirements regarding responses without it.
	now		now
	The term "now" means "the current value of the clock at the host		The term "now" means "the current value of the clock at the host
	performing the calculation". A 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		The current value of the clock at the host at the time the request
	resulting in the stored response was made.		resulting in the stored response was made.
	response_time		response_time
	The current value of the clock at the host at the time the		The current value of the clock at the host at the time the
	response was received.		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.
	skipping to change at line 690 ¶		skipping to change at page 15, line 50 ¶
	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 send stale responses unless it is disconnected
	(i.e., it cannot contact the origin server or otherwise find a		(i.e., it cannot contact the origin server or otherwise find a
	forward path) or doing so is explicitly allowed (e.g., by the		forward path) or doing so is explicitly allowed (e.g., by the max-
	max-stale request directive; see Section 5.2.1).		stale request directive; see Section 5.2.1).
	A cache SHOULD generate a Warning header field with the 110 warn-code		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		(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		generate a 112 warn-code (see Section 5.5.3) in stale responses if
	the cache is disconnected.		the cache is disconnected.
	A cache SHOULD NOT generate a new Warning header field when		A cache SHOULD NOT generate a new Warning header field when
	forwarding a response that does not have an Age header field, even if		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		the response is already stale. A cache need not validate a response
	that merely became stale in transit.		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 sending a conditional request for cache validation, a cache
	sends one or more precondition header fields containing validator		sends one or more precondition header fields containing validator
	metadata from its stored response(s), which is then compared by		metadata from its stored response(s), which is then compared by
	recipients to determine whether a stored response is equivalent to a		recipients to determine whether a stored response is equivalent to a
	current representation of the resource.		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 27 ¶
	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 838 ¶		skipping to change at page 19, line 10 ¶
	When a cache receives a 304 (Not Modified) response and already has		When a cache receives a 304 (Not Modified) response and already has
	one or more stored 200 (OK) responses for the same cache key, the		one or more stored 200 (OK) responses for the same cache key, the
	cache needs to identify which of the stored responses are updated by		cache needs to identify which of the stored responses are updated by
	this new response and then update the stored response(s) with the new		this new response and then update the stored response(s) with the new
	information provided in the 304 response.		information provided in the 304 response.
	The stored response to update is identified by using the first match		The stored response to update is identified by using the first match
	(if any) of the following:		(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 selected. If
	responses contain the same strong validator, then the cache MUST		none of the stored responses contain the same strong validator,
	NOT use the new response to update any stored responses.		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 selected 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.		selected for update.
	If a stored response is selected for update, the cache MUST:		If a stored response is selected for update, the cache MUST:
	o delete any Warning header fields in the stored response with		o delete any Warning header fields in the stored response with warn-
	warn-code 1xx (see Section 5.5);		code 1xx (see Section 5.5);
	o retain any Warning header fields in the stored response with		o retain any Warning header fields in the stored response with warn-
	warn-code 2xx; and,		code 2xx; and,
	o use other header fields provided in the 304 (Not Modified)		o use other header fields provided in the 304 (Not Modified)
	response to replace all instances of the corresponding header		response to replace all instances of the corresponding header
	fields in the stored response.		fields in the stored response.
	4.3.5. Freshening Responses via HEAD		4.3.5. Freshening Responses via 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
	skipping to change at line 886 ¶		skipping to change at page 20, line 13 ¶
	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:
	o delete any Warning header fields in the stored response with		o delete any Warning header fields in the stored response with warn-
	warn-code 1xx (see Section 5.5);		code 1xx (see Section 5.5);
	o retain any Warning header fields in the stored response with		o retain any Warning header fields in the stored response with warn-
	warn-code 2xx; and,		code 2xx; and,
	o use other header fields provided in the HEAD response to replace		o use other header fields provided in the HEAD response to replace
	all instances of the corresponding header fields in the stored		all instances of the corresponding header fields in the stored
	response and append new header fields to the stored response's		response and append new header fields to the stored response's
	header section unless otherwise restricted by the Cache-Control		header section unless otherwise restricted by the Cache-Control
	header field.		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/1.1 header
	fields related to caching.		fields related to caching.
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+--------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+--------------+
	| Age | http | standard | Section 5.1 |		| Age | http | standard | Section 5.1 |
	| Cache-Control | http | standard | Section 5.2 |		| Cache-Control | http | standard | Section 5.2 |
	| Expires | http | standard | Section 5.3 |		| Expires | http | standard | Section 5.3 |
	| Pragma | http | standard | Section 5.4 |		| Pragma | http | standard | Section 5.4 |
	| Warning | http | standard | Section 5.5 |		| Warning | http | standard | Section 5.5 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+--------------+
	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
	skipping to change at line 991 ¶		skipping to change at page 22, line 24 ¶
	Cache-Control directives 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-if-error | [RFC5861], Section 4 |
	| stale-while-revalidate | [RFC5861], Section 3 |		| stale-while-revalidate | [RFC5861], Section 3 |
	+------------------------+----------------------------------+		+------------------------+-----------------------------------+
	5.2.1. Request Cache-Control Directives		5.2.1. Request Cache-Control Directives
	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 is
	unwilling to accept a response whose age is greater than the		unwilling to accept a response whose age is greater than the
	specified number of seconds. Unless the max-stale request directive		specified number of seconds. Unless the max-stale request directive
	is also present, the client is not willing to accept a stale		is also present, the client is not willing to accept 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 max-stale is assigned a value, then the client is
	willing to accept a response that has exceeded its freshness lifetime		willing to accept a response that has exceeded its freshness lifetime
	by no more than the specified number of seconds. If no value is		by no more than the specified number of seconds. If no value is
	assigned to max-stale, then the client is willing to accept a stale		assigned to max-stale, then the client is willing to accept a stale
	response of any age.		response of 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 is
	willing to accept a response whose freshness lifetime is no less than		willing to accept a response whose freshness lifetime is no less than
	its current age plus the specified time in seconds. That is, the		its current age plus the specified time in seconds. That is, the
	client wants a response that will still be fresh for at least the		client wants a response that will still be fresh for at least the
	specified number of seconds.		specified number 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.
	skipping to change at line 1088 ¶		skipping to change at page 24, line 39 ¶
	The "no-cache" request directive indicates that a cache MUST NOT use		The "no-cache" request directive indicates that a cache MUST NOT use
	a stored response to satisfy the request without successful		a stored response 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 an intermediary
	(whether or not it implements a cache) MUST NOT transform the		(whether or not it implements a cache) MUST NOT transform the
	payload, as defined in Section 5.7.2 of [RFC7230].		payload, as defined in Section 5.6.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. If it receives this directive, a
	cache SHOULD either respond using a stored response that is		cache SHOULD either respond using a stored response that is
	consistent with the other constraints of the request, or respond with		consistent with the other constraints of the request, or respond with
	a 504 (Gateway Timeout) status code. If a group of caches is being		a 504 (Gateway Timeout) status code. If a group of caches is being
	operated as a unified system with good internal connectivity, a		operated as a unified system with good internal connectivity, a
	member cache MAY forward such a request within that group of caches.		member cache MAY forward such a request within that group of caches.
	skipping to change at line 1165 ¶		skipping to change at page 26, line 22 ¶
	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. 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.
	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.6.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 cacheable by default; see
	skipping to change at line 1244 ¶		skipping to change at page 28, line 9 ¶
	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.
	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.
	skipping to change at line 1303 ¶		skipping to change at page 29, line 19 ¶
	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).		[RFC5226], Section 4.1).
	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 1492 ¶		skipping to change at page 33, line 14 ¶
	Warnings have accompanying warn-text that describes the error, e.g.,		Warnings have accompanying warn-text that describes the error, e.g.,
	for logging. It is advisory only, and its content does not affect		for logging. It is advisory only, and its content does not affect
	interpretation of the warn-code.		interpretation of the warn-code.
	If a recipient that uses, evaluates, or displays Warning header		If a recipient that uses, evaluates, or displays Warning header
	fields receives a warn-date that is different from the Date value in		fields receives a warn-date that is different from the Date value in
	the same message, the recipient MUST exclude the warning-value		the same message, the recipient MUST exclude the warning-value
	containing that warn-date before storing, forwarding, or using the		containing that warn-date before storing, forwarding, or using the
	message. This allows recipients to exclude warning-values that were		message. This allows recipients to exclude warning-values that were
	improperly retained after a cache validation. If all of the		improperly retained after a cache validation. If all of the warning-
	warning-values are excluded, the recipient MUST exclude the Warning		values are excluded, the recipient MUST exclude the Warning header
	header field as well.		field as well.
	The following warn-codes are defined by this specification, each with		The following warn-codes are defined by this specification, each with
	a recommended warn-text in English, and a description of its meaning.		a recommended warn-text in English, and a description of its meaning.
	The procedure for defining additional warn codes is described in		The procedure for defining additional warn codes is described in
	Section 7.2.1.		Section 5.5.8.
	+-----------+----------------------------------+---------------+		+-----------+----------------------------------+----------------+
	| Warn Code | Short Description | Reference |		| Warn Code | Short Description | Reference |
	+-----------+----------------------------------+---------------+		+-----------+----------------------------------+----------------+
	| 110 | Response is Stale | Section 5.5.1 |		| 110 | Response is Stale | Section 5.5.1 |
	| 111 | Revalidation Failed | Section 5.5.2 |		| 111 | Revalidation Failed | Section 5.5.2 |
	| 112 | Disconnected Operation | Section 5.5.3 |		| 112 | Disconnected Operation | Section 5.5.3 |
	| 113 | Heuristic Expiration | Section 5.5.4 |		| 113 | Heuristic Expiration | Section 5.5.4 |
	| 199 | Miscellaneous Warning | Section 5.5.5 |		| 199 | Miscellaneous Warning | Section 5.5.5 |
	| 214 | Transformation Applied | Section 5.5.6 |		| 214 | Transformation Applied | Section 5.5.6 |
	| 299 | Miscellaneous Persistent Warning | Section 5.5.7 |		| 299 | Miscellaneous Persistent Warning | Section 5.5.7 |
	+-----------+----------------------------------+---------------+		+-----------+----------------------------------+----------------+
	5.5.1. Warning: 110 - "Response is Stale"		5.5.1. Warning: 110 - "Response is Stale"
	A cache SHOULD generate this whenever the sent response is stale.		A cache SHOULD generate this whenever the sent response is stale.
	5.5.2. Warning: 111 - "Revalidation Failed"		5.5.2. Warning: 111 - "Revalidation Failed"
	A cache SHOULD generate this when sending a stale response because an		A cache SHOULD generate this when sending a stale response because an
	attempt to validate the response failed, due to an inability to reach		attempt to validate the response failed, due to an inability to reach
	the server.		the server.
	skipping to change at line 1544 ¶		skipping to change at page 34, line 21 ¶
	5.5.5. Warning: 199 - "Miscellaneous Warning"		5.5.5. Warning: 199 - "Miscellaneous Warning"
	The warning text can include arbitrary information to be presented to		The warning text can include arbitrary information to be presented to
	a human user or logged. A system receiving this warning MUST NOT		a human user or logged. A system receiving this warning MUST NOT
	take any automated action, besides presenting the warning to the		take any automated action, besides presenting the warning to the
	user.		user.
	5.5.6. Warning: 214 - "Transformation Applied"		5.5.6. Warning: 214 - "Transformation Applied"
	This Warning code MUST be added by a proxy if it applies any		This Warning code MUST be added by a proxy if it applies any
	transformation to the representation, such as changing the		transformation to the representation, such as changing the content-
	content-coding, media-type, or modifying the representation data,		coding, media-type, or modifying the representation data, unless this
	unless this Warning code already appears in the response.		Warning code already appears in the response.
	5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"		5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"
	The warning text can include arbitrary information to be presented to		The warning text can include arbitrary information to be presented to
	a human user or logged. A system receiving this warning MUST NOT		a human user or logged. A system receiving this warning MUST NOT
	take any automated action.		take any automated action.
	7.2. Warn Code Registry		5.5.8. Warn Code Registry
	The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines		The "Hypertext Transfer Protocol (HTTP) Warn Codes" registry defines
	the namespace for warn codes. It has been created and is now		the namespace for warn codes. It has been created and is now
	maintained at <http://www.iana.org/assignments/http-warn-codes>.		maintained at <https://www.iana.org/assignments/http-warn-codes>.
	7.2.1. Procedure
	A registration MUST include the following fields:		A registration MUST include the following fields:
	o Warn Code (3 digits)		o Warn Code (3 digits)
	o Short Description		o Short Description
	o Pointer to specification text		o Pointer to specification text
	Values to be added to this namespace require IETF Review (see		Values to be added to this namespace require IETF Review (see
	skipping to change at line 1587 ¶		skipping to change at page 35, line 13 ¶
	retrieved earlier in a session.		retrieved earlier in a session.
	The freshness model (Section 4.2) does not necessarily apply to		The freshness model (Section 4.2) does not necessarily apply to
	history mechanisms. That is, a history mechanism can display a		history mechanisms. That is, a history mechanism can display a
	previous representation even if it has expired.		previous representation even if it has expired.
	This does not prohibit the history mechanism from telling the user		This does not prohibit the history mechanism from telling the user
	that a view might be stale or from honoring cache directives (e.g.,		that a view might be stale or from honoring cache directives (e.g.,
	Cache-Control: no-store).		Cache-Control: no-store).
	8. Security Considerations		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		In particular, various attacks might be amplified by being stored in
	a shared cache; such "cache poisoning" attacks use the cache to		a shared cache; such "cache poisoning" attacks use the cache to
	distribute a malicious payload to many clients, and are especially		distribute a malicious payload to many clients, and are especially
	effective when an attacker can use implementation flaws, elevated		effective when an attacker can use implementation flaws, elevated
	privileges, or other techniques to insert such a response into a		privileges, or other techniques to insert such a response into a
	cache. One common attack vector for cache poisoning is to exploit		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.
	Likewise, implementation flaws (as well as misunderstanding of cache		Likewise, implementation flaws (as well as misunderstanding of cache
	operation) might lead to caching of sensitive information (e.g.,		operation) might lead to caching of sensitive information (e.g.,
	authentication credentials) that is thought to be private, exposing		authentication credentials) that is thought to be private, exposing
	it to unauthorized parties.		it to unauthorized parties.
	Furthermore, the very use of a cache can bring about privacy		Furthermore, the very use of a cache can bring about privacy
	concerns. For example, if two users share a cache, and the first one		concerns. For example, if two users share a cache, and the first one
	browses to a site, the second may be able to detect that the other		browses to a site, the second may be able to detect that the other
	has been to that site, because the resources from it load more		has been to that site, because the resources from it load more
	quickly, thanks to the cache.		quickly, thanks to the cache.
	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		This section is to be removed before publishing as an RFC.
	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 "Message Headers" registry of "Permanent Message
			Header Field Names" at <https://www.iana.org/assignments/message-
			headers> with the header field names listed in the table 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 Registration
	9. Acknowledgments		Please update the "Hypertext Transfer Protocol (HTTP) Warn Codes"
			registry at <https://www.iana.org/assignments/http-warn-codes> with
			the registration procedure of Section 5.5.8 and the warn code values
			summarized in the table of Section 5.5.
	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-01
			(work in progress), May 2018.
	[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
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	June 2014.
	[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Protocol (HTTP/1.1): Conditional Requests", RFC 7232,		Resource Identifier (URI): Generic Syntax", STD 66,
	June 2014.		RFC 3986, DOI 10.17487/RFC3986, January 2005,
			<https://www.rfc-editor.org/info/rfc3986>.
	[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",		Specifications: ABNF", STD 68, RFC 5234,
	RFC 7233, June 2014.		DOI 10.17487/RFC5234, January 2008,
			<https://www.rfc-editor.org/info/rfc5234>.
	[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-01
			(work in progress), May 2018.
	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,
			<https://www.rfc-editor.org/info/rfc2616>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		DOI 10.17487/RFC5226, May 2008,
			<https://www.rfc-editor.org/info/rfc5226>.
	[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		Appendix A. Collected ABNF
	1.2 of [RFC7230].
			In the collected ABNF below, list rules are expanded as per
			Section 11 of [Semantics].
	Age = delta-seconds		Age = delta-seconds
	Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS		Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
	cache-directive ] )		cache-directive ] )
	Expires = HTTP-date		Expires = HTTP-date
	HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>		HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1>
	OWS = <OWS, see [RFC7230], Section 3.2.3>		OWS = <OWS, see [Semantics], Section 4.3>
	Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS		Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
	pragma-directive ] )		pragma-directive ] )
	Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]		Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
	)		)
	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 ) ]		extension-pragma = token [ "=" ( token / quoted-string ) ]
	field-name = <field-name, see [RFC7230], Section 3.2>		field-name = <field-name, see [Semantics], Section 4.2>
	port = <port, see [RFC7230], Section 2.7>		port = <port, see [RFC3986], Section 3.2.3>
	pragma-directive = "no-cache" / extension-pragma		pragma-directive = "no-cache" / extension-pragma
	pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>		pseudonym = <pseudonym, see [Semantics], Section 5.6.1>
	quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>		quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
	token = <token, see [RFC7230], Section 3.2.6>		token = <token, see [Semantics], Section 4.2.3>
	uri-host = <uri-host, see [RFC7230], Section 2.7>		uri-host = <host, see [RFC3986], Section 3.2.2>
	warn-agent = ( uri-host [ ":" port ] ) / pseudonym		warn-agent = ( uri-host [ ":" port ] ) / pseudonym
	warn-code = 3DIGIT		warn-code = 3DIGIT
	warn-date = DQUOTE HTTP-date DQUOTE		warn-date = DQUOTE HTTP-date DQUOTE
	warn-text = quoted-string		warn-text = quoted-string
	warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date		warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
	]		]
	Appendix A. Changes from RFC 2616		Appendix B. Changes from RFC 7234
	The specification has been substantially rewritten for clarity.
	The conditions under which an authenticated response can be cached		None yet.
	have been clarified. (Section 3.2)
	New status codes can now define that caches are allowed to use		Appendix C. Change Log
	heuristic freshness with them. Caches are now allowed to calculate
	heuristic freshness for URIs with query components. (Section 4.2.2)
	The algorithm for calculating age is now less conservative. Caches		This section is to be removed before publishing as an RFC.
	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		C.1. Between RFC7234 and draft 00
	determine the appropriate response to use when validating.
	(Section 4.3)
	The algorithm for selecting a cached negotiated response to use has		The changes were purely editorial:
	been clarified in several ways. In particular, it now explicitly
	allows header-specific canonicalization when processing selecting
	header fields. (Section 4.1)
	Requirements regarding denial-of-service attack avoidance when		o Change boilerplate and abstract to indicate the "draft" status,
	performing invalidation have been clarified. (Section 4.4)		and update references to ancestor specifications.
	Cache invalidation only occurs when a successful response is		o Remove version "1.1" from document title, indicating that this
	received. (Section 4.4)		specification applies to all HTTP versions.
	Cache directives are explicitly defined to be case-insensitive.		o Adjust historical notes.
	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		o Update links to sibling specifications.
	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 Replace sections listing changes from RFC 2616 by new empty
	noted to not be widely implemented; for example, "private=foo" is		sections referring to RFC 723x.
	interpreted by many caches as simply "private". Additionally, the
	meaning of the qualified form of no-cache has been clarified.
	(Section 5.2.2)
	The "no-cache" response directive's meaning has been clarified.		o Remove acknowledgements specific to RFC 723x.
	(Section 5.2.2.2)
	The one-year limit on Expires header field values has been removed;		o Move "Acknowledgements" to the very end and make them unnumbered.
	instead, the reasoning for using a sensible value is given.
	(Section 5.3)
	The Pragma header field is now only defined for backwards		C.2. Since draft-ietf-httpbis-cache-00
	compatibility; future pragmas are deprecated. (Section 5.4)
	Some requirements regarding production and processing of the Warning		The changes are purely editorial:
	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 Moved all extensibility tips, registration procedures, and
	Registries, and defines considerations for new cache directives.		registry tables from the IANA considerations to normative
	(Section 7.1 and Section 7.2)		sections, reducing the IANA considerations to just instructions
			that will be removed prior to publication as an RFC.
	Index		Index
	1		1
	110 (warn-code) 31		110 (warn-code) 33
	111 (warn-code) 31		111 (warn-code) 33
	112 (warn-code) 31		112 (warn-code) 33
	113 (warn-code) 31		113 (warn-code) 34
	199 (warn-code) 32		199 (warn-code) 34
	2		2
	214 (warn-code) 32		214 (warn-code) 34
	299 (warn-code) 32		299 (warn-code) 34
	A		A
	age 11
	Age header field 21		Age header field 21
			age 11
	C		C
			Cache-Control header field 22
	cache 4		cache 4
	cache entry 5		cache entry 6
	cache key 5-6		cache key 6
	Cache-Control header field 21
	D		D
	Disconnected Operation (warn-text) 31		Disconnected Operation (warn-text) 33
	E		E
	Expires header field 28		Expires header field 29
	explicit expiration time 11		explicit expiration time 11
	F		F
	fresh 11		fresh 11
	freshness lifetime 11		freshness lifetime 11
	G		G
	Grammar		Grammar
	Age 21		Age 21
			ALPHA 5
	Cache-Control 22		Cache-Control 22
	cache-directive 22		cache-directive 22
			CR 5
			CRLF 5
			CTL 5
	delta-seconds 5		delta-seconds 5
	Expires 28		DIGIT 5
	extension-pragma 29		DQUOTE 5
	Pragma 29		Expires 30
	pragma-directive 29		extension-pragma 31
	warn-agent 29		HEXDIG 5
	warn-code 29		HTAB 5
	warn-date 29		LF 5
	warn-text 29		OCTET 5
	Warning 29		Pragma 31
	warning-value 29		pragma-directive 31
			SP 5
			VCHAR 5
			warn-agent 32
			warn-code 32
			warn-date 32
			warn-text 32
			Warning 32
			warning-value 32
	H		H
	Heuristic Expiration (warn-text) 31		Heuristic Expiration (warn-text) 34
	heuristic expiration time 11		heuristic expiration time 11
	M		M
	max-age (cache directive) 22, 26		Miscellaneous Persistent Warning (warn-text) 34
	max-stale (cache directive) 22		Miscellaneous Warning (warn-text) 34
	min-fresh (cache directive) 22		max-age (cache directive) 23, 28
	Miscellaneous Persistent Warning (warn-text) 32		max-stale (cache directive) 23
	Miscellaneous Warning (warn-text) 32		min-fresh (cache directive) 24
	must-revalidate (cache directive) 24		must-revalidate (cache directive) 25
	N		N
	no-cache (cache directive) 23, 25		no-cache (cache directive) 24-25
	no-store (cache directive) 23, 24		no-store (cache directive) 24, 26
	no-transform (cache directive) 23, 25		no-transform (cache directive) 25-26
	O		O
	only-if-cached (cache directive) 23		only-if-cached (cache directive) 25
	P		P
	Pragma header field 29		Pragma header field 30
	private (cache directive) 25		private (cache directive) 27
	private cache 4		private cache 4
	proxy-revalidate (cache directive) 26		proxy-revalidate (cache directive) 27
	public (cache directive) 25		public (cache directive) 27
	R		R
	Response is Stale (warn-text) 30		Response is Stale (warn-text) 33
	Revalidation Failed (warn-text) 31		Revalidation Failed (warn-text) 33
	S		S
	s-maxage (cache directive) 27		s-maxage (cache directive) 28
	shared cache 4		shared cache 4
	stale 11		stale 11
	strong validator 18		strong validator 19
	T		T
	Transformation Applied (warn-text) 32		Transformation Applied (warn-text) 34
	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		USA
	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, NW 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. 167 change blocks.
	468 lines changed or deleted		488 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/