draft-ietf-httpbis-cache-15.txt		draft-ietf-httpbis-cache-16.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: 1 October 2021 J. Reschke, Ed.		Expires: 28 November 2021 J. Reschke, Ed.
	greenbytes		greenbytes
	30 March 2021		27 May 2021
	HTTP Caching		HTTP Caching
	draft-ietf-httpbis-cache-15		draft-ietf-httpbis-cache-16
	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.16.		The changes in this draft are summarized in Appendix C.17.
	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 1 October 2021.		This Internet-Draft will expire on 28 November 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	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. Requirements Notation . . . . . . . . . . . . . . . . . . 5		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 5		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 Header and Trailer Fields . . . . . . . . . . . . 8		3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8
	3.2. Updating Stored Header Fields . . . . . . . . . . . . . . 9		3.2. Updating Stored Header Fields . . . . . . . . . . . . . . 9
	3.3. Storing Incomplete Responses . . . . . . . . . . . . . . 10		3.3. Storing Incomplete Responses . . . . . . . . . . . . . . 10
	3.4. Combining Partial Content . . . . . . . . . . . . . . . . 11		3.4. Combining Partial Content . . . . . . . . . . . . . . . . 11
	3.5. Storing Responses to Authenticated Requests . . . . . . . 11		3.5. Storing Responses to Authenticated Requests . . . . . . . 11
	4. Constructing Responses from Caches . . . . . . . . . . . . . 11		4. Constructing Responses from Caches . . . . . . . . . . . . . 11
	4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 12		4.1. Calculating Cache Keys with Vary . . . . . . . . . . . . 12
	4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 14		4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 14
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	4.3.1. Sending a Validation Request . . . . . . . . . . . . 19		4.3.1. Sending a Validation Request . . . . . . . . . . . . 19
	4.3.2. Handling a Received Validation Request . . . . . . . 19		4.3.2. Handling a Received Validation Request . . . . . . . 19
	4.3.3. Handling a Validation Response . . . . . . . . . . . 21		4.3.3. Handling a Validation Response . . . . . . . . . . . 21
	4.3.4. Freshening Stored Responses upon Validation . . . . . 21		4.3.4. Freshening Stored Responses upon Validation . . . . . 21
	4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 22		4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 22
	4.4. Invalidating Stored Responses . . . . . . . . . . . . . . 22		4.4. Invalidating Stored Responses . . . . . . . . . . . . . . 22
	5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 23		5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 23
	5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 24		5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 24
	5.2.1. Request Cache-Control Directives . . . . . . . . . . 24		5.2.1. Request Cache-Control Directives . . . . . . . . . . 24
			5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 24
			5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 25
			5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25
			5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25
			5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 26
			5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 26
			5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 26
	5.2.2. Response Cache-Control Directives . . . . . . . . . . 26		5.2.2. Response Cache-Control Directives . . . . . . . . . . 26
			5.2.2.1. max-age . . . . . . . . . . . . . . . . . . . . . 26
			5.2.2.2. must-revalidate . . . . . . . . . . . . . . . . . 27
			5.2.2.3. must-understand . . . . . . . . . . . . . . . . . 27
			5.2.2.4. no-cache . . . . . . . . . . . . . . . . . . . . 27
			5.2.2.5. no-store . . . . . . . . . . . . . . . . . . . . 28
			5.2.2.6. no-transform . . . . . . . . . . . . . . . . . . 29
			5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 29
			5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 30
			5.2.2.9. public . . . . . . . . . . . . . . . . . . . . . 30
			5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 30
	5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 31		5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 31
	5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 32		5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 32
	5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 32		5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 32
	5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 33		5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 33
	5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33		5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33
	6. Relationship to Applications and Other Caches . . . . . . . . 33		6. Relationship to Applications and Other Caches . . . . . . . . 33
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 34		7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 35		7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 35
	7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 35		7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 35
	7.3. Caching of Sensitive Information . . . . . . . . . . . . 35		7.3. Caching of Sensitive Information . . . . . . . . . . . . 35
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 27 ¶
	C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 42		C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 42
	C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 42		C.8. Since draft-ietf-httpbis-cache-06 . . . . . . . . . . . . 42
	C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 43		C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 43
	C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 43		C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 43
	C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 43		C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 43
	C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 43		C.12. Since draft-ietf-httpbis-cache-10 . . . . . . . . . . . . 43
	C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 44		C.13. Since draft-ietf-httpbis-cache-11 . . . . . . . . . . . . 44
	C.14. Since draft-ietf-httpbis-cache-12 . . . . . . . . . . . . 44		C.14. Since draft-ietf-httpbis-cache-12 . . . . . . . . . . . . 44
	C.15. Since draft-ietf-httpbis-cache-13 . . . . . . . . . . . . 45		C.15. Since draft-ietf-httpbis-cache-13 . . . . . . . . . . . . 45
	C.16. Since draft-ietf-httpbis-cache-14 . . . . . . . . . . . . 45		C.16. Since draft-ietf-httpbis-cache-14 . . . . . . . . . . . . 45
			C.17. Since draft-ietf-httpbis-cache-15 . . . . . . . . . . . . 46
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
	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. It is typically used for distributed		hypertext information systems. It is typically used for distributed
	information systems, where the use of response caches can improve		information systems, where the use of response caches can improve
	performance. This document defines aspects of HTTP related to		performance. This document defines aspects of HTTP related to
	caching and reusing response messages.		caching and reusing response messages.
	skipping to change at page 5, line 51 ¶		skipping to change at page 6, line 23 ¶
	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 non-		form ought to use an arithmetic type of at least 31 bits of non-
	negative integer range. If a cache receives a delta-seconds value		negative integer range. If a cache receives a delta-seconds value
	greater than the greatest integer it can represent, or if any of its		greater than the greatest integer it can represent, or if any of its
	subsequent calculations overflows, the cache MUST consider the value		subsequent calculations overflows, the cache MUST consider the value
	to be 2147483648 (2^(31)) or the greatest positive integer it can		to be 2147483648 (2^31) or the greatest positive integer it can
	conveniently represent.		conveniently represent.
	| *Note:* The value 2147483648 is here for historical reasons,		| *Note:* The value 2147483648 is here for historical reasons,
	| represents infinity (over 68 years), and does not need to be		| represents infinity (over 68 years), and does not need to be
	| stored in binary form; an implementation could produce it as a		| stored in binary form; an implementation could produce it as a
	| canned string if any overflow occurs, even if the calculations		| 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		| representing that number. What matters here is that an
	| overflow be detected and not treated as a negative value in		| overflow be detected and not treated as a negative value in
	| later calculations.		| later calculations.
	skipping to change at page 19, line 15 ¶		skipping to change at page 19, line 15 ¶
	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 using		initiating the request independently - it synthesises a request using
	a stored response by copying the method, target URI, and request		a stored response by copying the method, target URI, and request
	header fields identified by the Vary header field (Section 4.1).		header fields identified by the Vary header field (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 URI. Typically, this will include
			only those stored responses(s) that have the same cache key, although
			a cache is allowed to validate a response that it cannot select with
			the request header fields it is sending.
	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.
	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 8.8.2 of [Semantics]), which can be used in an If-		field (Section 8.8.2 of [Semantics]), which can be used in an If-
	Modified-Since header field for response validation, or in an If-		Modified-Since header field for response validation, or in an 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
	skipping to change at page 20, line 5 ¶		skipping to change at page 19, line 48 ¶
	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
	conditional requests to limit data transfers to recently modified		conditional requests to limit data transfers to recently modified
	representations or to complete the transfer of a partially retrieved		representations or to complete the transfer of a partially retrieved
	representation.		representation.
	If a cache receives a request that can be satisfied by reusing one of		If a cache receives a request that can be satisfied by reusing a
	its stored 200 (OK) or 206 (Partial Content) responses, the cache		stored 200 (OK) or 206 (Partial Content) response, as per Section 4,
	SHOULD evaluate any applicable conditional header field preconditions		the cache SHOULD evaluate any applicable conditional header field
	received in that request with respect to the corresponding validators		preconditions received in that request with respect to the
	contained within the selected response. A cache MUST NOT evaluate		corresponding validators contained within the selected response.
	conditional header fields that only apply to an origin server, occur
	in a request with semantics that cannot be satisfied with a cached		A cache MUST NOT evaluate conditional header fields that only apply
	response, or occur in a request with a target resource for which it		to an origin server, occur in a request with semantics that cannot be
	has no stored responses; such preconditions are likely intended for		satisfied with a cached response, or occur in a request with a target
	some other (inbound) server.		resource for which it has no stored responses; such preconditions are
			likely intended for 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. In		the received precondition header fields and their precedence. In
	summary, the If-Match and If-Unmodified-Since conditional header		summary, the If-Match and If-Unmodified-Since conditional header
	fields are not applicable to a cache, and If-None-Match takes		fields are not applicable to a cache, and If-None-Match takes
	precedence over If-Modified-Since. See Section 13.2.2 of [Semantics]		precedence over If-Modified-Since. See Section 13.2.2 of [Semantics]
	for a complete specification of precondition precedence.		for a complete specification of precondition precedence.
	A request containing an If-None-Match header field (Section 13.1.2 of		A request containing an If-None-Match header field (Section 13.1.2 of
	[Semantics]) indicates that the client wants to validate one or more		[Semantics]) indicates that the client wants to validate one or more
	of its own stored responses in comparison to whichever stored		of its own stored responses in comparison to the stored response
	response is selected by the cache.		selected by the cache (as per Section 4).
	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
	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
	two lists as a replacement If-None-Match header field value in the
	forwarded request. If a stored response contains only partial
	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
	that partial stored response. If the response to the forwarded
	request is 304 (Not Modified) and has an ETag field value with 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 corresponding
	stored response, as updated by the 304 response 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 13.1.3 of [Semantics])		an If-Modified-Since header field (Section 13.1.3 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.		stored responses by modification date.
	If a request contains an If-Modified-Since header field and the Last-		If a request contains an If-Modified-Since header field and the Last-
	Modified header field is not present in a selected stored response, a		Modified header field is not present in a selected stored response, a
	cache SHOULD use the stored response's Date field value (or, if no		cache SHOULD use the stored response's Date field value (or, if no
	Date field is present, the time that the stored response was		Date field is present, the time that the stored response was
	received) to evaluate the conditional.		received) to evaluate the conditional.
	A cache that implements partial responses to range requests, as		A cache that implements partial responses to range requests, as
	defined in Section 14.2 of [Semantics], also needs to evaluate a		defined in Section 14.2 of [Semantics], also needs to evaluate a
	received If-Range header field (Section 13.1.5 of [Semantics])		received If-Range header field (Section 13.1.5 of [Semantics])
	regarding its selected stored response.		regarding its selected stored response.
			When a cache decides to forward a request to revalidate its own
			stored responses for a 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 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 forwarded request. If a stored response contains
			only partial 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 that partial stored response. If the response to the
			forwarded request is 304 (Not Modified) and has an ETag field value
			with 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
			corresponding stored response, as updated by the 304 response
			metadata (Section 4.3.4).
	4.3.3. Handling a Validation Response		4.3.3. Handling a Validation Response
	Cache handling of a response to a conditional request depends upon		Cache handling of a response to a conditional request depends upon
	its status code:		its status code:
	* A 304 (Not Modified) response status code indicates that the		* 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.
	* A full response (i.e., one containing content) indicates that none		* A full response (i.e., one containing content) indicates that none
	of the stored responses nominated in the conditional request is		of the stored responses nominated in the conditional request is
	skipping to change at page 21, line 34 ¶		skipping to change at page 21, line 29 ¶
	* However, if a cache receives a 5xx (Server Error) response while		* However, if a cache receives a 5xx (Server Error) response while
	attempting to validate a response, it can either forward this		attempting to validate a response, it can either forward this
	response to the requesting client, or act as if the server failed		response to the requesting client, or act as if the server failed
	to respond. In the latter case, the cache can send a previously		to respond. In the latter case, the cache can send a previously
	stored response, subject to its constraints on doing so (see		stored response, subject to its constraints on doing so (see
	Section 4.2.4), or retry the validation request.		Section 4.2.4), or retry the validation request.
	4.3.4. Freshening Stored Responses upon Validation		4.3.4. Freshening Stored Responses upon Validation
	When a cache receives a 304 (Not Modified) response and already has		When a cache receives a 304 (Not Modified) response and already has
	one or more stored 200 (OK) responses for the applicable cache key,		one or more stored 200 (OK) responses for the applicable request URI,
	the cache needs to identify which (if any) are to be updated by the		the cache needs to identify which (if any) are to be updated by the
	new information provided, and then do so.		new information provided, and then do so.
	The stored response(s) to update are identified by using the first		The stored response(s) to update are identified by using the first
	match (if any) of:		match (if any) of:
	* If the new response contains one or more _strong validators_ (see		* If the new response contains one or more _strong validators_ (see
	Section 8.8.1 of [Semantics]), then each of those strong		Section 8.8.1 of [Semantics]), then each of those strong
	validators identify the selected representation for update. All		validators identify the selected representation for update. All
	the stored responses with one of those same strong validators are		the stored responses with one of those same strong validators are
	skipping to change at page 37, line 50 ¶		skipping to change at page 37, line 50 ¶
	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", Work in Progress, Internet-Draft, draft-		Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
	ietf-httpbis-messaging-15, 30 March 2021,		ietf-httpbis-messaging-16, 27 May 2021,
	<https://tools.ietf.org/html/draft-ietf-httpbis-messaging-		<https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
	15>.		16>.
	[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>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	skipping to change at page 38, line 26 ¶		skipping to change at page 38, line 26 ¶
	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", Work in Progress, Internet-Draft,		Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
	draft-ietf-httpbis-semantics-15, 30 March 2021,		draft-ietf-httpbis-semantics-16, 27 May 2021,
	<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-		<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
	15>.		16>.
	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,
	DOI 10.17487/RFC2616, June 1999,		DOI 10.17487/RFC2616, June 1999,
	<https://www.rfc-editor.org/info/rfc2616>.		<https://www.rfc-editor.org/info/rfc2616>.
	[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale		[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
	skipping to change at page 44, line 12 ¶		skipping to change at page 44, line 12 ¶
	* In Section 5.2 (Cache-Control), adjust ABNF to allow empty lists		* In Section 5.2 (Cache-Control), adjust ABNF to allow empty lists
	(<https://github.com/httpwg/http-core/issues/210>)		(<https://github.com/httpwg/http-core/issues/210>)
	C.13. Since draft-ietf-httpbis-cache-11		C.13. Since draft-ietf-httpbis-cache-11
	* None.		* None.
	C.14. Since draft-ietf-httpbis-cache-12		C.14. Since draft-ietf-httpbis-cache-12
	* In Section 4.2.4, remove 'no-store', as it won't be in cache in		* In Section 4.2.4, remove 'no-store', as it won't be in cache in
	the first place (<https://github.com/httpwg/http-core/issues/447>)		the first place (<https://github.com/httpwg/http-core/issues/447>,
			<https://www.rfc-editor.org/errata/eid6279>)
	* In Section 3.1, make it clear that only response headers need be		* In Section 3.1, make it clear that only response headers need be
	stored (<https://github.com/httpwg/http-core/issues/457>)		stored (<https://github.com/httpwg/http-core/issues/457>)
	* Rewrote "Updating Stored Header Fields" Section 3.2		* Rewrote "Updating Stored Header Fields" Section 3.2
	(<https://github.com/httpwg/http-core/issues/458>)		(<https://github.com/httpwg/http-core/issues/458>)
	* In Section 4.2.1 clarify how to handle invalid and conflicting		* In Section 4.2.1 clarify how to handle invalid and conflicting
	directives (<https://github.com/httpwg/http-core/issues/460>)		directives (<https://github.com/httpwg/http-core/issues/460>)
	skipping to change at page 46, line 11 ¶		skipping to change at page 46, line 14 ¶
	* In Section 7.1, cache poisoning can affect private caches too		* In Section 7.1, cache poisoning can affect private caches too
	(<https://github.com/httpwg/http-core/issues/730>)		(<https://github.com/httpwg/http-core/issues/730>)
	* In Section 5.1, adjust handling of invalid values to match most		* In Section 5.1, adjust handling of invalid values to match most
	deployed caches (<https://github.com/httpwg/http-core/issues/778>)		deployed caches (<https://github.com/httpwg/http-core/issues/778>)
	* In Section 5.3, mention parsing requirement relaxation		* In Section 5.3, mention parsing requirement relaxation
	(<https://github.com/httpwg/http-core/issues/779>)		(<https://github.com/httpwg/http-core/issues/779>)
			C.17. Since draft-ietf-httpbis-cache-15
			* In Section 4.3.1, tune description of relation between cache keys
			and validators (<https://github.com/httpwg/http-core/issues/832>)
	Acknowledgments		Acknowledgments
	See Appendix "Acknowledgments" of [Semantics].		See Appendix "Acknowledgments" of [Semantics].
			Index
			A C E F G H M N O P S V W
			A
			Age header field Section 5.1
			age Section 4.2
			C
			Cache-Control header field Section 5.2
			cache Section 1
			cache key Section 2; Section 2
			collapsed requests Section 4
			E
			Expires header field Section 5.3
			explicit expiration time Section 4.2
			F
			Fields
			Age Section 5.1; Section 5.1
			Cache-Control Section 5.2
			Expires Section 5.3; Section 5.3
			Pragma Section 5.4; Section 5.4
			Warning Section 5.5
			fresh Section 4.2
			freshness lifetime Section 4.2
			G
			Grammar
			Age Section 5.1
			Cache-Control Section 5.2
			DIGIT Section 1.2
			Expires Section 5.3
			cache-directive Section 5.2
			delta-seconds Section 1.3
			H
			Header Fields
			Age Section 5.1; Section 5.1
			Cache-Control Section 5.2
			Expires Section 5.3; Section 5.3
			Pragma Section 5.4; Section 5.4
			Warning Section 5.5
			heuristic expiration time Section 4.2
			heuristically cacheable Section 4.2.2
			M
			max-age (cache directive) Section 5.2.1.1; Section 5.2.2.1
			max-stale (cache directive) Section 5.2.1.2
			min-fresh (cache directive) Section 5.2.1.3
			must-revalidate (cache directive) Section 5.2.2.2
			must-understand (cache directive) Section 5.2.2.3
			N
			no-cache (cache directive) Section 5.2.1.4; Section 5.2.2.4
			no-store (cache directive) Section 5.2.1.5; Section 5.2.2.5
			no-transform (cache directive) Section 5.2.1.6;
			Section 5.2.2.6
			O
			only-if-cached (cache directive) Section 5.2.1.7
			P
			Pragma header field Section 5.4
			private (cache directive) Section 5.2.2.7
			private cache Section 1
			proxy-revalidate (cache directive) Section 5.2.2.8
			public (cache directive) Section 5.2.2.9
			S
			s-maxage (cache directive) Section 5.2.2.10
			selected response Section 4.1
			shared cache Section 1
			stale Section 4.2
			strong validator Section 4.3.4
			V
			validator Section 4.3.1
			W
			Warning header field Section 5.5
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe		Adobe
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	United States of America		United States of America
	Email: fielding@gbiv.com		Email: fielding@gbiv.com
	URI: https://roy.gbiv.com/		URI: https://roy.gbiv.com/
End of changes. 23 change blocks.
	42 lines changed or deleted		167 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/