draft-ietf-httpbis-p6-cache-17.txt		draft-ietf-httpbis-p6-cache-18.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: May 3, 2012 J. Mogul		Expires: July 7, 2012 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	M. Nottingham, Ed.		M. Nottingham, Ed.
	Rackspace		Rackspace
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	October 31, 2011		January 4, 2012
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-17		draft-ietf-httpbis-p6-cache-18
	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. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 6 of the		information initiative since 1990. This document is Part 6 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616.		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	skipping to change at page 2, line 6		skipping to change at page 2, line 6
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org), which is archived at		group 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 C.18.		The changes in this draft are summarized in Appendix C.19.
	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 3, 2012.		This Internet-Draft will expire on July 7, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7		1.3. Conformance and Error Handling . . . . . . . . . . . . . . 7
	1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7		1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
	1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8		1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 8
	1.4.2. ABNF Rules defined in other Parts of the		1.4.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 8		Specification . . . . . . . . . . . . . . . . . . . . 8
	1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8		1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
	2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8		2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9		2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9
	2.2. Constructing Responses from Caches . . . . . . . . . . . . 10		2.2. Constructing Responses from Caches . . . . . . . . . . . . 10
	2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11		2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 12
	2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12		2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 13
	2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13		2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 14
	2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15		2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 16
	2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16		2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16
	2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17		2.4.1. Freshening Responses . . . . . . . . . . . . . . . . . 17
	2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18		2.5. Request Methods that Invalidate . . . . . . . . . . . . . 18
	2.6. Shared Caching of Authenticated Responses . . . . . . . . 18		2.6. Shared Caching of Authenticated Responses . . . . . . . . 18
	2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19		2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 19
	2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20		2.8. Combining Partial Content . . . . . . . . . . . . . . . . 20
	3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20		3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
	3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21		3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 21
	3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21		3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
	3.2.2. Response Cache-Control Directives . . . . . . . . . . 23		3.2.2. Response Cache-Control Directives . . . . . . . . . . 23
	3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26		3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 26
	3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27		3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 27
	3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28		3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28		3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29		3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
	4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 32		3.6.1. 110 Response is Stale . . . . . . . . . . . . . . . . 31
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		3.6.2. 111 Revalidation Failed . . . . . . . . . . . . . . . 31
	5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 32		3.6.3. 112 Disconnected Operation . . . . . . . . . . . . . . 31
	5.2. Header Field Registration . . . . . . . . . . . . . . . . 33		3.6.4. 113 Heuristic Expiration . . . . . . . . . . . . . . . 31
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 33		3.6.5. 199 Miscellaneous Warning . . . . . . . . . . . . . . 31
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33		3.6.6. 214 Transformation Applied . . . . . . . . . . . . . . 31
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33		3.6.7. 299 Miscellaneous Persistent Warning . . . . . . . . . 31
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 33		3.6.8. Warn Code Extensions . . . . . . . . . . . . . . . . . 32
	8.2. Informative References . . . . . . . . . . . . . . . . . . 34		3.7. History Lists . . . . . . . . . . . . . . . . . . . . . . 32
			3.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 32
			3.8.1. Cache Directive Registry . . . . . . . . . . . . . . . 32
			3.8.2. Warn Code Registry . . . . . . . . . . . . . . . . . . 33
			3.9. Header Field Registration . . . . . . . . . . . . . . . . 33
			4. Security Considerations . . . . . . . . . . . . . . . . . . . 34
			5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
			6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
			6.1. Normative References . . . . . . . . . . . . . . . . . . . 34
			6.2. Informative References . . . . . . . . . . . . . . . . . . 35
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 35
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 35		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 36
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 36		publication) . . . . . . . . . . . . . . . . . . . . 37
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 37
	C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37		C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 37
	C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37		C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 38
	C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38		C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 38
	C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 38		C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 39
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 38		C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 39
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38		C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 39
	C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 39		C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 40
	C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 39		C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 40
	C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39		C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 40
	C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 40		C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 41
	C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40		C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 41
	C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41		C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 41
	C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 41		C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 42
	C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 41		C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 42
	C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 41		C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 42
	C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42		C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 42
	C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 42		C.18. Since draft-ietf-httpbis-p6-cache-16 . . . . . . . . . . . 43
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		C.19. Since draft-ietf-httpbis-p6-cache-17 . . . . . . . . . . . 43
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	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.
	1.1. Purpose		1.1. Purpose
	skipping to change at page 11, line 11		skipping to change at page 11, line 11
	o The presented effective request URI (Section 4.3 of [Part1]) and		o The presented effective request URI (Section 4.3 of [Part1]) and
	that of the stored response match, and		that of the stored response match, and
	o the request method associated with the stored response allows it		o the request method associated with the stored response allows it
	to be used for the presented request, and		to be used for the presented request, and
	o selecting header fields nominated by the stored response (if any)		o selecting header fields nominated by the stored response (if any)
	match those presented (see Section 2.7), and		match those presented (see Section 2.7), and
	o the presented request and stored response are free from directives		o the presented request does not contain the no-cache pragma
	that would prevent its use (see Section 3.2 and Section 3.4), and		(Section 3.4), nor the no-cache cache directive (Section 3.2.1),
			unless the stored response is successfully validated
			(Section 2.4), and
			o the stored response does not contain the no-cache cache directive
			(Section 3.2.2), unless it is successfully validated
			(Section 2.4), and
	o the stored response is either:		o the stored response is either:
	* fresh (see Section 2.3), or		* fresh (see Section 2.3), or
	* allowed to be served stale (see Section 2.3.3), or		* allowed to be served stale (see Section 2.3.3), or
	* successfully validated (see Section 2.4).		* successfully validated (see Section 2.4).
	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
	skipping to change at page 12, line 34		skipping to change at page 12, line 40
	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.
	The calculation to determine if a response is fresh is:		The calculation to determine if a response is fresh is:
	response_is_fresh = (freshness_lifetime > current_age)		response_is_fresh = (freshness_lifetime > current_age)
	The freshness_lifetime is defined in Section 2.3.1; the current_age		The freshness_lifetime is defined in Section 2.3.1; the current_age
	is defined in Section 2.3.2.		is defined in Section 2.3.2.
	Additionally, clients might need to influence freshness calculation.		Additionally, clients can influence freshness calculation -- either
	They can do this using several request cache directives, with the		constraining it relaxing it -- by using the max-age and min-fresh
	effect of either increasing or loosening constraints on freshness.		request cache directives. See Section 3.2.1 for details.
	See Section 3.2.1.
	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 4 for an explanation of the difference between		resource. See Section 3.7 for an explanation of the difference
	caches and history mechanisms.		between caches and history mechanisms.
	2.3.1. Calculating Freshness Lifetime		2.3.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 cache directive
	(Section 3.2.2) is present, use its value, or		(Section 3.2.2) is present, use its value, or
	o If the max-age response cache directive (Section 3.2.2) is		o If the max-age response cache directive (Section 3.2.2) is
	skipping to change at page 15, line 10		skipping to change at page 15, line 20
	2. the "corrected_age_value", if all of the caches along the		2. the "corrected_age_value", if all of the caches along the
	response path implement HTTP/1.1. A cache MUST interpret this		response path implement HTTP/1.1. A cache MUST interpret this
	value relative to the time the request was initiated, not the		value relative to the time the request was initiated, not the
	time that the response was received.		time that the response was received.
	apparent_age = max(0, response_time - date_value);		apparent_age = max(0, response_time - date_value);
	response_delay = response_time - request_time;		response_delay = response_time - request_time;
	corrected_age_value = age_value + response_delay;		corrected_age_value = age_value + response_delay;
	These are combined as		These SHOULD be combined as
	corrected_initial_age = max(apparent_age, corrected_age_value);		corrected_initial_age = max(apparent_age, corrected_age_value);
			unless the cache is confident in the value of the Age header (e.g.,
			because there are no HTTP/1.0 hops in the Via header), in which case
			the corrected_age_value MAY be used as the corrected_initial_age.
	The current_age of a stored response can then be calculated by adding		The current_age of a stored response can then be calculated by adding
	the amount of time (in seconds) since the stored response was last		the amount of time (in seconds) since the stored response was last
	validated by the origin server to the corrected_initial_age.		validated by the origin server to the corrected_initial_age.
	resident_time = now - response_time;		resident_time = now - response_time;
	current_age = corrected_initial_age + resident_time;		current_age = corrected_initial_age + resident_time;
	Additionally, to avoid common problems in date parsing:		Additionally, to avoid common problems in date parsing:
	o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date		o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
	skipping to change at page 31, line 12		skipping to change at page 31, line 12
	warn-date, and that warn-date is different from the Date value in the		warn-date, and that warn-date is different from the Date value in the
	response, then that warning-value MUST be deleted from the message		response, then that warning-value MUST be deleted from the message
	before storing, forwarding, or using it. (preventing the consequences		before storing, forwarding, or using it. (preventing the consequences
	of naive caching of Warning header fields.) If all of the warning-		of naive caching of Warning header fields.) If all of the warning-
	values are deleted for this reason, the Warning header field MUST be		values are deleted for this reason, the Warning header field MUST be
	deleted as well.		deleted as well.
	The following warn-codes are defined by this specification, each with		The following warn-codes are defined by this specification, each with
	a recommended warn-text in English, and a description of its meaning.		a recommended warn-text in English, and a description of its meaning.
	110 Response is stale		3.6.1. 110 Response is Stale
	A cache SHOULD include this whenever the returned response is		A cache SHOULD include this whenever the returned response is stale.
	stale.
	111 Revalidation failed		3.6.2. 111 Revalidation Failed
	A cache SHOULD include this when returning a stale response		A cache SHOULD include this when returning a stale response because
	because an attempt to validate the response failed, due to an		an attempt to validate the response failed, due to an inability to
	inability to reach the server.		reach the server.
	112 Disconnected operation		3.6.3. 112 Disconnected Operation
	A cache SHOULD include this if it is intentionally disconnected		A cache SHOULD include this if it is intentionally disconnected from
	from the rest of the network for a period of time.		the rest of the network for a period of time.
	113 Heuristic expiration		3.6.4. 113 Heuristic Expiration
	A cache SHOULD include this if it heuristically chose a freshness		A cache SHOULD include this if it heuristically chose a freshness
	lifetime greater than 24 hours and the response's age is greater		lifetime greater than 24 hours and the response's age is greater than
	than 24 hours.		24 hours.
	199 Miscellaneous warning		3.6.5. 199 Miscellaneous Warning
	The warning text can include arbitrary information to be presented		The warning text can include arbitrary information to be presented to
	to a human user, or logged. A system receiving this warning MUST		a human user, or logged. A system receiving this warning MUST NOT
	NOT take any automated action, besides presenting the warning to		take any automated action, besides presenting the warning to the
	the user.		user.
	214 Transformation applied		3.6.6. 214 Transformation Applied
	MUST be added by a proxy if it applies any transformation to the		MUST be added by a proxy if it applies any transformation to the
	representation, such as changing the content-coding, media-type,		representation, such as changing the content-coding, media-type, or
	or modifying the representation data, unless this Warning code		modifying the representation data, unless this Warning code already
	already appears in the response.		appears in the response.
	299 Miscellaneous persistent warning		3.6.7. 299 Miscellaneous Persistent Warning
	The warning text can include arbitrary information to be presented		The warning text can include arbitrary information to be presented to
	to a human user, or logged. A system receiving this warning MUST		a human user, or logged. A system receiving this warning MUST NOT
	NOT take any automated action.		take any automated action.
	4. History Lists		3.6.8. Warn Code Extensions
			The HTTP Warn Code Registry defines the name space for warn codes.
			A registration MUST include the following fields:
			o Warn Code (3 digits)
			o Short Description
			o Pointer to specification text
			Values to be added to this name space are subject to IETF review
			([RFC5226], Section 4.1).
			The registry itself is maintained at
			<http://www.iana.org/assignments/http-warn-codes>.
			3.7. History Lists
	User agents often have history mechanisms, such as "Back" buttons and		User agents often have history mechanisms, such as "Back" buttons and
	history lists, that can be used to redisplay a representation		history lists, that can be used to redisplay a representation
	retrieved earlier in a session.		retrieved earlier in a session.
	The freshness model (Section 2.3) does not necessarily apply to		The freshness model (Section 2.3) does not necessarily apply to
	history mechanisms. I.e., a history mechanism can display a previous		history mechanisms. I.e., a history mechanism can display a previous
	representation even if it has expired.		representation even if it has expired.
	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).
	5. IANA Considerations		3.8. IANA Considerations
	5.1. Cache Directive Registry		3.8.1. Cache Directive Registry
	The registration procedure for HTTP Cache Directives is defined by		The registration procedure for HTTP Cache Directives is defined by
	Section 3.2.3 of this document.		Section 3.2.3 of this document.
	The HTTP Cache Directive Registry shall be created at		The HTTP Cache Directive Registry shall be created at
	<http://www.iana.org/assignments/http-cache-directives> and be		<http://www.iana.org/assignments/http-cache-directives> and be
	populated with the registrations below:		populated with the registrations below:
	+------------------------+------------------------------+		+------------------------+------------------------------+
	| Cache Directive | Reference |		| Cache Directive | Reference |
	skipping to change at page 33, line 5		skipping to change at page 33, line 24
	| no-transform | Section 3.2.1, Section 3.2.2 |		| no-transform | Section 3.2.1, Section 3.2.2 |
	| only-if-cached | Section 3.2.1 |		| only-if-cached | Section 3.2.1 |
	| private | Section 3.2.2 |		| private | Section 3.2.2 |
	| proxy-revalidate | Section 3.2.2 |		| proxy-revalidate | Section 3.2.2 |
	| public | Section 3.2.2 |		| public | Section 3.2.2 |
	| s-maxage | Section 3.2.2 |		| s-maxage | Section 3.2.2 |
	| stale-if-error | [RFC5861], Section 4 |		| stale-if-error | [RFC5861], Section 4 |
	| stale-while-revalidate | [RFC5861], Section 3 |		| stale-while-revalidate | [RFC5861], Section 3 |
	+------------------------+------------------------------+		+------------------------+------------------------------+
	5.2. Header Field Registration		3.8.2. Warn Code Registry
			The registration procedure for HTTP Warn Codes is defined by
			Section 3.6.8 of this document.
			The HTTP Warn Code Registry shall be created at
			<http://www.iana.org/assignments/http-cache-directives> and be
			populated with the registrations below:
			+-----------+----------------------------------+---------------+
			| Warn Code | Short Description | Reference |
			+-----------+----------------------------------+---------------+
			| 110 | Response is Stale | Section 3.6.1 |
			| 111 | Revalidation Failed | Section 3.6.2 |
			| 112 | Disconnected Operation | Section 3.6.3 |
			| 113 | Heuristic Expiration | Section 3.6.4 |
			| 199 | Miscellaneous Warning | Section 3.6.5 |
			| 214 | Transformation Applied | Section 3.6.6 |
			| 299 | Miscellaneous Persistent Warning | Section 3.6.7 |
			+-----------+----------------------------------+---------------+
			3.9. Header Field Registration
	The Message Header Field Registry located at <http://www.iana.org/		The Message Header Field Registry located at <http://www.iana.org/
	assignments/message-headers/message-header-index.html> shall be		assignments/message-headers/message-header-index.html> shall be
	updated with the permanent registrations below (see [RFC3864]):		updated with the permanent registrations below (see [RFC3864]):
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Age | http | standard | Section 3.1 |		| Age | http | standard | Section 3.1 |
	| Cache-Control | http | standard | Section 3.2 |		| Cache-Control | http | standard | Section 3.2 |
	| Expires | http | standard | Section 3.3 |		| Expires | http | standard | Section 3.3 |
	| Pragma | http | standard | Section 3.4 |		| Pragma | http | standard | Section 3.4 |
	| Vary | http | standard | Section 3.5 |		| Vary | http | standard | Section 3.5 |
	| Warning | http | standard | Section 3.6 |		| Warning | http | standard | Section 3.6 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	6. Security Considerations		4. Security Considerations
	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.
	7. Acknowledgments		5. Acknowledgments
	See Section 11 of [Part1].		See Section 11 of [Part1].
	8. References		6. References
	8.1. Normative References		6.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-17		and Message Parsing", draft-ietf-httpbis-p1-messaging-18
	(work in progress), October 2011.		(work in progress), January 2012.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 2: Message		and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-17 (work in		Semantics", draft-ietf-httpbis-p2-semantics-18 (work in
	progress), October 2011.		progress), January 2012.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-17 (work in		Requests", draft-ietf-httpbis-p4-conditional-18 (work in
	progress), October 2011.		progress), January 2012.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-17 (work		Partial Responses", draft-ietf-httpbis-p5-range-18 (work
	in progress), October 2011.		in progress), January 2012.
	[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",		and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
	draft-ietf-httpbis-p7-auth-17 (work in progress),		draft-ietf-httpbis-p7-auth-18 (work in progress),
	October 2011.		January 2012.
	[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.
	8.2. Informative References		6.2. Informative References
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation", RFC 1305, March 1992.		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.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] 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,
	skipping to change at page 42, line 22		skipping to change at page 43, line 15
	C.18. Since draft-ietf-httpbis-p6-cache-16		C.18. Since draft-ietf-httpbis-p6-cache-16
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document		o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
	HTTP's error-handling philosophy"		HTTP's error-handling philosophy"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/317>: "Cache-Control		o <http://tools.ietf.org/wg/httpbis/trac/ticket/317>: "Cache-Control
	directive case sensitivity"		directive case sensitivity"
			C.19. Since draft-ietf-httpbis-p6-cache-17
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/293>: "Interaction
			of request and response Cache-Control"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/212>: "Refining age
			for 1.1 proxy chains"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/274>: "warn-code
			registry"
	Index		Index
			1
			110 Response is Stale (warn code) 31
			111 Revalidation Failed (warn code) 31
			112 Disconnected Operation (warn code) 31
			113 Heuristic Expiration (warn code) 31
			199 Miscellaneous Warning (warn code) 31
			2
			214 Transformation Applied (warn code) 31
			299 Miscellaneous Persistent Warning (warn code) 31
	A		A
	age 6		age 6
	Age header field 20		Age header field 20
	C		C
	cache 5		cache 5
	Cache Directives		Cache Directives
	max-age 22, 25		max-age 22, 25
	max-stale 22		max-stale 22
	min-fresh 22		min-fresh 22
	must-revalidate 25		must-revalidate 25
	no-cache 21, 24		no-cache 22, 24
	no-store 22, 24		no-store 22, 24
	no-transform 23, 25		no-transform 23, 25
	only-if-cached 23		only-if-cached 23
	private 23		private 23
	proxy-revalidate 25		proxy-revalidate 25
	public 23		public 23
	s-maxage 25		s-maxage 25
	cache entry 8		cache entry 8
	cache key 8		cache key 8
	Cache-Control header field 21		Cache-Control header field 21
	skipping to change at page 43, line 50		skipping to change at page 45, line 19
	Cache Directive 22, 25		Cache Directive 22, 25
	max-stale		max-stale
	Cache Directive 22		Cache Directive 22
	min-fresh		min-fresh
	Cache Directive 22		Cache Directive 22
	must-revalidate		must-revalidate
	Cache Directive 25		Cache Directive 25
	N		N
	no-cache		no-cache
	Cache Directive 21, 24		Cache Directive 22, 24
	no-store		no-store
	Cache Directive 22, 24		Cache Directive 22, 24
	no-transform		no-transform
	Cache Directive 23, 25		Cache Directive 23, 25
	O		O
	only-if-cached		only-if-cached
	Cache Directive 23		Cache Directive 23
	P		P
	skipping to change at page 44, line 35		skipping to change at page 46, line 4
	shared cache 5		shared cache 5
	stale 6		stale 6
	strong validator 7		strong validator 7
	V		V
	validator 6		validator 6
	strong 7		strong 7
	Vary header field 28		Vary header field 28
	W		W
			Warn Codes
			110 Response is Stale 31
			111 Revalidation Failed 31
			112 Disconnected Operation 31
			113 Heuristic Expiration 31
			199 Miscellaneous Warning 31
			214 Transformation Applied 31
			299 Miscellaneous Persistent Warning 31
	Warning header field 29		Warning header field 29
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
End of changes. 52 change blocks.
	94 lines changed or deleted		183 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/