draft-ietf-httpbis-p6-cache-24.txt		draft-ietf-httpbis-p6-cache-25.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) M. Nottingham, Ed.		Obsoletes: 2616 (if approved) M. Nottingham, Ed.
	Intended status: Standards Track Akamai		Intended status: Standards Track Akamai
	Expires: March 29, 2014 J. Reschke, Ed.		Expires: May 21, 2014 J. Reschke, Ed.
	greenbytes		greenbytes
	September 25, 2013		November 17, 2013
	Hypertext Transfer Protocol (HTTP/1.1): Caching		Hypertext Transfer Protocol (HTTP/1.1): Caching
	draft-ietf-httpbis-p6-cache-24		draft-ietf-httpbis-p6-cache-25
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. This document defines requirements on HTTP caches and the		systems. This document defines requirements on HTTP caches and the
	associated header fields that control cache behavior or indicate		associated header fields that control cache behavior or indicate
	cacheable response messages.		cacheable response messages.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.5.		The changes in this draft are summarized in Appendix D.1.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 March 29, 2014.		This Internet-Draft will expire on May 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 43		skipping to change at page 2, line 43
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 5		1.2.1. Delta Seconds . . . . . . . . . . . . . . . . . . . . 5
	2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 5		2. Overview of Cache Operation . . . . . . . . . . . . . . . . . 5
	3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 6		3. Storing Responses in Caches . . . . . . . . . . . . . . . . . 6
	3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 7		3.1. Storing Incomplete Responses . . . . . . . . . . . . . . . 7
	3.2. Storing Responses to Authenticated Requests . . . . . . . 7		3.2. Storing Responses to Authenticated Requests . . . . . . . 7
	3.3. Combining Partial Content . . . . . . . . . . . . . . . . 7		3.3. Combining Partial Content . . . . . . . . . . . . . . . . 8
	4. Constructing Responses from Caches . . . . . . . . . . . . . . 8		4. Constructing Responses from Caches . . . . . . . . . . . . . . 8
	4.1. Calculating Secondary Keys with Vary . . . . . . . . . . . 9		4.1. Calculating Secondary Keys with Vary . . . . . . . . . . . 9
	4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 10		4.2. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12		4.2.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12
	4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 12		4.2.2. Calculating Heuristic Freshness . . . . . . . . . . . 12
	4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13		4.2.3. Calculating Age . . . . . . . . . . . . . . . . . . . 13
	4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 14		4.2.4. Serving Stale Responses . . . . . . . . . . . . . . . 15
	4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15		4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15		4.3.1. Sending a Validation Request . . . . . . . . . . . . . 15
	4.3.2. Handling a Received Validation Request . . . . . . . . 16		4.3.2. Handling a Received Validation Request . . . . . . . . 16
	4.3.3. Handling a Validation Response . . . . . . . . . . . . 17		4.3.3. Handling a Validation Response . . . . . . . . . . . . 17
	4.3.4. Freshening Stored Responses upon Validation . . . . . 18		4.3.4. Freshening Stored Responses upon Validation . . . . . 18
	4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 18		4.3.5. Freshening Responses via HEAD . . . . . . . . . . . . 19
	4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19		4.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
	5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		5.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20		5.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
	5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21		5.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
	5.2.2. Response Cache-Control Directives . . . . . . . . . . 23		5.2.2. Response Cache-Control Directives . . . . . . . . . . 23
	5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26		5.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
	5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27		5.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
	5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28		5.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29		5.5. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
	5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 30		5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 31
	5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31		5.5.2. Warning: 111 - "Revalidation Failed" . . . . . . . . . 31
	5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31		5.5.3. Warning: 112 - "Disconnected Operation" . . . . . . . 31
	5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31		5.5.4. Warning: 113 - "Heuristic Expiration" . . . . . . . . 31
	5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31		5.5.5. Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31
	5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31		5.5.6. Warning: 214 - "Transformation Applied" . . . . . . . 31
	5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31		5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" . . 31
	6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31		6. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32		7.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32
	7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32		7.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 32
	7.1.2. Considerations for New Cache Control Directives . . . 32		7.1.2. Considerations for New Cache Control Directives . . . 32
	7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 32		7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 33
	7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33		7.2. Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33
	7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33		7.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 33
	7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33		7.2.2. Registrations . . . . . . . . . . . . . . . . . . . . 33
	7.3. Header Field Registration . . . . . . . . . . . . . . . . 34		7.3. Header Field Registration . . . . . . . . . . . . . . . . 34
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 34		8. Security Considerations . . . . . . . . . . . . . . . . . . . 34
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 35		10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
	10.2. Informative References . . . . . . . . . . . . . . . . . . 36		10.2. Informative References . . . . . . . . . . . . . . . . . . 36
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 38
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 38
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 39		publication) . . . . . . . . . . . . . . . . . . . . 39
	D.1. Since draft-ietf-httpbis-p6-cache-19 . . . . . . . . . . . 40		D.1. Since draft-ietf-httpbis-p6-cache-24 . . . . . . . . . . . 40
	D.2. Since draft-ietf-httpbis-p6-cache-20 . . . . . . . . . . . 40		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	D.3. Since draft-ietf-httpbis-p6-cache-21 . . . . . . . . . . . 41
	D.4. Since draft-ietf-httpbis-p6-cache-22 . . . . . . . . . . . 41
	D.5. Since draft-ietf-httpbis-p6-cache-23 . . . . . . . . . . . 41
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	1. Introduction		1. Introduction
	HTTP is typically used for distributed information systems, where		HTTP is typically used for distributed information systems, where
	performance can be improved by the use of response caches. This		performance can be improved by the use of response caches. This
	document defines aspects of HTTP/1.1 related to caching and reusing		document defines aspects of HTTP/1.1 related to caching and reusing
	response messages.		response messages.
	An HTTP cache is a local store of response messages and the subsystem		An HTTP cache is a local store of response messages and the subsystem
	that controls storage, retrieval, and deletion of messages in it. A		that controls storage, retrieval, and deletion of messages in it. A
	skipping to change at page 5, line 12		skipping to change at page 5, line 12
	documents. Appendix C shows the collected ABNF with the list rule		documents. Appendix C shows the collected ABNF with the list rule
	expanded.		expanded.
	1.2.1. Delta Seconds		1.2.1. Delta Seconds
	The delta-seconds rule specifies a non-negative integer, representing		The delta-seconds rule specifies a non-negative integer, representing
	time in seconds.		time in seconds.
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	If a cache receives a delta-seconds value larger than the largest		A recipient parsing a delta-seconds value and converting it to binary
	positive integer it can represent, or if any of its subsequent		form ought to use an arithmetic type of at least 31 bits of non-
	calculations overflows, the cache MUST consider the value to be		negative integer range. If a cache receives a delta-seconds value
	2147483648 (2^31). A recipient parsing a delta-seconds value MUST		greater than the greatest integer it can represent, or if any of its
	use an arithmetic type of at least 31 bits of range, and a sender		subsequent calculations overflows, the cache MUST consider the value
	MUST NOT generate delta-seconds with a value greater than 2147483648.		to be either 2147483648 (2^31) or the greatest positive integer it
			can conveniently represent.
			Note: The value 2147483648 is here for historical reasons,
			effectively represents infinity (over 68 years), and does not need
			to be stored in binary form; an implementation could produce it as
			a canned string if any overflow occurs, even if the calculations
			are performed with an arithmetic type incapable of directly
			representing that number. What matters here is that an overflow
			be detected and not treated as a 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
	([Part2]) while eliminating the transfer of information already held		([Part2]) while eliminating 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, we assume that reusing the cached response is desirable and		HTTP, we assume that reusing the cached response is desirable and
	that such reuse is the default behavior when no requirement or local		that such reuse is the default behavior when no requirement or local
	configuration prevents it. Therefore, HTTP cache requirements are		configuration prevents it. Therefore, HTTP cache requirements are
	focused on preventing a cache from either storing a non-reusable		focused on preventing a cache from either storing a non-reusable
	skipping to change at page 6, line 37		skipping to change at page 6, line 46
	* contains a max-age response cache directive (see		* contains a max-age response cache directive (see
	Section 5.2.2.8), or		Section 5.2.2.8), or
	* contains a s-maxage response cache directive (see		* contains a s-maxage response cache directive (see
	Section 5.2.2.9) and the cache is shared, or		Section 5.2.2.9) and the cache is shared, or
	* contains a Cache Control Extension (see Section 5.2.3) that		* contains a Cache Control Extension (see Section 5.2.3) that
	allows it to be cached, or		allows it to be cached, or
	* has a status code that is defined as cacheable (see		* has a status code that is defined as cacheable by default (see
	Section 4.2.2), or		Section 4.2.2), or
	* contains a public response cache directive (see		* contains a public response cache directive (see
	Section 5.2.2.5).		Section 5.2.2.5).
	Note that any of the requirements listed above can be overridden by a		Note that any of the requirements listed above can be overridden by a
	cache-control extension; see Section 5.2.3.		cache-control extension; see Section 5.2.3.
	In this context, a cache has "understood" a request method or a		In this context, a cache has "understood" a request method or a
	response status code if it recognizes it and implements all specified		response status code if it recognizes it and implements all specified
	skipping to change at page 12, line 45		skipping to change at page 13, line 4
	a cache MAY assign a heuristic expiration time when an explicit time		a cache MAY assign a heuristic expiration time when an explicit time
	is not specified, employing algorithms that use other header field		is not specified, employing algorithms that use other header field
	values (such as the Last-Modified time) to estimate a plausible		values (such as the Last-Modified time) to estimate a plausible
	expiration time. This specification does not provide specific		expiration time. This specification does not provide specific
	algorithms, but does impose worst-case constraints on their results.		algorithms, but does impose worst-case constraints on their results.
	A cache MUST NOT use heuristics to determine freshness when an		A cache MUST NOT use heuristics to determine freshness when an
	explicit expiration time is present in the stored response. Because		explicit expiration time is present in the stored response. Because
	of the requirements in Section 3, this means that, effectively,		of the requirements in Section 3, this means that, effectively,
	heuristics can only be used on responses without explicit freshness		heuristics can only be used on responses without explicit freshness
	whose status codes are defined as cacheable, and responses without		whose status codes are defined as cacheable by default (see Section
	explicit freshness that have been marked as explicitly cacheable		6.1 of [Part2]), and those responses without explicit freshness that
	(e.g., with a "public" response cache directive).		have been marked as explicitly cacheable (e.g., with a "public"
			response cache directive).
	If the response has a Last-Modified header field (Section 2.2 of		If the response has a Last-Modified header field (Section 2.2 of
	[Part4]), caches are encouraged to use a heuristic expiration value		[Part4]), caches are encouraged to use a heuristic expiration value
	that is no more than some fraction of the interval since that time.		that is no more than some fraction of the interval since that time.
	A typical setting of this fraction might be 10%.		A typical setting of this fraction might be 10%.
	When a heuristic is used to calculate freshness lifetime, a cache		When a heuristic is used to calculate freshness lifetime, a cache
	SHOULD generate a Warning header field with a 113 warn-code (see		SHOULD generate a Warning header field with a 113 warn-code (see
	Section 5.5.4) in the response if its current_age is more than 24		Section 5.5.4) in the response if its current_age is more than 24
	hours and such a warning is not already present.		hours and such a warning is not already present.
	skipping to change at page 13, line 45		skipping to change at page 14, line 8
	date_value		date_value
	The term "date_value" denotes the value of the Date header field,		The term "date_value" denotes the value of the Date header field,
	in a form appropriate for arithmetic operations. See Section		in a form appropriate for arithmetic operations. See Section
	7.1.1.2 of [Part2] for the definition of the Date header field,		7.1.1.2 of [Part2] for the definition of the Date header field,
	and for requirements regarding responses without it.		and for requirements regarding responses without it.
	now		now
	The term "now" means "the current value of the clock at the host		The term "now" means "the current value of the clock at the host
	performing the calculation". A host ought to use NTP ([RFC1305])		performing the calculation". A host ought to use NTP ([RFC5905])
	or some similar protocol to synchronize its clocks to Coordinated		or some similar protocol to synchronize its clocks to Coordinated
	Universal Time.		Universal Time.
	request_time		request_time
	The current value of the clock at the host at the time the request		The current value of the clock at the host at the time the request
	resulting in the stored response was made.		resulting in the stored response was made.
	response_time		response_time
	skipping to change at page 21, line 42		skipping to change at page 21, line 52
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.2.1)
	The "max-age" request directive indicates that the client is		The "max-age" request directive indicates that the client is
	unwilling to accept a response whose age is greater than the		unwilling to accept a response whose age is greater than the
	specified number of seconds. Unless the max-stale request directive		specified number of seconds. Unless the max-stale request directive
	is also present, the client is not willing to accept a stale		is also present, the client is not willing to accept a stale
	response.		response.
	Note: This directive uses the token form of the argument syntax;		This directive uses the token form of the argument syntax; e.g.,
	e.g., 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate		'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate the
	the quoted-string form.		quoted-string form.
	5.2.1.2. max-stale		5.2.1.2. max-stale
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.2.1)
	The "max-stale" request directive indicates that the client is		The "max-stale" request directive indicates that the client is
	willing to accept a response that has exceeded its freshness		willing to accept a response that has exceeded its freshness
	lifetime. If max-stale is assigned a value, then the client is		lifetime. If max-stale is assigned a value, then the client is
	willing to accept a response that has exceeded its freshness lifetime		willing to accept a response that has exceeded its freshness lifetime
	by no more than the specified number of seconds. If no value is		by no more than the specified number of seconds. If no value is
	assigned to max-stale, then the client is willing to accept a stale		assigned to max-stale, then the client is willing to accept a stale
	response of any age.		response of any age.
	Note: This directive uses the token form of the argument syntax;		This directive uses the token form of the argument syntax; e.g.,
	e.g., 'max-stale=10', not 'max-stale="10"'. A sender SHOULD NOT		'max-stale=10', not 'max-stale="10"'. A sender SHOULD NOT generate
	generate the quoted-string form.		the quoted-string form.
	5.2.1.3. min-fresh		5.2.1.3. min-fresh
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.2.1)
	The "min-fresh" request directive indicates that the client is		The "min-fresh" request directive indicates that the client is
	willing to accept a response whose freshness lifetime is no less than		willing to accept a response whose freshness lifetime is no less than
	its current age plus the specified time in seconds. That is, the		its current age plus the specified time in seconds. That is, the
	client wants a response that will still be fresh for at least the		client wants a response that will still be fresh for at least the
	specified number of seconds.		specified number of seconds.
	Note: This directive uses the token form of the argument syntax;		This directive uses the token form of the argument syntax; e.g.,
	e.g., 'min-fresh=20', not 'min-fresh="20"'. A sender SHOULD NOT		'min-fresh=20', not 'min-fresh="20"'. A sender SHOULD NOT generate
	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 a cache MUST NOT use
	a stored response to satisfy the request without successful		a stored response to satisfy the request without successful
	validation on the origin server.		validation on the origin server.
	5.2.1.5. no-store		5.2.1.5. no-store
	The "no-store" request directive indicates that a cache MUST NOT		The "no-store" request directive indicates that a cache MUST NOT
	skipping to change at page 24, line 19		skipping to change at page 24, line 29
	subject to any other restrictions on caching. However, any header		subject to any other restrictions on caching. However, any header
	fields in the response that have the field-name(s) listed MUST NOT be		fields in the response that have the field-name(s) listed MUST NOT be
	sent in the response to a subsequent request without successful		sent in the response to a subsequent request without successful
	revalidation with the origin server. This allows an origin server to		revalidation with the origin server. This allows an origin server to
	prevent the re-use of certain header fields in a response, while		prevent the re-use of certain header fields in a response, while
	still allowing caching of the rest of the response.		still allowing caching of the rest of the response.
	The field-names given are not limited to the set of header fields		The field-names given are not limited to the set of header fields
	defined by this specification. Field names are case-insensitive.		defined by this specification. Field names are case-insensitive.
			This directive uses the quoted-string form of the argument syntax. A
			sender SHOULD NOT generate the token form (even if quoting appears
			not to be needed for single-entry lists).
	Note: Although it has been back-ported to many implementations, some		Note: Although it has been back-ported to many implementations, some
	HTTP/1.0 caches will not recognize or obey this directive. Also, no-		HTTP/1.0 caches will not recognize or obey this directive. Also, no-
	cache response directives with field-names are often handled by		cache response directives with field-names are often handled by
	caches as if an unqualified no-cache directive was received; i.e.,		caches as if an unqualified no-cache directive was received; i.e.,
	the special handling for the qualified form is not widely		the special handling for the qualified form is not widely
	implemented.		implemented.
	Note: This directive uses the quoted-string form of the argument
	syntax. A sender SHOULD NOT generate the token form (even if quoting
	appears not to be needed for single-entry lists).
	5.2.2.3. no-store		5.2.2.3. no-store
	The "no-store" response directive indicates that a cache MUST NOT		The "no-store" response directive indicates that a cache MUST NOT
	store any part of either the immediate request or response. This		store any part of either the immediate request or response. This
	directive applies to both private and shared caches. "MUST NOT		directive applies to both private and shared caches. "MUST NOT
	store" in this context means that the cache MUST NOT intentionally		store" in this context means that the cache MUST NOT intentionally
	store the information in non-volatile storage, and MUST make a 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
	promptly as possible after forwarding it.		promptly as possible after forwarding it.
	skipping to change at page 25, line 13		skipping to change at page 25, line 20
	payload, as defined in Section 5.7.2 of [Part1].		payload, as defined in Section 5.7.2 of [Part1].
	5.2.2.5. public		5.2.2.5. public
	The "public" response directive indicates that any cache MAY store		The "public" response directive indicates that any cache MAY store
	the response, even if the response would normally be non-cacheable or		the response, even if the response would normally be non-cacheable or
	cacheable only within a private cache. (See Section 3.2 for		cacheable only within a private cache. (See Section 3.2 for
	additional details related to the use of public in response to a		additional details related to the use of public in response to a
	request containing Authorization, and Section 3 for details of how		request containing Authorization, and Section 3 for details of how
	public affects responses that would normally not be stored, due to		public affects responses that would normally not be stored, due to
	their status codes not being defined as cacheable.)		their status codes not being defined as cacheable by default; see
			Section 4.2.2.)
	5.2.2.6. private		5.2.2.6. private
	Argument syntax:		Argument syntax:
	#field-name		#field-name
	The "private" response directive indicates that the response message		The "private" response directive indicates that the response message
	is intended for a single user and MUST NOT be stored by a shared		is intended for a single user and MUST NOT be stored by a shared
	cache. A private cache MAY store the response and reuse it for later		cache. A private cache MAY store the response and reuse it for later
	skipping to change at page 25, line 35		skipping to change at page 25, line 43
	If the private response directive specifies one or more field-names,		If the private response directive specifies one or more field-names,
	this requirement is limited to the field-values associated with the		this requirement is limited to the field-values associated with the
	listed response header fields. That is, a shared cache MUST NOT		listed response header fields. That is, a shared cache MUST NOT
	store the specified field-names(s), whereas it MAY store the		store the specified field-names(s), whereas it MAY store the
	remainder of the response message.		remainder of the response message.
	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
			sender SHOULD NOT generate the token form (even if quoting appears
			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, private response directives with field-names are		content. Also, private response directives with field-names are
	often handled by caches as if an unqualified private directive was		often handled by caches as if an unqualified private directive was
	received; i.e., the special handling for the qualified form is not		received; i.e., the special handling for the qualified form is not
	widely implemented.		widely implemented.
	Note: This directive uses the quoted-string form of the argument
	syntax. A sender SHOULD NOT generate the token form (even if quoting
	appears not to be needed for single-entry lists).
	5.2.2.7. proxy-revalidate		5.2.2.7. proxy-revalidate
	The "proxy-revalidate" response directive has the same meaning as the		The "proxy-revalidate" response directive has the same meaning as the
	must-revalidate response directive, except that it does not apply to		must-revalidate response directive, except that it does not apply to
	private caches.		private caches.
	5.2.2.8. max-age		5.2.2.8. max-age
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.2.1)
	The "max-age" response directive indicates that the response is to be		The "max-age" response directive indicates that the response is to be
	considered stale after its age is greater than the specified number		considered stale after its age is greater than the specified number
	of seconds.		of seconds.
	Note: This directive uses the token form of the argument syntax;		This directive uses the token form of the argument syntax; e.g.,
	e.g., 'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate		'max-age=5', not 'max-age="5"'. A sender SHOULD NOT generate the
	the quoted-string form.		quoted-string form.
	5.2.2.9. s-maxage		5.2.2.9. s-maxage
	Argument syntax:		Argument syntax:
	delta-seconds (see Section 1.2.1)		delta-seconds (see Section 1.2.1)
	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.
	Note: This directive uses the token form of the argument syntax;		This directive uses the token form of the argument syntax; e.g.,
	e.g., 's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT		's-maxage=10', not 's-maxage="10"'. A sender SHOULD NOT generate the
	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.		or more cache-extension tokens, each with an optional value.
	Informational extensions (those that do not require a change in cache		Informational extensions (those that do not require a change in cache
	behavior) can be added without changing the semantics of other		behavior) can be added without changing the semantics of other
	directives. Behavioral extensions are designed to work by acting as		directives. Behavioral extensions are designed to work by acting as
	modifiers to the existing base of cache directives.		modifiers to the existing base of cache directives.
	skipping to change at page 32, line 12		skipping to change at page 32, line 18
	This does not prohibit the history mechanism from telling the user		This does not prohibit the history mechanism from telling the user
	that a view might be stale, or from honoring cache directives (e.g.,		that a view might be stale, or from honoring cache directives (e.g.,
	Cache-Control: no-store).		Cache-Control: no-store).
	7. IANA Considerations		7. IANA Considerations
	7.1. Cache Directive Registry		7.1. Cache Directive Registry
	The HTTP Cache Directive Registry defines the name space for the		The HTTP Cache Directive Registry defines the name space for the
	cache directives. It will be created and maintained at		cache directives. It will be created and maintained at (the
			suggested URI)
	<http://www.iana.org/assignments/http-cache-directives>.		<http://www.iana.org/assignments/http-cache-directives>.
	7.1.1. Procedure		7.1.1. Procedure
	A registration MUST include the following fields:		A registration MUST include the following fields:
	o Cache Directive Name		o Cache Directive Name
	o Pointer to specification text		o Pointer to specification text
	skipping to change at page 33, line 27		skipping to change at page 33, line 32
	| 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 |
	+------------------------+----------------------------------+		+------------------------+----------------------------------+
	7.2. Warn Code Registry		7.2. Warn Code Registry
	The HTTP Warn Code Registry defines the name space for warn codes.		The HTTP Warn Code Registry defines the name space for warn codes.
	It will be created and maintained at		It will be created and maintained at (the suggested URI)
	<http://www.iana.org/assignments/http-warn-codes>.		<http://www.iana.org/assignments/http-warn-codes>.
	7.2.1. Procedure		7.2.1. Procedure
	A registration MUST include the following fields:		A registration MUST include the following fields:
	o Warn Code (3 digits)		o Warn Code (3 digits)
	o Short Description		o Short Description
	skipping to change at page 35, line 38		skipping to change at page 35, line 38
	9. Acknowledgments		9. Acknowledgments
	See Section 10 of [Part1].		See Section 10 of [Part1].
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-24 (work in progress),		draft-ietf-httpbis-p1-messaging-25 (work in progress),
	September 2013.		November 2013.
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-24 (work in progress),		draft-ietf-httpbis-p2-semantics-25 (work in progress),
	September 2013.		November 2013.
	[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Conditional Requests",		Protocol (HTTP/1.1): Conditional Requests",
	draft-ietf-httpbis-p4-conditional-24 (work in progress),		draft-ietf-httpbis-p4-conditional-25 (work in progress),
	September 2013.		November 2013.
	[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",		"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
	draft-ietf-httpbis-p5-range-24 (work in progress),		draft-ietf-httpbis-p5-range-25 (work in progress),
	September 2013.		November 2013.
	[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Authentication",		Protocol (HTTP/1.1): Authentication",
	draft-ietf-httpbis-p7-auth-24 (work in progress),		draft-ietf-httpbis-p7-auth-25 (work in progress),
	September 2013.		November 2013.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	10.2. Informative References		10.2. Informative References
	[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation", RFC 1305, March 1992.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale		[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
	Content", RFC 5861, April 2010.		Content", RFC 5861, April 2010.
			[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
			"Network Time Protocol Version 4: Protocol and Algorithms
			Specification", RFC 5905, June 2010.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	April 2011.		April 2011.
	Appendix A. Changes from RFC 2616		Appendix A. Changes from RFC 2616
	The specification has been substantially rewritten for clarity.		The specification has been substantially rewritten for clarity.
	The conditions under which an authenticated response can be cached		The conditions under which an authenticated response can be cached
	have been clarified. (Section 3.2)		have been clarified. (Section 3.2)
	skipping to change at page 39, line 49		skipping to change at page 39, line 49
	warn-agent = ( uri-host [ ":" port ] ) / pseudonym		warn-agent = ( uri-host [ ":" port ] ) / pseudonym
	warn-code = 3DIGIT		warn-code = 3DIGIT
	warn-date = DQUOTE HTTP-date DQUOTE		warn-date = DQUOTE HTTP-date DQUOTE
	warn-text = quoted-string		warn-text = quoted-string
	warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date		warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
	]		]
	Appendix D. Change Log (to be removed by RFC Editor before publication)		Appendix D. Change Log (to be removed by RFC Editor before publication)
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the IETF Last Call draft are summarized in <http://
	in <http://trac.tools.ietf.org/html/		trac.tools.ietf.org/html/draft-ietf-httpbis-p6-cache-24#appendix-D>.
	draft-ietf-httpbis-p6-cache-19#appendix-C>.
	D.1. Since draft-ietf-httpbis-p6-cache-19
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/307>: "untangle
	Cache-Control ABNF"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/353>: "Multiple
	values in Cache-Control header fields"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/355>: "Case
	sensitivity of header fields in CC values"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/356>: "Spurious
	'MAYs'"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/360>: "enhance
	considerations for new cache control directives"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
	requirements for recipients"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
	introduction of new IANA registries as normative changes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/373>: "broken prose
	in description of 'Vary'"
	D.2. Since draft-ietf-httpbis-p6-cache-20
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/375>: "'Most
	Conservative'"
	Other changes:
	o Conformance criteria and considerations regarding error handling
	are now defined in Part 1.
	o Move definition of "Vary" header field into Part 2.
	o Add security considerations with respect to cache poisoning and
	the "Set-Cookie" header field.
	D.3. Since draft-ietf-httpbis-p6-cache-21
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
	heuristic caching for new status codes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/406>: "304 without
	validator"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/430>: "Revert prior
	change to the meaning of the public cache response directive.
	D.4. Since draft-ietf-httpbis-p6-cache-22		D.1. Since draft-ietf-httpbis-p6-cache-24
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list		o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
	expansion in ABNF appendices"		needs to be updated to 5905"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/453>: "Returning the
	freshest response"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/464>: "placement of
	extension point considerations"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/469>: "Editorial
	notes for p6"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/471>: "Vary and
	future requests"
	D.5. Since draft-ietf-httpbis-p6-cache-23
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/486>: "Requiring		o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling
	proxies to process warn-date"		reference to cacheable status codes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/496>: "add Warning		o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR
	header field examples"		review of draft-ietf-httpbis-p6-cache-24"
	Index		Index
	1		1
	110 (warn-code) 30		110 (warn-code) 31
	111 (warn-code) 31		111 (warn-code) 31
	112 (warn-code) 31		112 (warn-code) 31
	113 (warn-code) 31		113 (warn-code) 31
	199 (warn-code) 31		199 (warn-code) 31
	2		2
	214 (warn-code) 31		214 (warn-code) 31
	299 (warn-code) 31		299 (warn-code) 31
	A		A
	age 10		age 10
	Age header field 20		Age header field 20
	C		C
	cache 4		cache 4
	cache entry 5		cache entry 5
	cache key 5		cache key 5
	Cache-Control header field 20		Cache-Control header field 21
	D		D
	Disconnected Operation (warn-text) 31		Disconnected Operation (warn-text) 31
	E		E
	Expires header field 27		Expires header field 27
	explicit expiration time 10		explicit expiration time 10
	F		F
	fresh 10		fresh 10
	skipping to change at page 43, line 9		skipping to change at page 41, line 26
	warn-text 29		warn-text 29
	Warning 29		Warning 29
	warning-value 29		warning-value 29
	H		H
	Heuristic Expiration (warn-text) 31		Heuristic Expiration (warn-text) 31
	heuristic expiration time 10		heuristic expiration time 10
	M		M
	max-age (cache directive) 21, 26		max-age (cache directive) 21, 26
	max-stale (cache directive) 21		max-stale (cache directive) 22
	min-fresh (cache directive) 22		min-fresh (cache directive) 22
	Miscellaneous Persistent Warning (warn-text) 31		Miscellaneous Persistent Warning (warn-text) 31
	Miscellaneous Warning (warn-text) 31		Miscellaneous Warning (warn-text) 31
	must-revalidate (cache directive) 23		must-revalidate (cache directive) 23
	N		N
	no-cache (cache directive) 22-23		no-cache (cache directive) 22, 24
	no-store (cache directive) 22, 24		no-store (cache directive) 22, 24
	no-transform (cache directive) 23-24		no-transform (cache directive) 23, 25
	O		O
	only-if-cached (cache directive) 23		only-if-cached (cache directive) 23
	P		P
	Pragma header field 28		Pragma header field 28
	private (cache directive) 25		private (cache directive) 25
	private cache 4		private cache 4
	proxy-revalidate (cache directive) 25		proxy-revalidate (cache directive) 26
	public (cache directive) 25		public (cache directive) 25
	R		R
	Response is Stale (warn-text) 30		Response is Stale (warn-text) 31
	Revalidation Failed (warn-text) 31		Revalidation Failed (warn-text) 31
	S		S
	s-maxage (cache directive) 26		s-maxage (cache directive) 26
	shared cache 4		shared cache 4
	stale 10		stale 10
	strong validator 18		strong validator 18
	T		T
	Transformation Applied (warn-text) 31		Transformation Applied (warn-text) 31
End of changes. 47 change blocks.
	160 lines changed or deleted		93 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/