draft-ietf-httpbis-cache-03.txt		draft-ietf-httpbis-cache-latest.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: April 21, 2019 J. Reschke, Ed.		Expires: August 19, 2019 J. Reschke, Ed.
	greenbytes		greenbytes
	October 18, 2018		February 15, 2019
	HTTP Caching		HTTP Caching
	draft-ietf-httpbis-cache-03		draft-ietf-httpbis-cache-latest
	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.4.		The changes in this draft are summarized in Appendix C.5.
	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 April 21, 2019.		This Internet-Draft will expire on August 19, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	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 Incomplete Responses . . . . . . . . . . . . . . 8		3.1. Storing Incomplete Responses . . . . . . . . . . . . . . 8
	3.2. Storing Responses to Authenticated Requests . . . . . . . 8		3.2. Storing Responses to Authenticated Requests . . . . . . . 9
	3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8		3.3. Combining Partial Content . . . . . . . . . . . . . . . . 9
	4. Constructing Responses from Caches . . . . . . . . . . . . . 9		4. Constructing Responses from Caches . . . . . . . . . . . . . 9
	4.1. Calculating Secondary Keys with Vary . . . . . . . . . . 10		4.1. Calculating Secondary Keys with Vary . . . . . . . . . . 10
	4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 12		4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . 13
	4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 13		4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 13
	4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 14		4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 14
	4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15		4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15
	4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 15		4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 16
	4.3.1. Sending a Validation Request . . . . . . . . . . . . 16		4.3.1. Sending a Validation Request . . . . . . . . . . . . 16
	4.3.2. Handling a Received Validation Request . . . . . . . 16		4.3.2. Handling a Received Validation Request . . . . . . . 17
	4.3.3. Handling a Validation Response . . . . . . . . . . . 18		4.3.3. Handling a Validation Response . . . . . . . . . . . 18
	4.3.4. Freshening Stored Responses upon Validation . . . . . 18		4.3.4. Freshening Stored Responses upon Validation . . . . . 18
	4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 19		4.3.5. Freshening Responses with HEAD . . . . . . . . . . . 19
	4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 20		4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . 20
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . 20		5. Header Field Definitions . . . . . . . . . . . . . . . . . . 20
	5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21		5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21		5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
	5.2.1. Request Cache-Control Directives . . . . . . . . . . 22		5.2.1. Request Cache-Control Directives . . . . . . . . . . 22
	5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 22		5.2.1.1. max-age . . . . . . . . . . . . . . . . . . . . . 22
	5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 22		5.2.1.2. max-stale . . . . . . . . . . . . . . . . . . . . 23
	5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 23		5.2.1.3. min-fresh . . . . . . . . . . . . . . . . . . . . 23
	5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 23		5.2.1.4. no-cache . . . . . . . . . . . . . . . . . . . . 23
	5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 23		5.2.1.5. no-store . . . . . . . . . . . . . . . . . . . . 24
	5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 24		5.2.1.6. no-transform . . . . . . . . . . . . . . . . . . 24
	5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 24		5.2.1.7. only-if-cached . . . . . . . . . . . . . . . . . 24
	5.2.2. Response Cache-Control Directives . . . . . . . . . . 24		5.2.2. Response Cache-Control Directives . . . . . . . . . . 24
	5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 24		5.2.2.1. must-revalidate . . . . . . . . . . . . . . . . . 24
	5.2.2.2. no-cache . . . . . . . . . . . . . . . . . . . . 24		5.2.2.2. no-cache . . . . . . . . . . . . . . . . . . . . 25
	5.2.2.3. no-store . . . . . . . . . . . . . . . . . . . . 25		5.2.2.3. no-store . . . . . . . . . . . . . . . . . . . . 26
	5.2.2.4. no-transform . . . . . . . . . . . . . . . . . . 26		5.2.2.4. no-transform . . . . . . . . . . . . . . . . . . 26
	5.2.2.5. public . . . . . . . . . . . . . . . . . . . . . 26		5.2.2.5. public . . . . . . . . . . . . . . . . . . . . . 26
	5.2.2.6. private . . . . . . . . . . . . . . . . . . . . . 26		5.2.2.6. private . . . . . . . . . . . . . . . . . . . . . 26
	5.2.2.7. proxy-revalidate . . . . . . . . . . . . . . . . 27		5.2.2.7. proxy-revalidate . . . . . . . . . . . . . . . . 27
	5.2.2.8. max-age . . . . . . . . . . . . . . . . . . . . . 27		5.2.2.8. max-age . . . . . . . . . . . . . . . . . . . . . 27
	5.2.2.9. s-maxage . . . . . . . . . . . . . . . . . . . . 27		5.2.2.9. s-maxage . . . . . . . . . . . . . . . . . . . . 27
	5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 27		5.2.3. Cache Control Extensions . . . . . . . . . . . . . . 28
	5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 28		5.2.4. Cache Directive Registry . . . . . . . . . . . . . . 29
	5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 29		5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 29
	5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 30		5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . 30
	5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30		5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 30
	6. Relationship to Applications . . . . . . . . . . . . . . . . 31		6. Relationship to Applications . . . . . . . . . . . . . . . . 30
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 31		7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	8.1. Header Field Registration . . . . . . . . . . . . . . . . 32		8.1. Header Field Registration . . . . . . . . . . . . . . . . 32
	8.2. Cache Directive Registration . . . . . . . . . . . . . . 32		8.2. Cache Directive Registration . . . . . . . . . . . . . . 32
	8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 32		8.3. Warn Code Registry . . . . . . . . . . . . . . . . . . . 32
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.1. Normative References . . . . . . . . . . . . . . . . . . 32		9.1. Normative References . . . . . . . . . . . . . . . . . . 32
	9.2. Informative References . . . . . . . . . . . . . . . . . 33		9.2. Informative References . . . . . . . . . . . . . . . . . 33
	Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 35		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 35
	Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 35		Appendix B. Changes from RFC 7234 . . . . . . . . . . . . . . . 35
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 36		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 35
	C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 36		C.1. Between RFC7234 and draft 00 . . . . . . . . . . . . . . 36
	C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 36		C.2. Since draft-ietf-httpbis-cache-00 . . . . . . . . . . . . 36
	C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 36		C.3. Since draft-ietf-httpbis-cache-01 . . . . . . . . . . . . 36
	C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 36		C.4. Since draft-ietf-httpbis-cache-02 . . . . . . . . . . . . 36
			C.5. Since draft-ietf-httpbis-cache-03 . . . . . . . . . . . . 37
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	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
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 22 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Conformance criteria and considerations regarding error handling are		Conformance criteria and considerations regarding error handling are
	defined in Section 3 of [Semantics].		defined in Section 3 of [Semantics].
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] with a list extension, defined in Section 11 of		notation of [RFC5234], extended with the notation for case-
	[Semantics], that allows for compact definition of comma-separated		sensitivity in strings defined in [RFC7405].
	lists using a '#' operator (similar to how the '*' operator indicates
	repetition). Appendix A shows the collected grammar with all list		It also uses a list extension, defined in Section 11 of [Semantics],
	operators expanded to standard ABNF notation.		that allows for compact definition of comma-separated lists using a
			'#' operator (similar to how the '*' operator indicates repetition).
			Appendix A shows the collected grammar with all list operators
			expanded to standard ABNF notation.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line		HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
	feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any		feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
	visible [USASCII] character).		visible [USASCII] character).
	The rules below are defined in [Semantics]:		The rules below are defined in [Semantics]:
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 15 ¶
	The primary cache key consists of the request method and target URI.		The primary cache key consists of the request method and target URI.
	However, since HTTP caches in common use today are typically limited		However, since HTTP caches in common use today are typically limited
	to caching responses to GET, many caches simply decline other methods		to caching responses to GET, many caches simply decline other methods
	and use only the URI as the primary cache key.		and use only the URI as the primary cache key.
	If a request target is subject to content negotiation, its cache		If a request target is subject to content negotiation, its cache
	entry might consist of multiple stored responses, each differentiated		entry might consist of multiple stored responses, each differentiated
	by a secondary key for the values of the original request's selecting		by a secondary key for the values of the original request's selecting
	header fields (Section 4.1).		header fields (Section 4.1).
			A cache is disconnected when it cannot contact the origin server or
			otherwise find a forward path for a given request. A disconnected
			cache can serve stale responses in some circumstances
			(Section 4.2.4).
	3. Storing Responses in Caches		3. Storing Responses in Caches
	A cache MUST NOT store a response to any request, unless:		A cache MUST NOT store a response to any request, unless:
	o The request method is understood by the cache and defined as being		o The request method is understood by the cache and defined as being
	cacheable, and		cacheable, and
	o the response status code is final (see Section 9.3 of		o the response status code is final (see Section 9.3 of
	[Messaging]), and		[Messaging]), and
	o the response status code is understood by the cache, and		o the response status code is understood by the cache, and
	o the "no-store" cache directive (see Section 5.2) does not appear		o the "no-store" cache directive (see Section 5.2) does not appear
	in request or response header fields, and		in the response, and
	o the "private" response directive (see Section 5.2.2.6) does not		o the "private" response directive (see Section 5.2.2.6) does not
	appear in the response, if the cache is shared, and		appear in the response, if the cache is shared, and
	o the Authorization header field (see Section 8.5.3 of [Semantics])		o the Authorization header field (see Section 8.5.3 of [Semantics])
	does not appear in the request, if the cache is shared, unless the		does not appear in the request, if the cache is shared, unless the
	response explicitly allows it (see Section 3.2), and		response explicitly allows it (see Section 3.2), and
	o the response either:		o the response either:
	skipping to change at page 8, line 38 ¶		skipping to change at page 9, line 9 ¶
	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.2. Storing Responses to Authenticated Requests
	A shared cache MUST NOT use a cached response to a request with an		A shared cache MUST NOT use a cached response to a request with an
	Authorization header field (Section 8.5.3 of [Semantics]) to satisfy		Authorization header field (Section 8.5.3 of [Semantics]) to satisfy
	any subsequent request unless a cache directive that allows such		any subsequent request unless a response directive that allows such
	responses to be stored is present in the response.		responses to be stored is present.
	In this specification, the following Cache-Control response		In this specification, the following Cache-Control response
	directives (Section 5.2.2) have such an effect: must-revalidate,		directives (Section 5.2.2) have such an effect: must-revalidate,
	public, and s-maxage.		public, and s-maxage.
	3.3. Combining Partial Content		3.3. Combining Partial Content
	A response might transfer only a partial representation if the		A response might transfer only a partial representation if the
	connection closed prematurely or if the request used one or more		connection closed prematurely or if the request used one or more
	Range specifiers (Section 8.3 of [Semantics]). After several such		Range specifiers (Section 8.3 of [Semantics]). After several such
	skipping to change at page 9, line 26 ¶		skipping to change at page 9, line 46 ¶
	o The presented effective request URI (Section 5.3 of [Semantics])		o The presented effective request URI (Section 5.3 of [Semantics])
	and that of the stored response match, and		and that of the stored response match, and
	o the request method associated with the stored response allows it		o the request method associated with the stored response allows it
	to be used for the presented request, and		to be used for the presented request, and
	o selecting header fields nominated by the stored response (if any)		o selecting header fields nominated by the stored response (if any)
	match those presented (see Section 4.1), and		match those presented (see Section 4.1), and
	o the presented request does not contain the no-cache pragma
	(Section 5.4), nor the no-cache cache directive (Section 5.2.1),
	unless the stored response is successfully validated
	(Section 4.3), and
	o the stored response does not contain the no-cache cache directive		o the stored response does not contain the no-cache cache directive
	(Section 5.2.2.2), unless it is successfully validated		(Section 5.2.2.2), unless it is successfully validated
	(Section 4.3), and		(Section 4.3), and
	o the stored response is either:		o the stored response is either:
	* fresh (see Section 4.2), or		* fresh (see Section 4.2), or
	* allowed to be served stale (see Section 4.2.4), or		* allowed to be served stale (see Section 4.2.4), or
	skipping to change at page 10, line 14 ¶		skipping to change at page 10, line 28 ¶
	A cache MUST write through requests with methods that are unsafe		A cache MUST write through requests with methods that are unsafe
	(Section 7.2.1 of [Semantics]) to the origin server; i.e., a cache is		(Section 7.2.1 of [Semantics]) to the origin server; i.e., a cache is
	not allowed to generate a reply to such a request before having		not allowed to generate a reply to such a request before having
	forwarded the request and having received a corresponding response.		forwarded the request and having received a corresponding response.
	Also, note that unsafe requests might invalidate already-stored		Also, note that unsafe requests might invalidate already-stored
	responses; see Section 4.4.		responses; see Section 4.4.
	When more than one suitable response is stored, a cache MUST use the		When more than one suitable response is stored, a cache MUST use the
	most recent response (as determined by the Date header field). It		most recent one (as determined by the Date header field). It can
	can also forward the request with "Cache-Control: max-age=0" or		also forward the request with "Cache-Control: max-age=0" or "Cache-
	"Cache-Control: no-cache" to disambiguate which response to use.		Control: no-cache" to disambiguate which response to use.
	A cache that does not have a clock available MUST NOT use stored		A cache that does not have a clock available MUST NOT use stored
	responses without revalidating them upon every use.		responses without revalidating them upon every use.
	4.1. Calculating Secondary Keys with Vary		4.1. Calculating Secondary Keys with Vary
	When a cache receives a request that can be satisfied by a stored		When a cache receives a request that can be satisfied by a stored
	response that has a Vary header field (Section 10.1.4 of		response that has a Vary header field (Section 10.1.4 of
	[Semantics]), it MUST NOT use that response unless all of the		[Semantics]), it MUST NOT use that response unless all of the
	selecting header fields nominated by the Vary header field match in		selecting header fields nominated by the Vary header field match in
	skipping to change at page 12, line 16 ¶		skipping to change at page 12, line 30 ¶
	caches are also allowed to use a heuristic to determine an expiration		caches are also allowed to use a heuristic to determine an expiration
	time under certain circumstances (see Section 4.2.2).		time under certain circumstances (see Section 4.2.2).
	The calculation to determine if a response is fresh is:		The calculation to determine if a response is fresh is:
	response_is_fresh = (freshness_lifetime > current_age)		response_is_fresh = (freshness_lifetime > current_age)
	freshness_lifetime is defined in Section 4.2.1; current_age is		freshness_lifetime is defined in Section 4.2.1; current_age is
	defined in Section 4.2.3.		defined in Section 4.2.3.
	Clients can send the max-age or min-fresh cache directives in a		Clients can send the max-age or min-fresh request directives
	request to constrain or relax freshness calculations for the		(Section 5.2.1) to constrain or relax freshness calculations for the
	corresponding response (Section 5.2.1).		corresponding response. However, caches are not required to honor
			them.
	When calculating freshness, to avoid common problems in date parsing:		When calculating freshness, to avoid common problems in date parsing:
	o Although all date formats are specified to be case-sensitive, a		o Although all date formats are specified to be case-sensitive, a
	cache recipient SHOULD match day, week, and time-zone names case-		cache recipient SHOULD match day, week, and time-zone names case-
	insensitively.		insensitively.
	o If a cache recipient's internal implementation of time has less		o If a cache recipient's internal implementation of time has less
	resolution than the value of an HTTP-date, the recipient MUST		resolution than the value of an HTTP-date, the recipient MUST
	internally represent a parsed Expires date as the nearest time		internally represent a parsed Expires date as the nearest time
	skipping to change at page 15, line 33 ¶		skipping to change at page 15, line 48 ¶
	A "stale" response is one that either has explicit expiry information		A "stale" response is one that either has explicit expiry information
	or is allowed to have heuristic expiry calculated, but is not fresh		or is allowed to have heuristic expiry calculated, but is not fresh
	according to the calculations in Section 4.2.		according to the calculations in Section 4.2.
	A cache MUST NOT generate a stale response if it is prohibited by an		A cache MUST NOT generate a stale response if it is prohibited by an
	explicit in-protocol directive (e.g., by a "no-store" or "no-cache"		explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
	cache directive, a "must-revalidate" cache-response-directive, or an		cache directive, a "must-revalidate" cache-response-directive, or an
	applicable "s-maxage" or "proxy-revalidate" cache-response-directive;		applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
	see Section 5.2.2).		see Section 5.2.2).
	A cache MUST NOT send stale responses unless it is disconnected		A cache MUST NOT send stale responses unless it is disconnected or
	(i.e., it cannot contact the origin server or otherwise find a		doing so is explicitly allowed (e.g., by the max-stale request
	forward path) or doing so is explicitly allowed (e.g., by the max-		directive; see Section 5.2.1).
	stale request directive; see Section 5.2.1).
	4.3. Validation		4.3. Validation
	When a cache has one or more stored responses for a requested URI,		When a cache has one or more stored responses for a requested URI,
	but cannot serve any of them (e.g., because they are not fresh, or		but cannot serve any of them (e.g., because they are not fresh, or
	one cannot be selected; see Section 4.1), it can use the conditional		one cannot be selected; see Section 4.1), it can use the conditional
	request mechanism Section 8.2 of [Semantics] in the forwarded request		request mechanism Section 8.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
	skipping to change at page 20, line 43 ¶		skipping to change at page 21, line 5 ¶
	Note that this does not guarantee that all appropriate responses are		Note that this does not guarantee that all appropriate responses are
	invalidated. For example, a state-changing request might invalidate		invalidated. For example, a state-changing request might invalidate
	responses in the caches it travels through, but relevant responses		responses in the caches it travels through, but relevant responses
	still might be stored in other caches that it has not.		still might be stored in other caches that it has not.
	5. Header Field Definitions		5. Header Field Definitions
	This section defines the syntax and semantics of HTTP header fields		This section defines the syntax and semantics of HTTP header fields
	related to caching.		related to caching.
	+-------------------+----------+-----------+--------------+		+-------------------+-----------+--------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Status | Reference |
	+-------------------+----------+-----------+--------------+		+-------------------+-----------+--------------+
	| Age | http | standard | Section 5.1 |		| Age | standard | Section 5.1 |
	| Cache-Control | http | standard | Section 5.2 |		| Cache-Control | standard | Section 5.2 |
	| Expires | http | standard | Section 5.3 |		| Expires | standard | Section 5.3 |
	| Pragma | http | standard | Section 5.4 |		| Pragma | standard | Section 5.4 |
	| Warning | http | obsoleted | Section 5.5 |		| Warning | obsoleted | Section 5.5 |
	+-------------------+----------+-----------+--------------+		+-------------------+-----------+--------------+
	5.1. Age		5.1. Age
	The "Age" header field conveys the sender's estimate of the amount of		The "Age" header field conveys the sender's estimate of the amount of
	time since the response was generated or successfully validated at		time since the response was generated or successfully validated at
	the origin server. Age values are calculated as specified in		the origin server. Age values are calculated as specified in
	Section 4.2.3.		Section 4.2.3.
	Age = delta-seconds		Age = delta-seconds
	skipping to change at page 21, line 31 ¶		skipping to change at page 21, line 41 ¶
	HTTP/1.0 cache that does not implement Age.		HTTP/1.0 cache that does not implement Age.
	5.2. Cache-Control		5.2. Cache-Control
	The "Cache-Control" header field is used to specify directives for		The "Cache-Control" header field is used to specify directives for
	caches along the request/response chain. Such cache directives are		caches along the request/response chain. Such cache directives are
	unidirectional in that the presence of a directive in a request does		unidirectional in that the presence of a directive in a request does
	not imply that the same directive is 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.
	A cache MUST obey the requirements of the Cache-Control directives		See Section 5.2.3 for information about how Cache-Control directives
	defined in this section. See Section 5.2.3 for information about how		defined elsewhere are handled.
	Cache-Control directives defined elsewhere are handled.
	Note: Some HTTP/1.0 caches might not implement Cache-Control.		Note: Some HTTP/1.0 caches might not implement Cache-Control.
	A proxy, whether or not it implements a cache, MUST pass cache		A proxy, whether or not it implements a cache, MUST pass cache
	directives through in forwarded messages, regardless of their		directives through in forwarded messages, regardless of their
	significance to that application, since the directives might be		significance to that application, since the directives might be
	applicable to all recipients along the request/response chain. It is		applicable to all recipients along the request/response chain. It is
	not possible to target a directive to a specific cache.		not possible to target a directive to a specific cache.
	Cache directives are identified by a token, to be compared case-		Cache directives are identified by a token, to be compared case-
	skipping to change at page 22, line 29 ¶		skipping to change at page 22, line 40 ¶
	| private | Section 5.2.2.6 |		| private | Section 5.2.2.6 |
	| proxy-revalidate | Section 5.2.2.7 |		| proxy-revalidate | Section 5.2.2.7 |
	| public | Section 5.2.2.5 |		| public | Section 5.2.2.5 |
	| s-maxage | Section 5.2.2.9 |		| s-maxage | Section 5.2.2.9 |
	| stale-if-error | [RFC5861], Section 4 |		| stale-if-error | [RFC5861], Section 4 |
	| stale-while-revalidate | [RFC5861], Section 3 |		| stale-while-revalidate | [RFC5861], Section 3 |
	+------------------------+-----------------------------------+		+------------------------+-----------------------------------+
	5.2.1. Request Cache-Control Directives		5.2.1. Request Cache-Control Directives
			This section defines cache request directives. They are advisory;
			caches MAY implement them, but are not required to.
	5.2.1.1. max-age		5.2.1.1. max-age
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.3)		delta-seconds (see Section 1.3)
	The "max-age" request directive indicates that the client is		The "max-age" request directive indicates that the client prefers a
	unwilling to accept a response whose age is greater than the		response whose age is less than or equal to the specified number of
	specified number of seconds. Unless the max-stale request directive		seconds. Unless the max-stale request directive is also present, the
	is also present, the client is not willing to accept a stale		client does not wish to receive a stale response.
	response.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the		'max-age=5' not 'max-age="5"'. A sender SHOULD NOT generate the
	quoted-string form.		quoted-string form.
	5.2.1.2. max-stale		5.2.1.2. max-stale
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.3)		delta-seconds (see Section 1.3)
	The "max-stale" request directive indicates that the client is		The "max-stale" request directive indicates that the client is
	willing to accept a response that has exceeded its freshness		willing to accept a response that has exceeded its freshness
	lifetime. If max-stale is assigned a value, then the client is		lifetime. If a value is present, then the client is willing to
	willing to accept a response that has exceeded its freshness lifetime		accept a response that has exceeded its freshness lifetime by no more
	by no more than the specified number of seconds. If no value is		than the specified number of seconds. If no value is assigned to
	assigned to max-stale, then the client is willing to accept a stale		max-stale, then the client is willing to accept a stale response of
	response of any age.		any age.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate		'max-stale=10' not 'max-stale="10"'. A sender SHOULD NOT generate
	the quoted-string form.		the quoted-string form.
	5.2.1.3. min-fresh		5.2.1.3. min-fresh
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.3)		delta-seconds (see Section 1.3)
	The "min-fresh" request directive indicates that the client is		The "min-fresh" request directive indicates that the client prefers a
	willing to accept a response whose freshness lifetime is no less than		response whose freshness lifetime is no less than its current age
	its current age plus the specified time in seconds. That is, the		plus the specified time in seconds. That is, the client wants a
	client wants a response that will still be fresh for at least the		response that will still be fresh for at least the specified number
	specified number of seconds.		of seconds.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate		'min-fresh=20' not 'min-fresh="20"'. A sender SHOULD NOT generate
	the quoted-string form.		the quoted-string form.
	5.2.1.4. no-cache		5.2.1.4. no-cache
	The "no-cache" request directive indicates that a cache MUST NOT use		The "no-cache" request directive indicates that the client prefers
	a stored response to satisfy the request without successful		stored response not be used to satisfy the request without successful
	validation on the origin server.		validation on the origin server.
	5.2.1.5. no-store		5.2.1.5. no-store
	The "no-store" request directive indicates that a cache MUST NOT		The "no-store" request directive indicates that a cache MUST NOT
	store any part of either this request or any response to it. This		store any part of either this request or any response to it. This
	directive applies to both private and shared caches. "MUST NOT		directive applies to both private and shared caches. "MUST NOT
	store" in this context means that the cache MUST NOT intentionally		store" in this context means that the cache MUST NOT intentionally
	store the information in non-volatile storage, and MUST make a best-		store the information in non-volatile storage, and MUST make a best-
	effort attempt to remove the information from volatile storage as		effort attempt to remove the information from volatile storage as
	skipping to change at page 24, line 11 ¶		skipping to change at page 24, line 26 ¶
	privacy. In particular, malicious or compromised caches might not		privacy. In particular, malicious or compromised caches might not
	recognize or obey this directive, and communications networks might		recognize or obey this directive, and communications networks might
	be vulnerable to eavesdropping.		be vulnerable to eavesdropping.
	Note that if a request containing this directive is satisfied from a		Note that if a request containing this directive is satisfied from a
	cache, the no-store request directive does not apply to the already		cache, the no-store request directive does not apply to the already
	stored response.		stored response.
	5.2.1.6. no-transform		5.2.1.6. no-transform
	The "no-transform" request directive indicates that an intermediary		The "no-transform" request directive indicates that the client is
	(whether or not it implements a cache) MUST NOT transform the		asking for intermediares (whether or not they implement a cache) to
	payload, as defined in Section 5.5.2 of [Semantics].		avoid transforming the payload, as defined in Section 5.5.2 of
			[Semantics].
	5.2.1.7. only-if-cached		5.2.1.7. only-if-cached
	The "only-if-cached" request directive indicates that the client only		The "only-if-cached" request directive indicates that the client only
	wishes to obtain a stored response. If it receives this directive, a		wishes to obtain a stored response. Caches that honor this request
	cache SHOULD either respond using a stored response that is		directive SHOULD, upon receiving it, either respond using a stored
	consistent with the other constraints of the request, or respond with		response that is consistent with the other constraints of the
	a 504 (Gateway Timeout) status code. If a group of caches is being		request, or respond with a 504 (Gateway Timeout) status code.
	operated as a unified system with good internal connectivity, a
	member cache MAY forward such a request within that group of caches.
	5.2.2. Response Cache-Control Directives		5.2.2. Response Cache-Control Directives
			This section defines cache response directives. A cache MUST obey
			the requirements of the Cache-Control directives defined in this
			section.
	5.2.2.1. must-revalidate		5.2.2.1. must-revalidate
	The "must-revalidate" response directive indicates that once it has		The "must-revalidate" response directive indicates that once it has
	become stale, the response MUST NOT be used to satisfy any other		become stale, the response MUST NOT be used to satisfy any other
	request without forwarding it for validation and receiving a		request without forwarding it for validation and receiving a
	successful response; see Section 4.3.		successful response; see Section 4.3.
	The must-revalidate directive is necessary to support reliable		The must-revalidate directive is necessary to support reliable
	operation for certain protocol features. In all circumstances a		operation for certain protocol features. In all circumstances a
	cache MUST obey the must-revalidate directive; in particular, if a		cache MUST obey the must-revalidate directive; in particular, if a
	cache cannot reach the origin server for any reason, it MUST generate		cache is disconnected, it MUST generate a 504 (Gateway Timeout)
	a 504 (Gateway Timeout) response.		response.
	The must-revalidate directive ought to be used by servers if and only		The must-revalidate directive ought to be used by servers if and only
	if failure to validate a request on the representation could result		if failure to validate a request on the representation could result
	in incorrect operation, such as a silently unexecuted financial		in incorrect operation, such as a silently unexecuted financial
	transaction.		transaction.
			The must-revalidate directive also has the effect of allowing a
			stored response to be used to satisfy a request with an Authorization
			header field; see Section 3.2.
	5.2.2.2. no-cache		5.2.2.2. no-cache
	Argument syntax:		Argument syntax:
	#field-name		#field-name
	The "no-cache" response directive indicates that the response MUST		The "no-cache" response directive indicates that the response MUST
	NOT be used to satisfy any other request without forwarding it for		NOT be used to satisfy any other request without forwarding it for
	validation and receiving a successful response; see Section 4.3.		validation and receiving a successful response; see Section 4.3.
	skipping to change at page 27, line 37 ¶		skipping to change at page 28, line 8 ¶
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.3)		delta-seconds (see Section 1.3)
	The "s-maxage" response directive indicates that, in shared caches,		The "s-maxage" response directive indicates that, in shared caches,
	the maximum age specified by this directive overrides the maximum age		the maximum age specified by this directive overrides the maximum age
	specified by either the max-age directive or the Expires header		specified by either the max-age directive or the Expires header
	field. The s-maxage directive also implies the semantics of the		field. The s-maxage directive also implies the semantics of the
	proxy-revalidate response directive.		proxy-revalidate response directive.
			The must-revalidate directive also has the effect of allowing a
			stored response to be used to satisfy a request with an Authorization
			header field; see Section 3.2.
	This directive uses the token form of the argument syntax: e.g.,		This directive uses the token form of the argument syntax: e.g.,
	's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the		's-maxage=10' not 's-maxage="10"'. A sender SHOULD NOT generate the
	quoted-string form.		quoted-string form.
	5.2.3. Cache Control Extensions		5.2.3. Cache Control Extensions
	The Cache-Control header field can be extended through the use of one		The Cache-Control header field can be extended through the use of one
	or more cache-extension tokens, each with an optional value. A cache		or more cache-extension tokens, each with an optional value. A cache
	MUST ignore unrecognized cache directives.		MUST ignore unrecognized cache directives.
	skipping to change at page 30, line 7 ¶		skipping to change at page 30, line 26 ¶
	Historically, HTTP required the Expires field-value to be no more		Historically, HTTP required the Expires field-value to be no more
	than a year in the future. While longer freshness lifetimes are no		than a year in the future. While longer freshness lifetimes are no
	longer prohibited, extremely large values have been demonstrated to		longer prohibited, extremely large values have been demonstrated to
	cause problems (e.g., clock overflows due to use of 32-bit integers		cause problems (e.g., clock overflows due to use of 32-bit integers
	for time values), and many caches will evict a response far sooner		for time values), and many caches will evict a response far sooner
	than that.		than that.
	5.4. Pragma		5.4. Pragma
	The "Pragma" header field allows backwards compatibility with		The "Pragma" header field was defined for HTTP/1.0 caches, so that
	HTTP/1.0 caches, so that clients can specify a "no-cache" request		clients could specify a "no-cache" request (as Cache-Control was not
	that they will understand (as Cache-Control was not defined until		defined until HTTP/1.1).
	HTTP/1.1). When the Cache-Control header field is also present and
	understood in a request, Pragma is ignored.
	In HTTP/1.0, Pragma was defined as an extensible field for
	implementation-specified directives for recipients. This
	specification deprecates such extensions to improve interoperability.
	Pragma = 1#pragma-directive
	pragma-directive = "no-cache" / extension-pragma
	extension-pragma = token [ "=" ( token / quoted-string ) ]
	When the Cache-Control header field is not present in a request,
	caches MUST consider the no-cache request pragma-directive as having
	the same effect as if "Cache-Control: no-cache" were present (see
	Section 5.2.1).
	When sending a no-cache request, a client ought to include both the
	pragma and cache-control directives, unless Cache-Control: no-cache
	is purposefully omitted to target other Cache-Control request
	directives at HTTP/1.1 or greater caches. For example:
	GET / HTTP/1.1
	Host: www.example.com
	Cache-Control: max-age=30
	Pragma: no-cache
	will constrain HTTP/1.1 and greater caches to serve a response no		However, support for Cache-Control is now widespread. As a result,
	older than 30 seconds, while precluding implementations that do not		this specification deprecates Pragma.
	understand Cache-Control from serving a cached response.
	Note: Because the meaning of "Pragma: no-cache" in responses is		Note: Because the meaning of "Pragma: no-cache" in responses was
	not specified, it does not provide a reliable replacement for		never specified, it does not provide a reliable replacement for
	"Cache-Control: no-cache" in them.		"Cache-Control: no-cache" in them.
	5.5. Warning		5.5. Warning
	The "Warning" header field 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 32, line 26 ¶		skipping to change at page 32, line 20 ¶
	Servers who wish to control caching of these responses are encouraged		Servers who wish to control caching of these responses are encouraged
	to emit appropriate Cache-Control response header fields.		to emit appropriate Cache-Control response header fields.
	8. IANA Considerations		8. IANA Considerations
	The change controller for the following registrations is: "IETF		The change controller for the following registrations is: "IETF
	(iesg@ietf.org) - Internet Engineering Task Force".		(iesg@ietf.org) - Internet Engineering Task Force".
	8.1. Header Field Registration		8.1. Header Field Registration
	Please update the "Message Headers" registry of "Permanent Message		Please update the "Hypertext Transfer Protocol (HTTP) Header Field
	Header Field Names" at <https://www.iana.org/assignments/message-		Registry" registry at <https://www.iana.org/assignments/http-headers>
	headers> with the header field names listed in the table of		with the header field names listed in the two tables of Section 5.
	Section 5.
	8.2. Cache Directive Registration		8.2. Cache Directive Registration
	Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive		Please update the "Hypertext Transfer Protocol (HTTP) Cache Directive
	Registry" at <https://www.iana.org/assignments/http-cache-directives>		Registry" at <https://www.iana.org/assignments/http-cache-directives>
	with the registration procedure of Section 5.2.4 and the cache		with the registration procedure of Section 5.2.4 and the cache
	directive names summarized in the table of Section 5.2.		directive names summarized in the table of Section 5.2.
	8.3. Warn Code Registry		8.3. Warn Code Registry
	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-03		Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-
	(work in progress), October 2018.		latest (work in progress), February 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		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>.
	[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>.
			[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
			RFC 7405, DOI 10.17487/RFC7405, December 2014,
			<https://www.rfc-editor.org/info/rfc7405>.
	[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-03		Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-latest
	(work in progress), October 2018.		(work in progress), February 2019.
	[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 35, line 21 ¶		skipping to change at page 35, line 21 ¶
	Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS		Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
	cache-directive ] )		cache-directive ] )
	Expires = HTTP-date		Expires = HTTP-date
	HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1>		HTTP-date = <HTTP-date, see [Semantics], Section 10.1.1.1>
	OWS = <OWS, see [Semantics], Section 4.3>		OWS = <OWS, see [Semantics], Section 4.3>
	Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
	pragma-directive ] )
	cache-directive = token [ "=" ( token / quoted-string ) ]		cache-directive = token [ "=" ( token / quoted-string ) ]
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	extension-pragma = token [ "=" ( token / quoted-string ) ]
	field-name = <field-name, see [Semantics], Section 4.2>		field-name = <field-name, see [Semantics], Section 4.2>
	port = <port, see [RFC3986], Section 3.2.3>		port = <port, see [RFC3986], Section 3.2.3>
	pragma-directive = "no-cache" / extension-pragma
	pseudonym = <pseudonym, see [Semantics], Section 5.5.1>		pseudonym = <pseudonym, see [Semantics], Section 5.5.1>
	quoted-string = <quoted-string, see [Semantics], Section 4.2.3>		quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
	token = <token, see [Semantics], Section 4.2.3>		token = <token, see [Semantics], Section 4.2.3>
	uri-host = <host, see [RFC3986], Section 3.2.2>		uri-host = <host, see [RFC3986], Section 3.2.2>
	Appendix B. Changes from RFC 7234		Appendix B. Changes from RFC 7234
	skipping to change at page 37, line 20 ¶		skipping to change at page 37, line 17 ¶
	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.2, 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
			o In Section 2, define what a disconnected cache is
			(<https://github.com/httpwg/http-core/issues/5>)
			o In Section 4, clarify language around how to select a response
			when more than one matches (<https://github.com/httpwg/http-core/
			issues/23>)
			o Remove requirements around cache request directives
			(<https://github.com/httpwg/http-core/issues/129>)
			o Deprecate Pragma (<https://github.com/httpwg/http-core/
			issues/140>)
			o In Section 3.2 and Section 5.2.2, note effect of some directives
			on authenticated requests (<https://github.com/httpwg/http-core/
			issues/161>)
	Index		Index
	A		A
	Age header field 21		Age header field 21
	age 11		age 11
	C		C
	Cache-Control header field 21		Cache-Control header field 21
	cache 4		cache 4
	cache entry 6		cache entry 6
	cache key 6		cache key 6-7
	E		E
	Expires header field 29		Expires header field 29
	explicit expiration time 11		explicit expiration time 11
	F		F
	fresh 11		fresh 11
	freshness lifetime 11		freshness lifetime 11
	G		G
	Grammar		Grammar
	Age 21		Age 21
	ALPHA 5		ALPHA 5
	Cache-Control 21		Cache-Control 22
	cache-directive 21		cache-directive 22
	CR 5		CR 5
	CRLF 5		CRLF 5
	CTL 5		CTL 5
	delta-seconds 5		delta-seconds 6
	DIGIT 5		DIGIT 5
	DQUOTE 5		DQUOTE 5
	Expires 29		Expires 29
	extension-pragma 30
	HEXDIG 5		HEXDIG 5
	HTAB 5		HTAB 5
	LF 5		LF 5
	OCTET 5		OCTET 5
	Pragma 30
	pragma-directive 30
	SP 5		SP 5
	VCHAR 5		VCHAR 5
	H		H
	heuristic expiration time 11		heuristic expiration time 11
	M		M
	max-age (cache directive) 22, 27		max-age (cache directive) 22, 27
	max-stale (cache directive) 22		max-stale (cache directive) 23
	min-fresh (cache directive) 23		min-fresh (cache directive) 23
	must-revalidate (cache directive) 24		must-revalidate (cache directive) 24
	N		N
	no-cache (cache directive) 23-24		no-cache (cache directive) 23, 25
	no-store (cache directive) 23, 25		no-store (cache directive) 24, 26
	no-transform (cache directive) 24, 26		no-transform (cache directive) 24, 26
	O		O
	only-if-cached (cache directive) 24		only-if-cached (cache directive) 24
	P		P
	Pragma header field 30		Pragma header field 30
	private (cache directive) 26		private (cache directive) 26
	private cache 4		private cache 4
	proxy-revalidate (cache directive) 27		proxy-revalidate (cache directive) 27
	public (cache directive) 26		public (cache directive) 26
	S		S
	s-maxage (cache directive) 27		s-maxage (cache directive) 27
	shared cache 4		shared cache 4
	stale 11		stale 11
	strong validator 18		strong validator 19
	V		V
	validator 16		validator 16
	W		W
	Warning header field 30		Warning header field 30
	Acknowledgments		Acknowledgments
	See Appendix "Acknowledgments" of [Semantics].		See Appendix "Acknowledgments" of [Semantics].
End of changes. 58 change blocks.
	141 lines changed or deleted		144 lines changed or added
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/