draft-ietf-httpbis-cache-09.txt		draft-ietf-httpbis-cache-10.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: January 12, 2021 J. Reschke, Ed.		Expires: January 13, 2021 J. F. Reschke, Ed.
	greenbytes		greenbytes
	July 11, 2020		July 12, 2020
	HTTP Caching		HTTP Caching
	draft-ietf-httpbis-cache-09		draft-ietf-httpbis-cache-10
	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.10.		The changes in this draft are summarized in Appendix C.11.
	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 January 12, 2021.		This Internet-Draft will expire on January 13, 2021.
	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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 2, line 46 ¶		skipping to change at page 2, line 48 ¶
	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 Header and Trailer Fields . . . . . . . . . . . . 8		3.1. Storing Header and Trailer Fields . . . . . . . . . . . . 8
	3.2. Storing Incomplete Responses . . . . . . . . . . . . . . 9		3.2. Storing Incomplete Responses . . . . . . . . . . . . . . 9
	3.3. Storing Responses to Authenticated Requests . . . . . . . 9		3.3. Storing Responses to Authenticated Requests . . . . . . . 10
	3.4. Combining Partial Content . . . . . . . . . . . . . . . . 10		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 . . . . . . . . . . . 14		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 . . . . . . . . . . . . . . . . . . . . . . . 17		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 . . . . . . . 18		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 . . . . . 20		4.3.4. Freshening Stored Responses upon Validation . . . . . 20
	4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 20		4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 21
	4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21		4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 21
	5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 22		5. Field Definitions . . . . . . . . . . . . . . . . . . . . . . 22
	5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23		5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 23
	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.1. max-age . . . . . . . . . . . . . . . . . . . . . 24
	5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 24		5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 24
	5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25		5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 25
	5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25		5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 25
	5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25		5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 25
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 39 ¶
	5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 27		5.2.2.3. no-cache . . . . . . . . . . . . . . . . . . . . 27
	5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 28		5.2.2.4. no-store . . . . . . . . . . . . . . . . . . . . 28
	5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 28		5.2.2.5. no-transform . . . . . . . . . . . . . . . . . . 28
	5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 28		5.2.2.6. public . . . . . . . . . . . . . . . . . . . . . 28
	5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28		5.2.2.7. private . . . . . . . . . . . . . . . . . . . . . 28
	5.2.2.8. proxy-revalidate . . . . . . . . . . . . . . . . 29		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 . . . . . . . . . . . . . . . . . . . . 30		5.2.2.10. s-maxage . . . . . . . . . . . . . . . . . . . . 30
	5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30		5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 30
	5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31		5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 31
	5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 31		5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 32
	5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 32		5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 33
	5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33		5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 33
	6. Relationship to Applications . . . . . . . . . . . . . . . . 33		6. Relationship to Applications . . . . . . . . . . . . . . . . 33
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 33		7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34		7.1. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 34
	7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34		7.2. Timing Attacks . . . . . . . . . . . . . . . . . . . . . 34
	7.3. Caching of Sensitive Information . . . . . . . . . . . . 34		7.3. Caching of Sensitive Information . . . . . . . . . . . . 35
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	8.1. Field Registration . . . . . . . . . . . . . . . . . . . 35		8.1. Field Registration . . . . . . . . . . . . . . . . . . . 35
	8.2. Cache Directive Registration . . . . . . . . . . . . . . 35		8.2. Cache Directive Registration . . . . . . . . . . . . . . 35
	8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 35		8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 35
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	9.1. Normative References . . . . . . . . . . . . . . . . . . 35		9.1. Normative References . . . . . . . . . . . . . . . . . . 35
	9.2. Informative References . . . . . . . . . . . . . . . . . 36		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 . . . . . . . . . . . . . . . 38
	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 . . . . . . . . . . . . 39
	C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 38		C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 39
	C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 38		C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 39
	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 . . . . . . . . . . . . 40
	C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 39		C.7. Since draft-ietf-httpbis-cache-05 . . . . . . . . . . . . 40
	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		C.9. Since draft-ietf-httpbis-cache-07 . . . . . . . . . . . . 41
	C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 41		C.10. Since draft-ietf-httpbis-cache-08 . . . . . . . . . . . . 41
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		C.11. Since draft-ietf-httpbis-cache-09 . . . . . . . . . . . . 41
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	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:
	o "HTTP Semantics" [Semantics]		o "HTTP Semantics" [Semantics]
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 35 ¶
	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 either 2147483648 (2^31) or the greatest positive integer it		to be either 2147483648 (2^31) or the greatest positive integer it
	can conveniently represent.		can conveniently represent.
	Note: The value 2147483648 is here for historical reasons,		| *Note:* The value 2147483648 is here for historical reasons,
	effectively represents infinity (over 68 years), and does not need		| effectively represents infinity (over 68 years), and does not
	to be stored in binary form; an implementation could produce it as		| need to be stored in binary form; an implementation could
	a canned string if any overflow occurs, even if the calculations		| produce it as a canned string if any overflow occurs, even if
	are performed with an arithmetic type incapable of directly		| the calculations are performed with an arithmetic type
	representing that number. What matters here is that an overflow		| incapable of directly representing that number. What matters
	be detected and not treated as a negative value in later		| here is that an overflow be detected and not treated as a
	calculations.		| negative value in later calculations.
	2. Overview of Cache Operation		2. Overview of Cache Operation
	Proper cache operation preserves the semantics of HTTP transfers		Proper cache operation preserves the semantics of HTTP transfers
	([Semantics]) while reducing the transfer of information already held		([Semantics]) while reducing the transfer of information already held
	in the cache. Although caching is an entirely OPTIONAL feature of		in the cache. Although caching is an entirely OPTIONAL feature of
	HTTP, it can be assumed that reusing a cached response is desirable		HTTP, it can be assumed that reusing a cached response is desirable
	and that such reuse is the default behavior when no requirement or		and that such reuse is the default behavior when no requirement or
	local configuration prevents it. Therefore, HTTP cache requirements		local configuration prevents it. Therefore, HTTP cache requirements
	are focused on preventing a cache from either storing a non-reusable		are focused on preventing a cache from either storing a non-reusable
	skipping to change at page 8, line 39 ¶		skipping to change at page 8, line 48 ¶
	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 Header and Trailer Fields		3.1. Storing Header and Trailer Fields
	Caches MUST include all received header fields -- including		Caches MUST include all received header fields - including
	unrecognised ones -- when storing a response; this assures that new		unrecognised ones - when storing a response; this assures that new
	HTTP header fields can be successfully deployed. However, the		HTTP header fields can be successfully deployed. However, the
	following exceptions are made:		following exceptions are made:
	o The Connection header field and fields whose names are listed in		o The Connection header field and fields whose names are listed in
	it are required by Section 9.1 of [Messaging] to be removed before		it are required by Section 9.1 of [Messaging] to be removed before
	forwarding the message. This MAY be implemented by doing so		forwarding the message. This MAY be implemented by doing so
	before storage.		before storage.
	o Likewise, some fields' semantics require them to be removed before		o Likewise, some fields' semantics require them to be removed before
	forwarding the message, and this MAY be implemented by doing so		forwarding the message, and this MAY be implemented by doing so
	skipping to change at page 15, line 15 ¶		skipping to change at page 15, line 18 ¶
	(e.g., with a "public" response directive).		(e.g., with a "public" response directive).
	Note that in previous specifications heuristically cacheable response		Note that in previous specifications heuristically cacheable response
	status codes were called "cacheable by default."		status codes were called "cacheable by default."
	If the response has a Last-Modified header field (Section 11.2.2 of		If the response has a Last-Modified header field (Section 11.2.2 of
	[Semantics]), caches are encouraged to use a heuristic expiration		[Semantics]), caches are encouraged to use a heuristic expiration
	value that is no more than some fraction of the interval since that		value that is no more than some fraction of the interval since that
	time. A typical setting of this fraction might be 10%.		time. A typical setting of this fraction might be 10%.
	Note: Section 13.9 of [RFC2616] prohibited caches from calculating		| *Note:* Section 13.9 of [RFC2616] prohibited caches from
	heuristic freshness for URIs with query components (i.e., those		| calculating heuristic freshness for URIs with query components
	containing '?'). In practice, this has not been widely		| (i.e., those containing '?'). In practice, this has not been
	implemented. Therefore, origin servers are encouraged to send		| widely implemented. Therefore, origin servers are encouraged
	explicit directives (e.g., Cache-Control: no-cache) if they wish		| to send explicit directives (e.g., Cache-Control: no-cache) if
	to preclude caching.		| they wish to preclude caching.
	4.2.3. Calculating Age		4.2.3. Calculating Age
	The Age header field is used to convey an estimated age of the		The Age header field is used to convey an estimated age of the
	response message when obtained from a cache. The Age field value is		response message when obtained from a cache. The Age field value is
	the cache's estimate of the number of seconds since the response was		the cache's estimate of the number of seconds since the response was
	generated or validated by the origin server. In essence, the Age		generated or validated by the origin server. In essence, the Age
	value is the sum of the time that the response has been resident in		value is the sum of the time that the response has been resident in
	each of the caches along the path from the origin server, plus the		each of the caches along the path from the origin server, plus the
	amount of time it has been in transit along network paths.		amount of time it has been in transit along network paths.
	skipping to change at page 17, line 26 ¶		skipping to change at page 17, line 32 ¶
	request mechanism Section 9.2 of [Semantics] in the forwarded request		request mechanism Section 9.2 of [Semantics] in the forwarded request
	to give the next inbound server an opportunity to select a valid		to give the next inbound server an opportunity to select a valid
	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
	using a stored response by copying the method, target URI, and		a stored response by copying the method, target URI, and request
	request header fields identified by the Vary header field		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.
	One such validator is the timestamp given in a Last-Modified header		One such validator is the timestamp given in a Last-Modified header
	skipping to change at page 22, line 19 ¶		skipping to change at page 22, line 27 ¶
	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.		(Redirection) status code.
	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 |		| Cache-Control | standard | Section 5.2 |
	| Cache-Control | standard | Section 5.2 |		| Expires | standard | Section 5.3 |
	| Expires | standard | Section 5.3 |		| Pragma | standard | Section 5.4 |
	| Pragma | standard | Section 5.4 |		| Warning | obsoleted | Section 5.5 |
	| Warning | obsoleted | Section 5.5 |		+---------------+-----------+-------------+
	+---------------+-----------+--------------+
	Table 1		Table 1
	5.1. Age		5.1. Age
	The "Age" header field conveys the sender's estimate of the amount of		The "Age" header field conveys the sender's estimate of the amount of
	time since the response was generated or successfully validated at		time since the response was generated or successfully validated at
	the origin server. Age values are calculated as specified in		the origin server. Age values are calculated as specified in
	Section 4.2.3.		Section 4.2.3.
	Age = delta-seconds		Age = delta-seconds
	skipping to change at page 23, line 16 ¶		skipping to change at page 23, line 22 ¶
	The "Cache-Control" header field is used to list directives for		The "Cache-Control" header field is used to list directives for
	caches along the request/response chain. Such cache directives are		caches along the request/response chain. Such cache directives are
	unidirectional in that the presence of a directive in a request does		unidirectional in that the presence of a directive in a request does
	not imply that the same directive is present in the response, or to		not imply that the same directive is present in the response, or to
	be repeated in it.		be repeated in it.
	See Section 5.2.3 for information about how Cache-Control directives		See Section 5.2.3 for information about how Cache-Control directives
	defined elsewhere are handled.		defined elsewhere are handled.
	Note: Some HTTP/1.0 caches might not implement Cache-Control.		| *Note:* Some HTTP/1.0 caches might not implement Cache-Control.
	A proxy, whether or not it implements a cache, MUST pass cache		A proxy, whether or not it implements a cache, MUST pass cache
	directives through in forwarded messages, regardless of their		directives through in forwarded messages, regardless of their
	significance to that application, since the directives might be		significance to that application, since the directives might be
	applicable to all recipients along the request/response chain. It is		applicable to all recipients along the request/response chain. It is
	not possible to target a directive to a specific cache.		not possible to target a directive to a specific cache.
	Cache directives are identified by a token, to be compared case-		Cache directives are identified by a token, to be compared case-
	insensitively, and have an optional argument, that can use both token		insensitively, and have an optional argument, that can use both token
	and quoted-string syntax. For the directives defined below that		and quoted-string syntax. For the directives defined below that
	define arguments, recipients ought to accept both forms, even if a		define arguments, recipients ought to accept both forms, even if a
	specific form is required for generation.		specific form is required for generation.
	Cache-Control = 1#cache-directive		Cache-Control = 1#cache-directive
	cache-directive = token [ "=" ( token / quoted-string ) ]		cache-directive = token [ "=" ( token / quoted-string ) ]
	For the cache directives defined below, no argument is defined (nor		For the cache directives defined below, no argument is defined (nor
	allowed) unless stated otherwise.		allowed) unless stated otherwise.
	+------------------+-----------------------------------+		+------------------+----------------------------------+
	| Cache Directive | Reference |		| Cache Directive | Reference |
	+------------------+-----------------------------------+		| max-age | Section 5.2.1.1, Section 5.2.2.9 |
	| max-age | Section 5.2.1.1, Section 5.2.2.9 |		| max-stale | Section 5.2.1.2 |
	| max-stale | Section 5.2.1.2 |		| min-fresh | Section 5.2.1.3 |
	| min-fresh | Section 5.2.1.3 |		| must-revalidate | Section 5.2.2.1 |
	| must-revalidate | Section 5.2.2.1 |		| must-understand | Section 5.2.2.2 |
	| must-understand | Section 5.2.2.2 |		| no-cache | Section 5.2.1.4, Section 5.2.2.3 |
	| no-cache | Section 5.2.1.4, Section 5.2.2.3 |		| no-store | Section 5.2.1.5, Section 5.2.2.4 |
	| no-store | Section 5.2.1.5, Section 5.2.2.4 |		| no-transform | Section 5.2.1.6, Section 5.2.2.5 |
	| no-transform | Section 5.2.1.6, Section 5.2.2.5 |		| only-if-cached | Section 5.2.1.7 |
	| only-if-cached | Section 5.2.1.7 |		| private | Section 5.2.2.7 |
	| private | Section 5.2.2.7 |		| proxy-revalidate | Section 5.2.2.8 |
	| proxy-revalidate | Section 5.2.2.8 |		| public | Section 5.2.2.6 |
	| public | Section 5.2.2.6 |		| s-maxage | Section 5.2.2.10 |
	| s-maxage | Section 5.2.2.10 |		+------------------+----------------------------------+
	+------------------+-----------------------------------+
	Table 2		Table 2
	5.2.1. Request Cache-Control Directives		5.2.1. Request Cache-Control Directives
	This section defines cache request directives. They are advisory;		This section defines cache request directives. They are advisory;
	caches MAY implement them, but are not required to.		caches MAY implement them, but are not required to.
	5.2.1.1. max-age		5.2.1.1. max-age
	Argument syntax:		Argument syntax:
	skipping to change at page 27, line 45 ¶		skipping to change at page 27, line 45 ¶
	certain header fields in a response, while still allowing caching of		certain header fields in a response, while still allowing caching of
	the rest of the response.		the rest of the response.
	The field names given are not limited to the set of header fields		The field names given are not limited to the set of header fields
	defined by this specification. Field names are case-insensitive.		defined by this specification. Field names are case-insensitive.
	This directive uses the quoted-string form of the argument syntax. A		This directive uses the quoted-string form of the argument syntax. A
	sender SHOULD NOT generate the token form (even if quoting appears		sender SHOULD NOT generate the token form (even if quoting appears
	not to be needed for single-entry lists).		not to be needed for single-entry lists).
	Note: Although it has been back-ported to many implementations, some		*Note:* Although it has been back-ported to many implementations,
	HTTP/1.0 caches will not recognize or obey this directive. Also, the		some HTTP/1.0 caches will not recognize or obey this directive.
	qualified form of the directive is often handled by caches as if an		Also, the qualified form of the directive is often handled by caches
	unqualified no-cache directive was received; i.e., the special		as if an unqualified no-cache directive was received; i.e., the
	handling for the qualified form is not widely implemented.		special handling for the qualified form is not widely implemented.
	5.2.2.4. no-store		5.2.2.4. no-store
	The "no-store" response directive indicates that a cache MUST NOT		The "no-store" response directive indicates that a cache MUST NOT
	store any part of either the immediate request or response, and MUST		store any part of either the immediate request or response, and MUST
	NOT use the response to satisfy any other request.		NOT use the response to satisfy any other request.
	This directive applies to both private and shared caches. "MUST NOT		This directive applies to both private and shared caches. "MUST NOT
	store" in this context means that the cache MUST NOT intentionally		store" in this context means that the cache MUST NOT intentionally
	store the information in non-volatile storage, and MUST make a best-		store the information in non-volatile storage, and MUST make a best-
	skipping to change at page 29, line 21 ¶		skipping to change at page 29, line 26 ¶
	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.		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
	content. Also, the qualified form of the directive is often handled		content. Also, the qualified form of the directive is often handled
	by caches as if an unqualified private directive was received; i.e.,		by caches as if an unqualified private directive was received; i.e.,
	the special handling for the qualified form is not widely		the special handling for the qualified form is not widely
	implemented.		implemented.
	5.2.2.8. proxy-revalidate		5.2.2.8. proxy-revalidate
	The "proxy-revalidate" response directive indicates that once the		The "proxy-revalidate" response directive indicates that once the
	response has become stale, a shared cache MUST NOT reuse that		response has become stale, a shared cache MUST NOT reuse that
	skipping to change at page 32, line 50 ¶		skipping to change at page 33, line 14 ¶
	5.4. Pragma		5.4. Pragma
	The "Pragma" header field was defined for HTTP/1.0 caches, so that		The "Pragma" header field was defined for HTTP/1.0 caches, so that
	clients could specify a "no-cache" request (as Cache-Control was not		clients could specify a "no-cache" request (as Cache-Control was not
	defined until HTTP/1.1).		defined until HTTP/1.1).
	However, support for Cache-Control is now widespread. As a result,		However, support for Cache-Control is now widespread. As a result,
	this specification deprecates Pragma.		this specification deprecates Pragma.
	Note: Because the meaning of "Pragma: no-cache" in responses was		| *Note:* Because the meaning of "Pragma: no-cache" in responses
	never specified, it does not provide a reliable replacement for		| was never specified, it does not provide a reliable replacement
	"Cache-Control: no-cache" in them.		| for "Cache-Control: no-cache" in them.
	5.5. Warning		5.5. Warning
	The "Warning" header field was used to carry additional information		The "Warning" header field was used to carry additional information
	about the status or transformation of a message that might not be		about the status or transformation of a message that might not be
	reflected in the status code. This specification obsoletes it, as it		reflected in the status code. This specification obsoletes it, as it
	is not widely generated or surfaced to users. The information it		is not widely generated or surfaced to users. The information it
	carried can be gleaned from examining other header fields, such as		carried can be gleaned from examining other header fields, such as
	Age.		Age.
	skipping to change at page 35, line 29 ¶		skipping to change at page 35, line 47 ¶
	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. F. Reschke,
	Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-09		Ed., "HTTP/1.1 Messaging", Work in Progress, Internet-
	(work in progress), July 2020.		Draft, draft-ietf-httpbis-messaging-10, July 12, 2020,
			<https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
			10>.
	[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 36, line 10 ¶		skipping to change at page 36, line 29 ¶
	[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. F. Reschke,
	Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-09		Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
	(work in progress), July 2020.		draft-ietf-httpbis-semantics-10, July 12, 2020,
			<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
			10>.
	[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 36, line 39 ¶		skipping to change at page 37, line 14 ¶
	[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,		[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
	"Network Time Protocol Version 4: Protocol and Algorithms		"Network Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,		Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
	<https://www.rfc-editor.org/info/rfc5905>.		<https://www.rfc-editor.org/info/rfc5905>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP): Caching",		Ed., "Hypertext Transfer Protocol (HTTP): Caching",
	RFC 7234, DOI 10.17487/RFC7234, June 2014,		RFC 7234, DOI 10.17487/RFC7234, June 2014,
	<https://www.rfc-editor.org/info/rfc7234>.		<https://www.rfc-editor.org/info/rfc7234>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	Appendix A. Collected ABNF		Appendix A. Collected ABNF
	skipping to change at page 37, line 49 ¶		skipping to change at page 38, line 24 ¶
	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. In practice, Warning was 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 41, line 17 ¶		skipping to change at page 41, line 40 ¶
	(<https://github.com/httpwg/http-core/issues/320>)		(<https://github.com/httpwg/http-core/issues/320>)
	o In Section 3.2, move definition of "complete" into semantics		o In Section 3.2, move definition of "complete" into semantics
	(<https://github.com/httpwg/http-core/issues/334>)		(<https://github.com/httpwg/http-core/issues/334>)
	C.10. Since draft-ietf-httpbis-cache-08		C.10. Since draft-ietf-httpbis-cache-08
	o Appendix A now uses the sender variant of the "#" list expansion		o Appendix A now uses the sender variant of the "#" list expansion
	(<https://github.com/httpwg/http-core/issues/192>)		(<https://github.com/httpwg/http-core/issues/192>)
	Index		C.11. Since draft-ietf-httpbis-cache-09
	A
	Age header field 22
	age 12
	C
	Cache-Control header field 23
	cache 4
	cache key 6
	E
	Expires header field 31
	explicit expiration time 12
	F
	Fields
	Age 22
	Cache-Control 23
	Expires 31
	Pragma 32
	Warning 33
	fresh 12
	freshness lifetime 12
	G
	Grammar
	Age 22
	ALPHA 5
	Cache-Control 23
	cache-directive 23
	CR 5
	CRLF 5
	CTL 5
	delta-seconds 6
	DIGIT 5
	DQUOTE 5
	Expires 32
	HEXDIG 5
	HTAB 5
	LF 5
	OCTET 5
	SP 5
	VCHAR 5
	H
	Header Fields
	Age 22
	Cache-Control 23
	Expires 31
	Pragma 32
	Warning 33
	heuristic expiration time 12
	heuristically cacheable 14
	M
	max-age (cache directive) 24, 29
	max-stale (cache directive) 24
	min-fresh (cache directive) 25
	must-revalidate (cache directive) 26
	must-understand (cache directive) 27
	N
	no-cache (cache directive) 25, 27
	no-store (cache directive) 25, 28
	no-transform (cache directive) 26, 28
	O
	only-if-cached (cache directive) 26
	P
	Pragma header field 32
	private (cache directive) 28
	private cache 4
	proxy-revalidate (cache directive) 29
	public (cache directive) 28
	S
	s-maxage (cache directive) 30
	shared cache 4
	stale 12
	strong validator 20
	V
	validator 17
	W		o Switch to xml2rfc v3 mode for draft generation
	Warning header field 33		(<https://github.com/httpwg/http-core/issues/394>)
	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
	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/
	Mark Nottingham (editor)		Mark Nottingham (editor)
	Fastly		Fastly
	EMail: mnot@mnot.net		Email: mnot@mnot.net
	URI: https://www.mnot.net/		URI: https://www.mnot.net/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster 48155		48155 Münster
	Germany		Germany
	EMail: julian.reschke@greenbytes.de		Email: julian.reschke@greenbytes.de
	URI: https://greenbytes.de/tech/webdav/		URI: https://greenbytes.de/tech/webdav/
End of changes. 40 change blocks.
	190 lines changed or deleted		105 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/