draft-ietf-httpbis-p6-cache-25.txt		draft-ietf-httpbis-p6-cache-26.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: May 21, 2014 J. Reschke, Ed.		Expires: August 10, 2014 J. Reschke, Ed.
	greenbytes		greenbytes
	November 17, 2013		February 6, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Caching		Hypertext Transfer Protocol (HTTP/1.1): Caching
	draft-ietf-httpbis-p6-cache-25		draft-ietf-httpbis-p6-cache-26
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	protocol for distributed, collaborative, hypertext information		level protocol for distributed, collaborative, hypertext information
	systems. This document defines requirements on HTTP caches and the		systems. This document defines HTTP caches and the associated header
	associated header fields that control cache behavior or indicate		fields that control cache behavior or indicate cacheable response
	cacheable response messages.		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.1.		The changes in this draft are summarized in Appendix D.2.
	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 May 21, 2014.		This Internet-Draft will expire on August 10, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	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 3, line 19		skipping to change at page 3, line 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 . . . . . . . . . . . . . . . . . . . . . . 21		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" . . . . . . . . . . 31		5.5.1. Warning: 110 - "Response is Stale" . . . . . . . . . . 30
	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 . . . . . . . . . . . . . . . . . . . . 33		7.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 32
	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-24 . . . . . . . . . . . 40		D.1. Since draft-ietf-httpbis-p6-cache-24 . . . . . . . . . . . 40
			D.2. Since draft-ietf-httpbis-p6-cache-25 . . . . . . . . . . . 40
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	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
	cache stores cacheable responses in order to reduce the response time		cache stores cacheable responses in order to reduce the response time
	and network bandwidth consumption on future, equivalent requests.		and network bandwidth consumption on future, equivalent requests.
	Any client or server MAY employ a cache, though a cache cannot be		Any client or server MAY employ a cache, though a cache cannot be
	used by a server that is acting as a tunnel.		used by a server that is acting as a tunnel.
	A shared cache is a cache that stores responses to be reused by more		A shared cache is a cache that stores responses to be reused by more
	than one user; shared caches are usually (but not always) deployed as		than one user; shared caches are usually (but not always) deployed as
	a part of an intermediary. A private cache, in contrast, is		a part of an intermediary. A private cache, in contrast, is
	dedicated to a single user.		dedicated to a single user; often, they are deployed as a component
			of a user agent.
	The goal of caching in HTTP/1.1 is to significantly improve		The goal of caching in HTTP/1.1 is to significantly improve
	performance by reusing a prior response message to satisfy a current		performance by reusing a prior response message to satisfy a current
	request. A stored response is considered "fresh", as defined in		request. A stored response is considered "fresh", as defined in
	Section 4.2, if the response can be reused without "validation"		Section 4.2, if the response can be reused without "validation"
	(checking with the origin server to see if the cached response		(checking with the origin server to see if the cached response
	remains valid for this request). A fresh response can therefore		remains valid for this request). A fresh response can therefore
	reduce both latency and network overhead each time it is reused.		reduce both latency and network overhead each time it is reused.
	When a cached response is not fresh, it might still be reusable if it		When a cached response is not fresh, it might still be reusable if it
	can be freshened by validation (Section 4.3) or if the origin is		can be freshened by validation (Section 4.3) or if the origin is
	skipping to change at page 4, line 47		skipping to change at page 4, line 48
	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 2.5 of [Part1].		defined in Section 2.5 of [Part1].
	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 the list rule extension defined in Section		notation of [RFC5234] with a list extension, defined in Section 7 of
	7 of [Part1]. Appendix B describes rules imported from other		[Part1], that allows for compact definition of comma-separated lists
	documents. Appendix C shows the collected ABNF with the list rule		using a '#' operator (similar to how the '*' operator indicates
	expanded.		repetition). Appendix B describes rules imported from other
			documents. Appendix C shows the collected grammar with all list
			operators expanded to standard ABNF notation.
	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
	A recipient parsing a delta-seconds value and converting it to binary		A recipient parsing a delta-seconds value and converting it to binary
	form ought to use an arithmetic type of at least 31 bits of non-		form ought to use an arithmetic type of at least 31 bits of non-
	skipping to change at page 5, line 34		skipping to change at page 5, line 35
	are performed with an arithmetic type incapable of directly		are performed with an arithmetic type incapable of directly
	representing that number. What matters here is that an overflow		representing that number. What matters here is that an overflow
	be detected and not treated as a negative value in later		be detected and not treated as a negative value in later
	calculations.		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, it can be assumed that reusing a cached response is desirable
	that such reuse is the default behavior when no requirement or local		and that such reuse is the default behavior when no requirement or
	configuration prevents it. Therefore, HTTP cache requirements are		local configuration prevents it. Therefore, HTTP cache requirements
	focused on preventing a cache from either storing a non-reusable		are focused on preventing a cache from either storing a non-reusable
	response or reusing a stored response inappropriately, rather than		response or reusing a stored response inappropriately, rather than
	mandating that caches always store and reuse particular responses.		mandating that caches always store and reuse particular responses.
	Each cache entry consists of a cache key and one or more HTTP		Each cache entry consists of a cache key and one or more HTTP
	responses corresponding to prior requests that used the same key.		responses corresponding to prior requests that used the same key.
	The most common form of cache entry is a successful result of a		The most common form of cache entry is a successful result of a
	retrieval request: i.e., a 200 (OK) response to a GET request, which		retrieval request: i.e., a 200 (OK) response to a GET request, which
	contains a representation of the resource identified by the request		contains a representation of the resource identified by the request
	target (Section 4.3.1 of [Part2]). However, it is also possible to		target (Section 4.3.1 of [Part2]). However, it is also possible to
	cache permanent redirects, negative results (e.g., 404 (Not Found)),		cache permanent redirects, negative results (e.g., 404 (Not Found)),
	skipping to change at page 6, line 26		skipping to change at page 6, line 27
	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 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 request or response header fields, and
	o the "private" cache response directive (see Section 5.2.2.6) does		o the "private" response directive (see Section 5.2.2.6) does not
	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 4.1 of [Part7]) does		o the Authorization header field (see Section 4.2 of [Part7]) does
	not appear in the request, if the cache is shared, unless the		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:
	* contains an Expires header field (see Section 5.3), or		* contains an Expires header field (see Section 5.3), or
	* contains a max-age response cache directive (see		* contains a max-age response 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 directive (see Section 5.2.2.9)
	Section 5.2.2.9) and the cache is shared, or		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 by default (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 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
	caching-related behavior.		caching-related behavior.
	Note that, in normal operation, some caches will not store a response		Note that, in normal operation, some caches will not store a response
	that has neither a cache validator nor an explicit expiration time,		that has neither a cache validator nor an explicit expiration time,
	skipping to change at page 7, line 41		skipping to change at page 7, line 40
	response with the stored entry, as defined in Section 3.3. A cache		response with the stored entry, as defined in Section 3.3. A cache
	MUST NOT use an incomplete response to answer requests unless the		MUST NOT use an incomplete response to answer requests unless the
	response has been made complete or the request is partial and		response has been made complete or the request is partial and
	specifies a range that is wholly within the incomplete response. A		specifies a range that is wholly within the incomplete response. A
	cache MUST NOT send a partial response to a client without explicitly		cache MUST NOT send a partial response to a client without explicitly
	marking it as such using the 206 (Partial Content) status code.		marking it as such using the 206 (Partial Content) 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 4.1 of [Part7]) to satisfy any		Authorization header field (Section 4.2 of [Part7]) to satisfy any
	subsequent request unless a cache directive that allows such		subsequent request unless a cache directive that allows such
	responses to be stored is present in the response.		responses to be stored is present in the response.
	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, s-maxage.		public, s-maxage.
	Note that cached responses that contain the "must-revalidate" and/or		Note that cached responses that contain the "must-revalidate" and/or
	"s-maxage" response directives are not allowed to be served stale		"s-maxage" response directives are not allowed to be served stale
	(Section 4.2.4) by shared caches. In particular, a response with		(Section 4.2.4) by shared caches. In particular, a response with
	skipping to change at page 11, line 12		skipping to change at page 11, line 8
	A response's age is the time that has passed since it was generated		A response's age is the time that has passed since it was generated
	by, or successfully validated with, the origin server.		by, or successfully validated with, the origin server.
	When a response is "fresh" in the cache, it can be used to satisfy		When a response is "fresh" in the cache, it can be used to satisfy
	subsequent requests without contacting the origin server, thereby		subsequent requests without contacting the origin server, thereby
	improving efficiency.		improving efficiency.
	The primary mechanism for determining freshness is for an origin		The primary mechanism for determining freshness is for an origin
	server to provide an explicit expiration time in the future, using		server to provide an explicit expiration time in the future, using
	either the Expires header field (Section 5.3) or the max-age response		either the Expires header field (Section 5.3) or the max-age response
	cache directive (Section 5.2.2.8). Generally, origin servers will		directive (Section 5.2.2.8). Generally, origin servers will assign
	assign future explicit expiration times to responses in the belief		future explicit expiration times to responses in the belief that the
	that the representation is not likely to change in a semantically		representation is not likely to change in a semantically significant
	significant way before the expiration time is reached.		way before the expiration time is reached.
	If an origin server wishes to force a cache to validate every		If an origin server wishes to force a cache to validate every
	request, it can assign an explicit expiration time in the past to		request, it can assign an explicit expiration time in the past to
	indicate that the response is already stale. Compliant caches will		indicate that the response is already stale. Compliant caches will
	normally validate a stale cached response before reusing it for		normally validate a stale cached response before reusing it for
	subsequent requests (see Section 4.2.4).		subsequent requests (see Section 4.2.4).
	Since origin servers do not always provide explicit expiration times,		Since origin servers do not always provide explicit expiration times,
	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).
	skipping to change at page 12, line 18		skipping to change at page 12, line 12
	Note that freshness applies only to cache operation; it cannot be		Note that freshness applies only to cache operation; it cannot be
	used to force a user agent to refresh its display or reload a		used to force a user agent to refresh its display or reload a
	resource. See Section 6 for an explanation of the difference between		resource. See Section 6 for an explanation of the difference between
	caches and history mechanisms.		caches and history mechanisms.
	4.2.1. Calculating Freshness Lifetime		4.2.1. Calculating Freshness Lifetime
	A cache can calculate the freshness lifetime (denoted as		A cache can calculate the freshness lifetime (denoted as
	freshness_lifetime) of a response by using the first match of:		freshness_lifetime) of a response by using the first match of:
	o If the cache is shared and the s-maxage response cache directive		o If the cache is shared and the s-maxage response directive
	(Section 5.2.2.9) is present, use its value, or		(Section 5.2.2.9) is present, use its value, or
	o If the max-age response cache directive (Section 5.2.2.8) is		o If the max-age response directive (Section 5.2.2.8) is present,
	present, use its value, or		use its value, or
	o If the Expires response header field (Section 5.3) is present, use		o If the Expires response header field (Section 5.3) is present, use
	its value minus the value of the Date response header field, or		its value minus the value of the Date response header field, or
	o Otherwise, no explicit expiration time is present in the response.		o Otherwise, no explicit expiration time is present in the response.
	A heuristic freshness lifetime might be applicable; see		A heuristic freshness lifetime might be applicable; see
	Section 4.2.2.		Section 4.2.2.
	Note that this calculation is not vulnerable to clock skew, since all		Note that this calculation is not vulnerable to clock skew, since all
	of the information comes from the origin server.		of the information comes from the origin server.
	skipping to change at page 13, line 7		skipping to change at page 12, line 50
	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 by default (see Section		whose status codes are defined as cacheable by default (see Section
	6.1 of [Part2]), and those responses without explicit freshness that		6.1 of [Part2]), and those responses without explicit freshness that
	have been marked as explicitly cacheable (e.g., with a "public"		have been marked as explicitly cacheable (e.g., with a "public"
	response cache directive).		response 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 19, line 25		skipping to change at page 19, line 25
	When a cache makes an inbound HEAD request for a given request target		When a cache makes an inbound HEAD request for a given request target
	and receives a 200 (OK) response, the cache SHOULD update or		and receives a 200 (OK) response, the cache SHOULD update or
	invalidate each of its stored GET responses that could have been		invalidate each of its stored GET responses that could have been
	selected for that request (see Section 4.1).		selected for that request (see Section 4.1).
	For each of the stored responses that could have been selected, if		For each of the stored responses that could have been selected, if
	the stored response and HEAD response have matching values for any		the stored response and HEAD response have matching values for any
	received validator fields (ETag and Last-Modified) and, if the HEAD		received validator fields (ETag and Last-Modified) and, if the HEAD
	response has a Content-Length header field, the value of Content-		response has a Content-Length header field, the value of Content-
	Length matches that of the stored response, the cache SHOULD update		Length matches that of the stored response, the cache SHOULD update
	the stored response a described below; otherwise, the cache SHOULD		the stored response as described below; otherwise, the cache SHOULD
	consider the stored response to be stale.		consider the stored response to be stale.
	If a cache updates a stored response with the metadata provided in a		If a cache updates a stored response with the metadata provided in a
	HEAD response, the cache MUST:		HEAD response, the cache MUST:
	o delete any Warning header fields in the stored response with warn-		o delete any Warning header fields in the stored response with warn-
	code 1xx (see Section 5.5);		code 1xx (see Section 5.5);
	o retain any Warning header fields in the stored response with warn-		o retain any Warning header fields in the stored response with warn-
	code 2xx; and,		code 2xx; and,
	skipping to change at page 26, line 45		skipping to change at page 26, line 45
	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.
	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.		or more cache-extension tokens, each with an optional value. A cache
			MUST ignore unrecognized cache directives.
	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.
	modifiers to the existing base of cache directives.
	Both the new directive and the standard directive are supplied, such
	that applications that do not understand the new directive will
	default to the behavior specified by the standard directive, and
	those that understand the new directive will recognize it as
	modifying the requirements associated with the standard directive.
	In this way, extensions to the cache-control directives can be made
	without requiring changes to the base protocol.
	This extension mechanism depends on an HTTP cache obeying all of the		Behavioral extensions are designed to work by acting as modifiers to
	cache-control directives defined for its native HTTP-version, obeying		the existing base of cache directives. Both the new directive and
	certain extensions, and ignoring all directives that it does not		the old directive are supplied, such that applications that do not
	understand.		understand the new directive will default to the behavior specified
			by the old directive, and those that understand the new directive
			will recognize it as modifying the requirements associated with the
			old directive. In this way, extensions to the existing cache-control
			directives can be made without breaking deployed caches.
	For example, consider a hypothetical new response directive called		For example, consider a hypothetical new response directive called
	"community" that acts as a modifier to the private directive. We		"community" that acts as a modifier to the private directive: in
	define this new directive to mean that, in addition to any private		addition to private caches, any cache that is shared only by members
	cache, any cache that is shared only by members of the community		of the named community is allowed to cache the response. An origin
	named within its value is allowed to cache the response. An origin
	server wishing to allow the UCI community to use an otherwise private		server wishing to allow the UCI community to use an otherwise private
	response in their shared cache(s) could do so by including		response in their shared cache(s) could do so by including
	Cache-Control: private, community="UCI"		Cache-Control: private, community="UCI"
	A cache seeing this header field will act correctly even if the cache		A cache that recognizes such a community cache-extension could
	does not understand the community cache-extension, since it will also		broaden its behavior in accordance with that extension. A cache that
	see and understand the private directive and thus default to the safe		does not recognize the community cache-extension would ignore it and
	behavior.		adhere to the private directive.
	A cache MUST ignore unrecognized cache directives; it is assumed that
	any cache directive likely to be unrecognized by an HTTP/1.1 cache
	will be combined with standard directives (or the response's default
	cacheability) such that the cache behavior will remain minimally
	correct even if the cache does not understand the extension(s).
	5.3. Expires		5.3. Expires
	The "Expires" header field gives the date/time after which the		The "Expires" header field gives the date/time after which the
	response is considered stale. See Section 4.2 for further discussion		response is considered stale. See Section 4.2 for further discussion
	of the freshness model.		of the freshness model.
	The presence of an Expires field does not imply that the original		The presence of an Expires field does not imply that the original
	resource will change or cease to exist at, before, or after that		resource will change or cease to exist at, before, or after that
	time.		time.
	skipping to change at page 30, line 40		skipping to change at page 30, line 29
	If a sender generates one or more 1xx warn-codes in a message to be		If a sender generates one or more 1xx warn-codes in a message to be
	sent to a recipient known to implement only HTTP/1.0, the sender MUST		sent to a recipient known to implement only HTTP/1.0, the sender MUST
	include in each corresponding warning-value a warn-date that matches		include in each corresponding warning-value a warn-date that matches
	the Date header field in the message. For example:		the Date header field in the message. For example:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Sat, 25 Aug 2012 23:34:45 GMT		Date: Sat, 25 Aug 2012 23:34:45 GMT
	Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"		Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"
			Warnings have accompanying warn-text that describes the error, e.g.,
			for logging. It is advisory only, and its content does not affect
			interpretation of the warn-code.
	If a recipient that uses, evaluates, or displays Warning header		If a recipient that uses, evaluates, or displays Warning header
	fields receives a warn-date that is different from the Date value in		fields receives a warn-date that is different from the Date value in
	the same message, the recipient MUST exclude the warning-value		the same message, the recipient MUST exclude the warning-value
	containing that warn-date before storing, forwarding, or using the		containing that warn-date before storing, forwarding, or using the
	message. This allows recipients to exclude warning-values that were		message. This allows recipients to exclude warning-values that were
	improperly retained after a cache validation. If all of the warning-		improperly retained after a cache validation. If all of the warning-
	values are excluded, the recipient MUST exclude the Warning header		values are excluded, the recipient MUST exclude the Warning header
	field as well.		field as well.
	The following warn-codes are defined by this specification, each with		The following warn-codes are defined by this specification, each with
	skipping to change at page 34, line 43		skipping to change at page 34, line 43
	| Pragma | http | standard | Section 5.4 |		| Pragma | http | standard | Section 5.4 |
	| Warning | http | standard | Section 5.5 |		| Warning | http | standard | Section 5.5 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	8. Security Considerations		8. Security Considerations
	This section is meant to inform developers, information providers,		This section is meant to inform developers, information providers,
	and users of known security concerns specific to HTTP/1.1 caching.		and users of known security concerns specific to HTTP caching. More
	More general security considerations are addressed in HTTP messaging		general security considerations are addressed in HTTP messaging
	[Part1] and semantics [Part2].		[Part1] and semantics [Part2].
	Caches expose additional potential vulnerabilities, since the		Caches expose additional potential vulnerabilities, since the
	contents of the cache represent an attractive target for malicious		contents of the cache represent an attractive target for malicious
	exploitation. Because cache contents persist after an HTTP request		exploitation. Because cache contents persist after an HTTP request
	is complete, an attack on the cache can reveal information long after		is complete, an attack on the cache can reveal information long after
	a user believes that the information has been removed from the		a user believes that the information has been removed from the
	network. Therefore, cache contents need to be protected as sensitive		network. Therefore, cache contents need to be protected as sensitive
	information.		information.
	Furthermore, the very use of a cache can bring about privacy		In particular, various attacks might be amplified by being stored in
	concerns. For example, if two users share a cache, and the first one		a shared cache; such "cache poisoning" attacks use the cache to
	browses to a site, the second may be able to detect that the other		distribute a malicious payload to many clients, and are especially
	has been to that site, because the resources from it load more		effective when an attacker can use implementation flaws, elevated
	quickly, thanks to the cache.		privileges, or other techniques to insert such a response into a
			cache. One common attack vector for cache poisoning is to exploit
	Implementation flaws might allow attackers to insert content into a		differences in message parsing on proxies and in user agents; see
	cache ("cache poisoning"), leading to compromise of clients that		Section 3.3.3 of [Part1] for the relevant requirements.
	trust that content. Because of their nature, these attacks are
	difficult to mitigate.
	Likewise, implementation flaws (as well as misunderstanding of cache		Likewise, implementation flaws (as well as misunderstanding of cache
	operation) might lead to caching of sensitive information (e.g.,		operation) might lead to caching of sensitive information (e.g.,
	authentication credentials) that is thought to be private, exposing		authentication credentials) that is thought to be private, exposing
	it to unauthorized parties.		it to unauthorized parties.
			Furthermore, the very use of a cache can bring about privacy
			concerns. For example, if two users share a cache, and the first one
			browses to a site, the second may be able to detect that the other
			has been to that site, because the resources from it load more
			quickly, thanks to the cache.
	Note that the Set-Cookie response header field [RFC6265] does not		Note that the Set-Cookie response header field [RFC6265] does not
	inhibit caching; a cacheable response with a Set-Cookie header field		inhibit caching; a cacheable response with a Set-Cookie header field
	can be (and often is) used to satisfy subsequent requests to caches.		can be (and often is) used to satisfy subsequent requests to caches.
	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.
	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-25 (work in progress),		draft-ietf-httpbis-p1-messaging-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p2-semantics-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p4-conditional-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p5-range-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p7-auth-26 (work in progress),
	November 2013.		February 2014.
	[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
	skipping to change at page 37, line 30		skipping to change at page 37, line 34
	Requirements regarding denial of service attack avoidance when		Requirements regarding denial of service attack avoidance when
	performing invalidation have been clarified. (Section 4.4)		performing invalidation have been clarified. (Section 4.4)
	Cache invalidation only occurs when a successful response is		Cache invalidation only occurs when a successful response is
	received. (Section 4.4)		received. (Section 4.4)
	Cache directives are explicitly defined to be case-insensitive.		Cache directives are explicitly defined to be case-insensitive.
	Handling of multiple instances of cache directives when only one is		Handling of multiple instances of cache directives when only one is
	expected is now defined. (Section 5.2)		expected is now defined. (Section 5.2)
	The "no-store" cache request directive doesn't apply to responses;		The "no-store" request directive doesn't apply to responses; i.e., a
	i.e., a cache can satisfy a request with no-store on it, and does not		cache can satisfy a request with no-store on it, and does not
	invalidate it. (Section 5.2.1.5)		invalidate it. (Section 5.2.1.5)
	The qualified forms of the private and no-cache cache directives are		The qualified forms of the private and no-cache cache directives are
	noted to not be widely implemented; e.g., "private=foo" is		noted to not be widely implemented; e.g., "private=foo" is
	interpreted by many caches as simply "private". Additionally, the		interpreted by many caches as simply "private". Additionally, the
	meaning of the qualified form of no-cache has been clarified.		meaning of the qualified form of no-cache has been clarified.
	(Section 5.2.2)		(Section 5.2.2)
	The "no-cache" response cache directive's meaning has been clarified.		The "no-cache" response directive's meaning has been clarified.
	(Section 5.2.2.2)		(Section 5.2.2.2)
	The one-year limit on Expires header field values has been removed;		The one-year limit on Expires header field values has been removed;
	instead, the reasoning for using a sensible value is given.		instead, the reasoning for using a sensible value is given.
	(Section 5.3)		(Section 5.3)
	The Pragma header field is now only defined for backwards		The Pragma header field is now only defined for backwards
	compatibility; future pragmas are deprecated. (Section 5.4)		compatibility; future pragmas are deprecated. (Section 5.4)
	Some requirements regarding production and processing of the Warning		Some requirements regarding production and processing of the Warning
	skipping to change at page 40, line 18		skipping to change at page 40, line 18
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref		o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
	needs to be updated to 5905"		needs to be updated to 5905"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling		o <http://tools.ietf.org/wg/httpbis/trac/ticket/500>: "dangling
	reference to cacheable status codes"		reference to cacheable status codes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR		o <http://tools.ietf.org/wg/httpbis/trac/ticket/512>: "APPSDIR
	review of draft-ietf-httpbis-p6-cache-24"		review of draft-ietf-httpbis-p6-cache-24"
			D.2. Since draft-ietf-httpbis-p6-cache-25
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/535>: "IESG ballot
			on draft-ietf-httpbis-p6-cache-25"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
			'stateless' to Abstract"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
			introduction of list rule"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
			security considerations with pointers to current research"
	Index		Index
	1		1
	110 (warn-code) 31		110 (warn-code) 30
	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
	skipping to change at page 41, line 48		skipping to change at page 42, line 16
	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) 26		proxy-revalidate (cache directive) 26
	public (cache directive) 25		public (cache directive) 25
	R		R
	Response is Stale (warn-text) 31		Response is Stale (warn-text) 30
	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. 43 change blocks.
	97 lines changed or deleted		112 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/