draft-ietf-httpbis-cache-07.txt		draft-ietf-httpbis-cache-08.txt
	HTTP Working Group R. Fielding, Ed.		HTTP Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 7234 (if approved) M. Nottingham, Ed.		Obsoletes: 7234 (if approved) M. Nottingham, Ed.
	Intended status: Standards Track Fastly		Intended status: Standards Track Fastly
	Expires: September 8, 2020 J. Reschke, Ed.		Expires: November 27, 2020 J. Reschke, Ed.
	greenbytes		greenbytes
	March 7, 2020		May 26, 2020
	HTTP Caching		HTTP Caching
	draft-ietf-httpbis-cache-07		draft-ietf-httpbis-cache-08
	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.		This document obsoletes RFC 7234.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<https://lists.w3.org/Archives/Public/ietf-http-wg/>.		<https://lists.w3.org/Archives/Public/ietf-http-wg/>.
	Working Group information can be found at <https://httpwg.org/>;		Working Group information can be found at <https://httpwg.org/>;
	source code and issues list for this draft can be found at		source code and issues list for this draft can be found at
	<https://github.com/httpwg/http-core>.		<https://github.com/httpwg/http-core>.
	The changes in this draft are summarized in Appendix C.8.		The changes in this draft are summarized in Appendix C.9.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 8, 2020.		This Internet-Draft will expire on November 27, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://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
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 6
	2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6		2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 6
	3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7		3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 7
	3.1. Storing Incomplete Responses . . . . . . . . . . . . . . 8		3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8
	3.2. Storing Responses to Authenticated Requests . . . . . . . 9		3.2. Storing Incomplete Responses . . . . . . . . . . . . . . 9
	3.3. Combining Partial Content . . . . . . . . . . . . . . . . 9		3.3. Storing Responses to Authenticated Requests . . . . . . . 9
			3.4. Combining Partial Content . . . . . . . . . . . . . . . . 10
	4. Constructing Responses from Caches . . . . . . . . . . . . . 10		4. Constructing Responses from Caches . . . . . . . . . . . . . 10
	4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 11		4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 11
	4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 13		4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 14
	4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 14		4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 14
	4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 15		4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 15
	4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 16		4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 16
	4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 16		4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 17
	4.3.1. Sending a Validation Request . . . . . . . . . . . . 17		4.3.1. Sending a Validation Request . . . . . . . . . . . . 17
	4.3.2. Handling a Received Validation Request . . . . . . . 17		4.3.2. Handling a Received Validation Request . . . . . . . 18
	4.3.3. Handling a Validation Response . . . . . . . . . . . 19		4.3.3. Handling a Validation Response . . . . . . . . . . . 19
	4.3.4. Freshening Stored Responses upon Validation . . . . . 19		4.3.4. Freshening Stored Responses upon Validation . . . . . 20
	4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20		4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20
	4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21		4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21
	5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 21		5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 22
	5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 22		5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23
	5.2.1. Request Cache-Control Directives . . . . . . . . . . 23		5.2.1. Request Cache-Control Directives . . . . . . . . . . 24
	5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 23		5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 24
	5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 24		5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 24
	5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 24		5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25
	5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 24		5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25
	5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25		5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25
	5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 25		5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 26
	5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 25		5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 26
	5.2.2. Response Cache-Control Directives . . . . . . . . . . 25		5.2.2. Response Cache-Control Directives . . . . . . . . . . 26
	5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 25		5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 26
	5.2.2.2. must-understand . . . . . . . . . . . . . . . . . 26		5.2.2.2. must-understand . . . . . . . . . . . . . . . . . 27
	5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 26		5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 27
	5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 27		5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 28
	5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 27		5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 28
	5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 27		5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 28
	5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28		5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28
	5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 28		5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 29
	5.2.2.9. max-age . . . . . . . . . . . . . . . . . . . . . 29		5.2.2.9. max-age . . . . . . . . . . . . . . . . . . . . . 29
	5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 29		5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 30
	5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 29		5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30
	5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 30		5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31
	5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31		5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31
	5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32		5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32
	5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 32		5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33
	6. Relationship to Applications . . . . . . . . . . . . . . . . 32		6. Relationship to Applications . . . . . . . . . . . . . . . . 33
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 33		7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 33		7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34
	7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 33		7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34
	7.3. Caching of Sensitive Information . . . . . . . . . . . . 34		7.3. Caching of Sensitive Information . . . . . . . . . . . . 34
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	8.1. Field Registration . . . . . . . . . . . . . . . . . . . 34		8.1. Field Registration . . . . . . . . . . . . . . . . . . . 35
	8.2. Cache Directive Registration . . . . . . . . . . . . . . 34		8.2. Cache Directive Registration . . . . . . . . . . . . . . 35
	8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 34		8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 35
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	9.1. Normative References . . . . . . . . . . . . . . . . . . 34		9.1. Normative References . . . . . . . . . . . . . . . . . . 35
	9.2. Informative References . . . . . . . . . . . . . . . . . 35		9.2. Informative References . . . . . . . . . . . . . . . . . 36
	Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 37		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 37
	Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 37		Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 37
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 38
	C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 38		C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 38
	C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 38		C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 38
	C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 38		C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 38
	C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 38		C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 38
	C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 39		C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 39
	C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 39		C.6. Since draft-ietf-httpbis-cache-04 . . . . . . . . . . . . 39
	C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 39		C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 39
	C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 40		C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 40
			C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 40
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 42		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level request/response protocol that uses extensible semantics and		level request/response protocol that uses extensible semantics and
	self-descriptive messages for flexible interaction with network-based		self-descriptive messages for flexible interaction with network-based
	hypertext information systems. HTTP is defined by a series of		hypertext information systems. HTTP is defined by a series of
	documents that collectively form the HTTP/1.1 specification:		documents that collectively form the HTTP/1.1 specification:
	skipping to change at page 7, line 17 ¶		skipping to change at page 7, line 17 ¶
	responses by incorporating values of the original request's selecting		responses by incorporating values of the original request's selecting
	header fields into the cache key as well, as per Section 4.1.		header fields into the cache key as well, as per Section 4.1.
	Furthermore, caches might incorporate additional material into the		Furthermore, caches might incorporate additional material into the
	cache key. For example, user agent caches might include the		cache key. For example, user agent caches might include the
	referring site's identity, thereby "double keying" the cache to avoid		referring site's identity, thereby "double keying" the cache to avoid
	some privacy risks (see Section 7.2).		some privacy risks (see Section 7.2).
	Most commonly, caches store the successful result of a retrieval		Most commonly, caches store the successful result of a retrieval
	request: i.e., a 200 (OK) response to a GET request, which contains a		request: i.e., a 200 (OK) response to a GET request, which contains a
	representation of the resource identified by the request target		representation of the target resource (Section 7.3.1 of [Semantics]).
	(Section 7.3.1 of [Semantics]). However, it is also possible to		However, it is also possible to store redirects, negative results
	store redirects, negative results (e.g., 404 (Not Found)), incomplete		(e.g., 404 (Not Found)), incomplete results (e.g., 206 (Partial
	results (e.g., 206 (Partial Content)), and responses to methods other		Content)), and responses to methods other than GET if the method's
	than GET if the method's definition allows such caching and defines		definition allows such caching and defines something suitable for use
	something suitable for use as a cache key.		as a cache key.
	A cache is disconnected when it cannot contact the origin server or		A cache is disconnected when it cannot contact the origin server or
	otherwise find a forward path for a given request. A disconnected		otherwise find a forward path for a given request. A disconnected
	cache can serve stale responses in some circumstances		cache can serve stale responses in some circumstances
	(Section 4.2.4).		(Section 4.2.4).
	3. Storing Responses in Caches		3. Storing Responses in Caches
	A cache MUST NOT store a response to a request unless:		A cache MUST NOT store a response to a request unless:
	skipping to change at page 7, line 51 ¶		skipping to change at page 7, line 51 ¶
	o the "no-store" cache directive is not present in the response (see		o the "no-store" cache directive is not present in the response (see
	Section 5.2);		Section 5.2);
	o if the cache is shared: the "private" response directive is either		o if the cache is shared: the "private" response directive is either
	not present or allows a modified response to be stored by a shared		not present or allows a modified response to be stored by a shared
	cache; see Section 5.2.2.7);		cache; see Section 5.2.2.7);
	o if the cache is shared: the Authorization header field is not		o if the cache is shared: the Authorization header field is not
	present in the request (see Section 8.5.3 of [Semantics]) or a		present in the request (see Section 8.5.3 of [Semantics]) or a
	response directive is present that explicitly allows shared		response directive is present that explicitly allows shared
	caching (see Section 3.2); and,		caching (see Section 3.3); and,
	o the response contains at least one of:		o the response contains at least one of:
	* a public response directive (see Section 5.2.2.6);		* a public response directive (see Section 5.2.2.6);
			* a private response directive, if the cache is not shared (see
			Section 5.2.2.7);
	* an Expires header field (see Section 5.3);		* an Expires header field (see Section 5.3);
	* a max-age response directive (see Section 5.2.2.9);		* a max-age response directive (see Section 5.2.2.9);
	* if the cache is shared, an s-maxage response directive (see		* if the cache is shared, an s-maxage response directive (see
	Section 5.2.2.10);		Section 5.2.2.10);
	* a Cache Control Extension that allows it to be cached (see		* a Cache Control Extension that allows it to be cached (see
	Section 5.2.3); or,		Section 5.2.3); or,
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 37 ¶
	In this context, a cache has "understood" a request method or a		In this context, a cache has "understood" a request method or a
	response status code if it recognizes it and implements all specified		response status code if it recognizes it and implements all specified
	caching-related behavior.		caching-related behavior.
	Note that, in normal operation, some caches will not store a response		Note that, in normal operation, some caches will not store a response
	that has neither a cache validator nor an explicit expiration time,		that has neither a cache validator nor an explicit expiration time,
	as such responses are not usually useful to store. However, caches		as such responses are not usually useful to store. However, caches
	are not prohibited from storing such responses.		are not prohibited from storing such responses.
	3.1. Storing Incomplete Responses		3.1. Storing Header and Trailer Fields
	A response message is considered complete when all of the octets		Caches MUST include all received header fields -- including
	indicated by its framing are available. Note that, when no explicit		unrecognised ones -- when storing a response; this assures that new
	framing is provided, a response message that is ended by the		HTTP header fields can be successfully deployed. However, the
	connection's close is considered complete even though it might be		following exceptions are made:
	indistinguishable from an incomplete response (see [Messaging],
	Section 6.3). A cache SHOULD consider a close-terminated response		o The Connection header field and fields whose names are listed in
	incomplete if the connection termination is detected to be an error.		it are required by Section 13.1 of [Semantics] to be removed
	A server that wishes to avoid premature termination resulting in an		before forwarding the message. This MAY be implemented by doing
	incorrect cached response SHOULD send the response with explicit		so before storage.
	framing.
			o Likewise, some fields' semantics require them to be removed before
			forwarding the message, and this MAY be implemented by doing so
			before storage; see Section 13.1 of [Semantics] for some examples.
			o Header fields that are specific to a client's proxy configuration
			MUST NOT be stored, unless the cache incorporates the identity of
			the proxy into the cache key. Effectively, this is limited to
			Proxy-Authenticate Section 10.3.2 of [Semantics], Proxy-
			Authentication-Info Section 10.3.4 of [Semantics], and Proxy-
			Authorization Section 8.5.4 of [Semantics].
			Caches MAY either store trailer fields separately from header fields,
			or discard them. Caches MUST NOT combine trailer fields with header
			fields.
			3.2. Storing Incomplete Responses
	If the request method is GET, the response status code is 200 (OK),		If the request method is GET, the response status code is 200 (OK),
	and the entire response header section has been received, a cache MAY		and the entire response header section has been received, a cache MAY
	store an incomplete response message body if the stored response is		store a response body that is not complete (Section 2.1 of
	recorded as incomplete. Likewise, a 206 (Partial Content) response		[Semantics]) if the stored response is recorded as being incomplete.
	MAY be stored as if it were an incomplete 200 (OK) response.		Likewise, a 206 (Partial Content) response MAY be stored as if it
	However, a cache MUST NOT store incomplete or partial-content		were an incomplete 200 (OK) response. However, a cache MUST NOT
	responses if it does not support the Range and Content-Range header		store incomplete or partial-content responses if it does not support
	fields or if it does not understand the range units used in those		the Range and Content-Range header fields or if it does not
	fields.		understand the range units used in those fields.
	A cache MAY complete a stored incomplete response by making a		A cache MAY complete a stored incomplete response by making a
	subsequent range request (Section 8.3 of [Semantics]) and combining		subsequent range request (Section 8.3 of [Semantics]) and combining
	the successful response with the stored response, as defined in		the successful response with the stored response, as defined in
	Section 3.3. A cache MUST NOT use an incomplete response to answer		Section 3.4. A cache MUST NOT use an incomplete response to answer
	requests unless the response has been made complete or the request is		requests unless the response has been made complete or the request is
	partial and specifies a range that is wholly within the incomplete		partial and specifies a range that is wholly within the incomplete
	response. A cache MUST NOT send a partial response to a client		response. A cache MUST NOT send a partial response to a client
	without explicitly marking it as such using the 206 (Partial Content)		without explicitly marking it as such using the 206 (Partial Content)
	status code.		status code.
	3.2. Storing Responses to Authenticated Requests		3.3. 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 8.5.3 of [Semantics]) to satisfy		Authorization header field (Section 8.5.3 of [Semantics]) to satisfy
	any subsequent request unless the response contains a Cache-Control		any subsequent request unless the response contains a Cache-Control
	field with a response directive (Section 5.2.2) that allows it to be		field with a response directive (Section 5.2.2) that allows it to be
	stored by a shared cache and the cache conforms to the requirements		stored by a shared cache and the cache conforms to the requirements
	of that directive for that response.		of that directive for that response.
	In this specification, the following response directives have such an		In this specification, the following response directives have such an
	effect: must-revalidate (Section 5.2.2.1), public (Section 5.2.2.6),		effect: must-revalidate (Section 5.2.2.1), public (Section 5.2.2.6),
	and s-maxage (Section 5.2.2.10).		and s-maxage (Section 5.2.2.10).
	3.3. Combining Partial Content		3.4. Combining Partial Content
	A response might transfer only a partial representation if the		A response might transfer only a partial representation if the
	connection closed prematurely or if the request used one or more		connection closed prematurely or if the request used one or more
	Range specifiers (Section 8.3 of [Semantics]). After several such		Range specifiers (Section 8.3 of [Semantics]). After several such
	transfers, a cache might have received several ranges of the same		transfers, a cache might have received several ranges of the same
	representation. A cache MAY combine these ranges into a single		representation. A cache MAY combine these ranges into a single
	stored response, and reuse that response to satisfy later requests,		stored response, and reuse that response to satisfy later requests,
	if they all share the same strong validator and the cache complies		if they all share the same strong validator and the cache complies
	with the client requirements in Section 9.3.7.3 of [Semantics].		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 use the header fields provided in the new response, aside		cache MUST use the header fields provided in the new response, aside
	from Content-Range, to replace all instances of the corresponding		from 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 [Semantics])		o The presented target URI (Section 5.1 of [Semantics]) and that of
	and that of the stored response match, and		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 stored response does not contain the no-cache cache directive		o the stored response does not contain the no-cache cache directive
	(Section 5.2.2.3), unless it is successfully validated		(Section 5.2.2.3), unless it is successfully validated
	(Section 4.3), and		(Section 4.3), and
	skipping to change at page 17, line 10 ¶		skipping to change at page 17, line 28 ¶
	stored response to use, updating the stored metadata in the process,		stored response to use, updating the stored metadata in the process,
	or to replace the stored response(s) with a new response. This		or to replace the stored response(s) with a new response. This
	process is known as "validating" or "revalidating" the stored		process is known as "validating" or "revalidating" the stored
	response.		response.
	4.3.1. Sending a Validation Request		4.3.1. Sending a Validation Request
	When generating a conditional request for validation, a cache starts		When generating a conditional request for validation, a cache starts
	with either a request it is attempting to satisfy, or -- if it is		with either a request it is attempting to satisfy, or -- if it is
	initiating the request independently -- it synthesises a request		initiating the request independently -- it synthesises a request
	using a stored response by copying the method, request-target, and		using a stored response by copying the method, target URI, and
	request header fields identified by the Vary header field		request header fields identified by the Vary header field
	Section 4.1.		Section 4.1.
	It then updates that request with one or more precondition header		It then updates that request with one or more precondition header
	fields. These contain validator metadata sourced from stored		fields. These contain validator metadata sourced from stored
	response(s) that have the same cache key.		response(s) that have the same cache key.
	The precondition header fields are then compared by recipients to		The precondition header fields are then compared by recipients to
	determine whether any stored response is equivalent to a current		determine whether any stored response is equivalent to a current
	representation of the resource.		representation of the resource.
	skipping to change at page 20, line 17 ¶		skipping to change at page 20, line 38 ¶
	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
	identified for update.		identified for update.
	For each stored response identified for update, the cache MUST use		For each stored response identified for update, the cache MUST use
	the header fields provided in the 304 (Not Modified) response to		the header fields provided in the 304 (Not Modified) response to
	replace all instances of the corresponding header fields in the		replace all instances of the corresponding header fields in the
	stored response.		stored response, with the following exceptions:
			o The exceptions to header field storage in Section 3.1 also apply
			to header field updates.
			o Caches MUST NOT update the following header fields: Content-
			Encoding, Content-Length, Content-MD5 (Section 14.15 of
			[RFC2616]), Content-Range, ETag.
	4.3.5. Freshening Responses with HEAD		4.3.5. Freshening Responses with HEAD
	A response to the HEAD method is identical to what an equivalent		A response to the HEAD method is identical to what an equivalent
	request made with a GET would have been, except it lacks a body.		request made with a GET would have been, except it lacks a body.
	This property of HEAD responses can be used to invalidate or update a		This property of HEAD responses can be used to invalidate or update a
	cached GET response if the more efficient conditional GET request		cached GET response if the more efficient conditional GET request
	mechanism is not available (due to no validators being present in the		mechanism is not available (due to no validators being present in the
	stored response) or if transmission of the representation body is not		stored response) or if transmission of the representation body is not
	desired even if it has changed.		desired even if it has changed.
	When a cache makes an inbound HEAD request for a given request target		When a cache makes an inbound HEAD request for a given target URI and
	and receives a 200 (OK) response, the cache SHOULD update or		receives a 200 (OK) response, the cache SHOULD update or invalidate
	invalidate each of its stored GET responses that could have been		each of its stored GET responses that could have been selected for
	selected for that request (see Section 4.1).		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 Content-		response has a Content-Length header field, the value of Content-
	Length matches that of the stored response, the cache SHOULD update		Length matches that of the stored response, the cache SHOULD update
	the stored response as described below; otherwise, the cache SHOULD		the stored response as described below; otherwise, the cache 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 use the header fields provided in the		HEAD response, the cache MUST use the header fields provided in the
	HEAD response to replace all instances of the corresponding header		HEAD response to replace all instances of the corresponding header
	fields in the stored response and append new header fields to the		fields in the stored response (subject to the exceptions in
	stored response's header section unless otherwise restricted by the		Section 4.3.4) and append new header fields to the stored response's
	Cache-Control header field.		header section unless otherwise restricted by the Cache-Control
			header field.
	4.4. Invalidation		4.4. Invalidation
	Because unsafe request methods (Section 7.2.1 of [Semantics]) 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 are required to invalidate stored
	up to date.		responses to keep their contents up to date. Invalidate means that
			the cache will either remove all stored responses whose target URI
			matches the given URI, or will mark them as "invalid" and in need of
			a mandatory validation before they can be sent in response to a
			subsequent request.
	A cache MUST invalidate the effective Request URI (Section 5.5 of		Note that this does not guarantee that all appropriate responses are
	[Semantics]) as well as the URI(s) in the Location and Content-		invalidated globally; a state-changing request would only invalidate
	Location response header fields (if present) when a non-error status		responses in the caches that it travels through.
	code is received in response to an unsafe request method.
			A cache MUST invalidate the target URI (Section 5.1 of [Semantics])
			as well as the URI(s) in the Location and Content-Location response
			header fields (if present) when a non-error status 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 target URI (Section 5.1 of
	of [Semantics]). This helps prevent denial-of-service attacks.		[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 target URI (Section 5.1 of [Semantics])
	[Semantics]) when it receives a non-error response to a request with		when it receives a non-error response to a request with a method
	a method whose safety is unknown.		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.
	either remove all stored responses related to the effective request
	URI or will mark these as "invalid" and in need of a mandatory
	validation before they can be sent in response to a subsequent
	request.
	Note that this does not guarantee that all appropriate responses are
	invalidated. For example, a state-changing request might invalidate
	responses in the caches it travels through, but relevant responses
	still might be stored in other caches that it has not.
	5. Field Definitions		5. Field Definitions
	This section defines the syntax and semantics of HTTP fields related		This section defines the syntax and semantics of HTTP fields related
	to caching.		to caching.
	+---------------+-----------+--------------+		+---------------+-----------+--------------+
	| Field Name | Status | Reference |		| Field Name | Status | Reference |
	+---------------+-----------+--------------+		+---------------+-----------+--------------+
	| Age | standard | Section 5.1 |		| Age | standard | Section 5.1 |
	skipping to change at page 26, line 18 ¶		skipping to change at page 26, line 50 ¶
	cache is disconnected, the cache MUST generate a 504 (Gateway		cache is disconnected, the cache MUST generate a 504 (Gateway
	Timeout) response rather than reuse the stale response.		Timeout) response rather than reuse the stale response.
	The must-revalidate directive ought to be used by servers if and only		The must-revalidate directive ought to be used by servers if and only
	if failure to validate a request on the representation could result		if failure to validate a request on the representation could result
	in incorrect operation, such as a silently unexecuted financial		in incorrect operation, such as a silently unexecuted financial
	transaction.		transaction.
	The must-revalidate directive also permits a shared cache to reuse a		The must-revalidate directive also permits a shared cache to reuse a
	response to a request containing an Authorization header field,		response to a request containing an Authorization header field,
	subject to the above requirement on revalidation (Section 3.2).		subject to the above requirement on revalidation (Section 3.3).
	5.2.2.2. must-understand		5.2.2.2. must-understand
	The "must-understand" response directive limits caching of the		The "must-understand" response directive limits caching of the
	response to a cache that understands and conforms to the requirements		response to a cache that understands and conforms to the requirements
	for that response's status code. A cache MUST NOT store a response		for that response's status code. A cache MUST NOT store a response
	containing the must-understand directive if the cache does not		containing the must-understand directive if the cache does not
	understand the response status code.		understand the response status code.
	5.2.2.3. no-cache		5.2.2.3. no-cache
	skipping to change at page 27, line 45 ¶		skipping to change at page 28, line 32 ¶
	5.2.2.5. no-transform		5.2.2.5. 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 [Semantics].		payload, as defined in Section 5.7.2 of [Semantics].
	5.2.2.6. public		5.2.2.6. public
	The "public" response directive indicates that a cache MAY store the		The "public" response directive indicates that a cache MAY store the
	response even if it would otherwise be prohibited, subject to the		response even if it would otherwise be prohibited, subject to the
	constraints of any other response directives present. In other		constraints defined in Section 3. In other words, public explicitly
	words, public explicitly marks the response as cacheable. For		marks the response as cacheable. For example, public permits a
	example, public permits a shared cache to reuse a response to a		shared cache to reuse a response to a request containing an
	request containing an Authorization header field (Section 3.2).		Authorization header field (Section 3.3).
	If no explicit freshness information is provided, the response is is		Note that it is not necessary to add the public directive to a
	heuristically cacheable (Section 4.2.2).		response that is already cacheable according to Section 3.
			If no explicit freshness information is provided on a response with
			the public directive, it is heuristically cacheable (Section 4.2.2).
	5.2.2.7. private		5.2.2.7. private
	Argument syntax:		Argument syntax:
	#field-name		#field-name
	The unqualified "private" response directive indicates that a shared		The unqualified "private" response directive indicates that a shared
	cache MUST NOT store the response (i.e., the response is intended for		cache MUST NOT store the response (i.e., the response is intended for
	a single user). It also indicates that a private cache MAY store the		a single user). It also indicates that a private cache MAY store the
	response, subject to any other cache directives present, even if the		response, subject the constraints defined in Section 3, even if the
	response would not otherwise be heuristically cacheable by a private		response would not otherwise be heuristically cacheable by a private
	cache.		cache.
	If a qualified private response directive is present, with an		If a qualified private response directive is present, with an
	argument that lists one or more field names, then only the listed		argument that lists one or more field names, then only the listed
	fields are limited to a single user: a shared cache MUST NOT store		fields are limited to a single user: a shared cache MUST NOT store
	the listed fields if they are present in the original response, but		the listed fields if they are present in the original response, but
	MAY store the remainder of the response message without those fields.		MAY store the remainder of the response message without those fields,
			subject the constraints defined in Section 3.
	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: This usage of the word "private" only controls where the		Note: This usage of the word "private" only controls where the
	response can be stored; it cannot ensure the privacy of the message		response can be stored; it cannot ensure the privacy of the message
	skipping to change at page 29, line 37 ¶		skipping to change at page 30, line 27 ¶
	specified by either the max-age directive or the Expires header		specified by either the max-age directive or the Expires header
	field.		field.
	The s-maxage directive incorporates the proxy-revalidate		The s-maxage directive incorporates the proxy-revalidate
	(Section 5.2.2.8) response directive's semantics for a shared cache.		(Section 5.2.2.8) response directive's semantics for a shared cache.
	A shared cache MUST NOT reuse a stale response with s-maxage to		A shared cache MUST NOT reuse a stale response with s-maxage to
	satisfy another request until it has been successfully validated by		satisfy another request until it has been successfully validated by
	the origin, as defined by Section 4.3. This directive also permits a		the origin, as defined by Section 4.3. This directive also permits a
	shared cache to reuse a response to a request containing an		shared cache to reuse a response to a request containing an
	Authorization header field, subject to the above requirements on		Authorization header field, subject to the above requirements on
	maximum age and revalidation (Section 3.2).		maximum age and revalidation (Section 3.3).
	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 MUST NOT generate the		's-maxage=10' not 's-maxage="10"'. A sender MUST NOT generate the
	quoted-string form.		quoted-string form.
	5.2.3. Cache Control Extensions		5.2.3. Cache Control Extensions
	The Cache-Control header field can be extended through the use of one		The Cache-Control header field can be extended through the use of one
	or more cache-extension tokens, each with an optional value. A cache		or more cache-extension tokens, each with an optional value. A cache
	MUST ignore unrecognized cache directives.		MUST ignore unrecognized cache directives.
	skipping to change at page 34, line 48 ¶		skipping to change at page 35, line 30 ¶
	Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn		Please add a note to the "Hypertext Transfer Protocol (HTTP) Warn
	Codes" registry at <https://www.iana.org/assignments/http-warn-codes>		Codes" registry at <https://www.iana.org/assignments/http-warn-codes>
	to the effect that Warning is obsoleted.		to the effect that Warning is obsoleted.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[Messaging]		[Messaging]
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-07		Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-08
	(work in progress), March 2020.		(work in progress), May 2020.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	skipping to change at page 35, line 30 ¶		skipping to change at page 36, line 11 ¶
	[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",		[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
	RFC 7405, DOI 10.17487/RFC7405, December 2014,		RFC 7405, DOI 10.17487/RFC7405, December 2014,
	<https://www.rfc-editor.org/info/rfc7405>.		<https://www.rfc-editor.org/info/rfc7405>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[Semantics]		[Semantics]
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-07		Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-08
	(work in progress), March 2020.		(work in progress), May 2020.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	9.2. Informative References		9.2. Informative References
	[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,		Transfer Protocol -- HTTP/1.1", RFC 2616,
	skipping to change at page 37, line 49 ¶		skipping to change at page 37, line 49 ¶
	The "public" and "private" cache directives were clarified, so that		The "public" and "private" cache directives were clarified, so that
	they do not make responses reusable under any condition.		they do not make responses reusable under any condition.
	(Section 5.2.2)		(Section 5.2.2)
	The "must-understand" cache directive was introduced; caches are no		The "must-understand" cache directive was introduced; caches are no
	longer required to understand the semantics of new response status		longer required to understand the semantics of new response status
	codes unless it is present. (Section 5.2.2.2)		codes unless it is present. (Section 5.2.2.2)
	The Warning response header was obsoleted. Much of the information		The Warning response header was obsoleted. Much of the information
	supported by Warning could be gleaned by examining the response), and		supported by Warning could be gleaned by examining the response, and
	the remaining warn-codes -- although potentially useful -- were		the remaining warn-codes -- although potentially useful -- were
	entirely advisory, and in practice were not added by caches or		entirely advisory. In practice, Warning was not added by caches or
	intermediaries. (Section 5.5)		intermediaries. (Section 5.5)
	Appendix C. Change Log		Appendix C. Change Log
	This section is to be removed before publishing as an RFC.		This section is to be removed before publishing as an RFC.
	C.1. Between RFC7234 and draft 00		C.1. Between RFC7234 and draft 00
	The changes were purely editorial:		The changes were purely editorial:
	skipping to change at page 39, line 17 ¶		skipping to change at page 39, line 17 ¶
	o In Section 4.3.1, clarify the source of validators in conditional		o In Section 4.3.1, clarify the source of validators in conditional
	requests (<https://github.com/httpwg/http-core/issues/110>)		requests (<https://github.com/httpwg/http-core/issues/110>)
	o Revise Section 6 to apply to more than just History Lists		o Revise Section 6 to apply to more than just History Lists
	(<https://github.com/httpwg/http-core/issues/126>)		(<https://github.com/httpwg/http-core/issues/126>)
	o In Section 5.5, deprecated "Warning" header field		o In Section 5.5, deprecated "Warning" header field
	(<https://github.com/httpwg/http-core/issues/139>)		(<https://github.com/httpwg/http-core/issues/139>)
	o In Section 3.2, remove a spurious note		o In Section 3.3, remove a spurious note
	(<https://github.com/httpwg/http-core/issues/141>)		(<https://github.com/httpwg/http-core/issues/141>)
	C.5. Since draft-ietf-httpbis-cache-03		C.5. Since draft-ietf-httpbis-cache-03
	o In Section 2, define what a disconnected cache is		o In Section 2, define what a disconnected cache is
	(<https://github.com/httpwg/http-core/issues/5>)		(<https://github.com/httpwg/http-core/issues/5>)
	o In Section 4, clarify language around how to select a response		o In Section 4, clarify language around how to select a response
	when more than one matches (<https://github.com/httpwg/http-core/		when more than one matches (<https://github.com/httpwg/http-core/
	issues/23>)		issues/23>)
	o in Section 4.2.4, mention stale-while-revalidate and stale-if-		o in Section 4.2.4, mention stale-while-revalidate and stale-if-
	error (<https://github.com/httpwg/http-core/issues/122>)		error (<https://github.com/httpwg/http-core/issues/122>)
	o Remove requirements around cache request directives		o Remove requirements around cache request directives
	(<https://github.com/httpwg/http-core/issues/129>)		(<https://github.com/httpwg/http-core/issues/129>)
	o Deprecate Pragma (<https://github.com/httpwg/http-core/		o Deprecate Pragma (<https://github.com/httpwg/http-core/
	issues/140>)		issues/140>)
	o In Section 3.2 and Section 5.2.2, note effect of some directives		o In Section 3.3 and Section 5.2.2, note effect of some directives
	on authenticated requests (<https://github.com/httpwg/http-core/		on authenticated requests (<https://github.com/httpwg/http-core/
	issues/161>)		issues/161>)
	C.6. Since draft-ietf-httpbis-cache-04		C.6. Since draft-ietf-httpbis-cache-04
	o In Section 5.2, remove the registrations for stale-if-error and		o In Section 5.2, remove the registrations for stale-if-error and
	stale-while-revalidate which happened in RFC 7234		stale-while-revalidate which happened in RFC 7234
	(<https://github.com/httpwg/http-core/issues/207>)		(<https://github.com/httpwg/http-core/issues/207>)
	C.7. Since draft-ietf-httpbis-cache-05		C.7. Since draft-ietf-httpbis-cache-05
	o In Section 3.1, clarify how weakly framed content is considered		o In Section 3.2, clarify how weakly framed content is considered
	for purposes of completeness (<https://github.com/httpwg/http-		for purposes of completeness (<https://github.com/httpwg/http-
	core/issues/25>)		core/issues/25>)
	o Throughout, describe Vary and cache key operations more clearly		o Throughout, describe Vary and cache key operations more clearly
	(<https://github.com/httpwg/http-core/issues/28>)		(<https://github.com/httpwg/http-core/issues/28>)
	o In Section 3, remove concept of "cacheable methods" in favor of		o In Section 3, remove concept of "cacheable methods" in favor of
	prose (<https://github.com/httpwg/http-core/issues/54>,		prose (<https://github.com/httpwg/http-core/issues/54>,
	<https://www.rfc-editor.org/errata/eid5300>)		<https://www.rfc-editor.org/errata/eid5300>)
	skipping to change at page 41, line 5 ¶		skipping to change at page 40, line 46 ¶
	o In Section 3, distinguish between private with and without		o In Section 3, distinguish between private with and without
	qualifying headers (<https://github.com/httpwg/http-core/		qualifying headers (<https://github.com/httpwg/http-core/
	issues/270>)		issues/270>)
	o In Section 4.1, clarify that any "*" as a member of Vary will		o In Section 4.1, clarify that any "*" as a member of Vary will
	disable caching (<https://github.com/httpwg/http-core/issues/286>)		disable caching (<https://github.com/httpwg/http-core/issues/286>)
	o In Section 1.1, reference RFC 8174 as well		o In Section 1.1, reference RFC 8174 as well
	(<https://github.com/httpwg/http-core/issues/303>)		(<https://github.com/httpwg/http-core/issues/303>)
			C.9. Since draft-ietf-httpbis-cache-07
			o Throughout, replace "effective request URI", "request-target" and
			similar with "target URI" (<https://github.com/httpwg/http-core/
			issues/259>)
			o In Section 5.2.2.6 and Section 5.2.2.7, make it clear that these
			directives do not ignore other requirements for caching
			(<https://github.com/httpwg/http-core/issues/320>)
			o In Section 3.2, move definition of "complete" into semantics
			(<https://github.com/httpwg/http-core/issues/334>)
	Index		Index
	A		A
	Age header field 22		Age header field 22
	age 12		age 12
	C		C
	Cache-Control header field 22		Cache-Control header field 23
	cache 4		cache 4
	cache key 6		cache key 6
	E		E
	Expires header field 31		Expires header field 31
	explicit expiration time 12		explicit expiration time 12
	F		F
	Fields		Fields
	Age 22		Age 22
	Cache-Control 22		Cache-Control 23
	Expires 31		Expires 31
	Pragma 32		Pragma 32
	Warning 32		Warning 33
	fresh 12		fresh 12
	freshness lifetime 12		freshness lifetime 12
	G		G
	Grammar		Grammar
	Age 22		Age 22
	ALPHA 5		ALPHA 5
	Cache-Control 23		Cache-Control 23
	cache-directive 23		cache-directive 23
	CR 5		CR 5
	CRLF 5		CRLF 5
	CTL 5		CTL 5
	delta-seconds 6		delta-seconds 6
	DIGIT 5		DIGIT 5
	DQUOTE 5		DQUOTE 5
	Expires 31		Expires 32
	HEXDIG 5		HEXDIG 5
	HTAB 5		HTAB 5
	LF 5		LF 5
	OCTET 5		OCTET 5
	SP 5		SP 5
	VCHAR 5		VCHAR 5
	H		H
	Header Fields		Header Fields
	Age 22		Age 22
	Cache-Control 22		Cache-Control 23
	Expires 31		Expires 31
	Pragma 32		Pragma 32
	Warning 32		Warning 33
	heuristic expiration time 12		heuristic expiration time 12
	heuristically cacheable 14		heuristically cacheable 14
	M		M
	max-age (cache directive) 23, 29		max-age (cache directive) 24, 29
	max-stale (cache directive) 24		max-stale (cache directive) 24
	min-fresh (cache directive) 24		min-fresh (cache directive) 25
	must-revalidate (cache directive) 25		must-revalidate (cache directive) 26
	must-understand (cache directive) 26		must-understand (cache directive) 27
	N		N
	no-cache (cache directive) 24, 26		no-cache (cache directive) 25, 27
	no-store (cache directive) 25, 27		no-store (cache directive) 25, 28
	no-transform (cache directive) 25, 27		no-transform (cache directive) 26, 28
	O		O
	only-if-cached (cache directive) 25		only-if-cached (cache directive) 26
	P		P
	Pragma header field 32		Pragma header field 32
	private (cache directive) 28		private (cache directive) 28
	private cache 4		private cache 4
	proxy-revalidate (cache directive) 28		proxy-revalidate (cache directive) 29
	public (cache directive) 27		public (cache directive) 28
	S		S
	s-maxage (cache directive) 29		s-maxage (cache directive) 30
	shared cache 4		shared cache 4
	stale 12		stale 12
	strong validator 19		strong validator 20
	V		V
	validator 17		validator 17
	W		W
	Warning header field 32		Warning header field 33
	Acknowledgments		Acknowledgments
	See Appendix "Acknowledgments" of [Semantics].		See Appendix "Acknowledgments" of [Semantics].
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe		Adobe
	345 Park Ave		345 Park Ave
End of changes. 68 change blocks.
	141 lines changed or deleted		185 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/