draft-ietf-httpbis-p6-cache-09.txt		draft-ietf-httpbis-p6-cache-10.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track Alcatel-Lucent
	Expires: September 9, 2010 J. Mogul		Expires: January 13, 2011 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	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.
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 8, 2010		July 12, 2010
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-09		draft-ietf-httpbis-p6-cache-10
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. This document is Part 6 of the seven-part specification		systems. This document is Part 6 of the seven-part specification
	that defines the protocol referred to as "HTTP/1.1" and, taken		that defines the protocol referred to as "HTTP/1.1" and, taken
	together, obsoletes RFC 2616. Part 6 defines requirements on HTTP		together, obsoletes RFC 2616. Part 6 defines requirements on HTTP
	caches and the associated header fields that control cache behavior		caches and the associated header fields that control cache behavior
	or indicate cacheable response messages.		or indicate cacheable response messages.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	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). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related		at <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.10.		The changes in this draft are summarized in Appendix C.11.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		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."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 13, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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
	described in the BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 3, line 25		skipping to change at page 3, line 18
	2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7		2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7		2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 7
	2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8		2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8
	2.2. Constructing Responses from Caches . . . . . . . . . . . . 9		2.2. Constructing Responses from Caches . . . . . . . . . . . . 9
	2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10		2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10
	2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11		2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11
	2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12		2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12
	2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13		2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
	2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14		2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14
	2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14		2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14
	2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15		2.6. Shared Caching of Authenticated Responses . . . . . . . . 15
	2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16		2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16
			2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 16
	3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17		3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
	3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18		3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18
	3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18		3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19
	3.2.2. Response Cache-Control Directives . . . . . . . . . . 20		3.2.2. Response Cache-Control Directives . . . . . . . . . . 20
	3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22		3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23
	3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23		3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24
	3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24		3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25		3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26
	4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28		4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	5.1. Message Header Registration . . . . . . . . . . . . . . . 28		5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 28		5.2. Message Header Registration . . . . . . . . . . . . . . . 30
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29		6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 29		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	8.2. Informative References . . . . . . . . . . . . . . . . . . 30		8.1. Normative References . . . . . . . . . . . . . . . . . . . 30
	Appendix A. Compatibility with Previous Versions . . . . . . . . 30		8.2. Informative References . . . . . . . . . . . . . . . . . . 31
	A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 30		Appendix A. Compatibility with Previous Versions . . . . . . . . 32
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 30		A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 32
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 32
			Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 32
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 32		publication) . . . . . . . . . . . . . . . . . . . . 34
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 32		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 34
	C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 32		C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 34
	C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 33		C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 35
	C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 33		C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 35
	C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34		C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34		C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 34		C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36
	C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35		C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36
	C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35		C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36
	C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 35		C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36		C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
	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 7, line 4		skipping to change at page 7, line 4
	A cache that is accessible to more than one user. A non-shared		A cache that is accessible to more than one user. A non-shared
	cache is dedicated to a single user.		cache is dedicated to a single user.
	1.3. Requirements		1.3. Requirements
	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].
	An implementation is not compliant if it fails to satisfy one or more		An implementation is not compliant if it fails to satisfy one or more
	of the MUST or REQUIRED level requirements for the protocols it		of the "MUST" or "REQUIRED" level requirements for the protocols it
	implements. An implementation that satisfies all the MUST or		implements. An implementation that satisfies all the "MUST" or
	REQUIRED level and all the SHOULD level requirements for its		"REQUIRED" level and all the "SHOULD" level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the "MUST" level requirements but not all the "SHOULD"
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant".
	1.4. Syntax Notation		1.4. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the ABNF syntax defined in Section 1.2 of
	[Part1] (which extends the syntax defined in [RFC5234] with a list		[Part1] (which extends the syntax defined in [RFC5234] with a list
	rule). Appendix B shows the collected ABNF, with the list rule		rule). Appendix B shows the collected ABNF, with the list rule
	expanded.		expanded.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	skipping to change at page 8, line 17		skipping to change at page 8, line 14
	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 3.2) does not appear		o the "no-store" cache directive (see Section 3.2) does not appear
	in request or response headers, and		in request or response headers, and
	o the "private" cache response directive (see Section 3.2.2 does not		o the "private" cache response directive (see Section 3.2.2 does not
	appear in the response, if the cache is shared, and		appear in the response, if the cache is shared, and
	o the "Authorization" header (see Section 3.1 of [Part7]) does not		o the "Authorization" header (see Section 3.1 of [Part7]) does not
	appear in the request, if the cache is shared (unless the "public"		appear in the request, if the cache is shared, unless the response
	directive is present; see Section 3.2), and		explicitly allows it (see Section 2.6), and
	o the response either:		o the response either:
	* contains an Expires header (see Section 3.3), or		* contains an Expires header (see Section 3.3), or
	* contains a max-age response cache directive (see		* contains a max-age response cache directive (see
	Section 3.2.2), or		Section 3.2.2), or
	* contains a s-maxage response cache directive and the cache is		* contains a s-maxage response cache directive and the cache is
	shared, or		shared, or
	skipping to change at page 9, line 18		skipping to change at page 9, line 14
	status code.		status code.
	A cache that does not support the Range and Content-Range headers		A cache that does not support the Range and Content-Range headers
	MUST NOT store incomplete or partial responses.		MUST NOT store incomplete or partial responses.
	2.2. Constructing Responses from Caches		2.2. Constructing Responses from Caches
	For a presented request, a cache MUST NOT return a stored response,		For a presented request, a cache MUST NOT return a stored response,
	unless:		unless:
	o The presented Request-URI and that of the stored response match		o The presented Effective Request URI (Section 4.3 of [Part1]) and
	([[TODO-Request-URI: Need to find a new term for this, as Part 1		that of the stored response match, and
	doesn't define Request-URI anymore; the new term request-target
	does not work for this. (see
	<http://tools.ietf.org/wg/httpbis/trac/ticket/196>)]]), 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 request-headers nominated by the stored response (if		o selecting request-headers nominated by the stored response (if
	any) match those presented (see Section 2.6), and		any) match those presented (see Section 2.7), and
	o the presented request and stored response are free from directives		o the presented request and stored response are free from directives
	that would prevent its use (see Section 3.2 and Section 3.4), and		that would prevent its use (see Section 3.2 and Section 3.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
	skipping to change at page 10, line 14		skipping to change at page 10, line 8
	having received a corresponding response.		having received a corresponding response.
	Also, note that unsafe requests might invalidate already stored		Also, note that unsafe requests might invalidate already stored
	responses; see Section 2.5.		responses; see Section 2.5.
	Caches MUST use the most recent response (as determined by the Date		Caches MUST use the most recent response (as determined by the Date
	header) when more than one suitable response is stored. They can		header) when more than one suitable response is stored. They can
	also forward a request with "Cache-Control: max-age=0" or "Cache-		also forward a request with "Cache-Control: max-age=0" or "Cache-
	Control: no-cache" to disambiguate which response to use.		Control: no-cache" to disambiguate which response to use.
	[[TODO-header-properties: end-to-end and hop-by-hop headers, non-
	modifiable headers removed; re-spec in p1]]
	2.3. Freshness Model		2.3. Freshness Model
	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 (Section 3.3) or the max-age response cache		either the Expires header (Section 3.3) or the max-age response cache
	directive (Section 3.2.2). Generally, origin servers will assign		directive (Section 3.2.2). Generally, origin servers will assign
	skipping to change at page 11, line 32		skipping to change at page 11, line 22
	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
	present, use its value, or		present, use its value, or
	o If the Expires response header (Section 3.3) is present, use its		o If the Expires response header (Section 3.3) is present, use its
	value minus the value of the Date response header, or		value minus the value of the Date response header, or
	o Otherwise, no explicit expiration time is present in the response,		o Otherwise, no explicit expiration time is present in the response.
	but a heuristic may be used; see Section 2.3.1.1.		A heuristic freshness lifetime might be applicable; see
			Section 2.3.1.1.
	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.
	2.3.1.1. Calculating Heuristic Freshness		2.3.1.1. Calculating Heuristic Freshness
	If no explicit expiration time is present in a stored response that		If no explicit expiration time is present in a stored response that
	has a status code of 200, 203, 206, 300, 301 or 410, a heuristic		has a status code of 200, 203, 206, 300, 301 or 410, a heuristic
	expiration time can be calculated. Heuristics MUST NOT be used for		expiration time can be calculated. Heuristics MUST NOT be used for
	other response status codes.		other response status codes.
	skipping to change at page 12, line 6		skipping to change at page 11, line 46
	When a heuristic is used to calculate freshness lifetime, the cache		When a heuristic is used to calculate freshness lifetime, the cache
	SHOULD attach a Warning header with a 113 warn-code to the response		SHOULD attach a Warning header with a 113 warn-code to the response
	if its current_age is more than 24 hours and such a warning is not		if its current_age is more than 24 hours and such a warning is not
	already present.		already present.
	Also, if the response has a Last-Modified header (Section 6.6 of		Also, if the response has a Last-Modified header (Section 6.6 of
	[Part4]), the heuristic expiration value SHOULD be no more than some		[Part4]), the heuristic expiration value SHOULD be no more than some
	fraction of the interval since that time. A typical setting of this		fraction of the interval since that time. A typical setting of this
	fraction might be 10%.		fraction might be 10%.
	[[REVIEW-query-string-heuristics: took away HTTP/1.0 query string		Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do
	heuristic uncacheability.]]		not calculate heuristic freshness for URLs with query components
			(i.e., those containing '?'). In practice, this has not been
			widely implemented. Therefore, servers are encouraged to send
			explicit directives (e.g., Cache-Control: no-cache) if they wish
			to preclude caching.
	2.3.2. Calculating Age		2.3.2. Calculating Age
	HTTP/1.1 uses the Age response-header to convey the estimated age of		HTTP/1.1 uses the Age response-header to convey the estimated age of
	the response message when obtained from a cache. The Age field value		the response message when obtained from a cache. The Age field value
	is the cache's estimate of the amount of time since the response was		is the cache's estimate of the amount of time since the response was
	generated or validated by the origin server. In essence, the Age		generated or validated by the origin server. In essence, the Age
	value is the sum of the time that the response has been resident in		value is the sum of the time that the response has been resident in
	each of the caches along the path from the origin server, plus the		each of the caches along the path from the origin server, plus the
	amount of time it has been in transit along network paths.		amount of time it has been in transit along network paths.
	The term "age_value" denotes the value of the Age header, in a form		The following data is used for the age calculation:
	appropriate for arithmetic operations.
	HTTP/1.1 requires origin servers to send a Date header, if possible,		age_value
	with every response, giving the time at which the response was
	generated (see Section 9.3 of [Part1]). The term "date_value"
	denotes the value of the Date header, in a form appropriate for
	arithmetic operations.
	The term "now" means "the current value of the clock at the host		The term "age_value" denotes the value of the Age header
	performing the calculation." Hosts that use HTTP, but especially		(Section 3.1), in a form appropriate for arithmetic operation; or
	hosts running origin servers and caches, SHOULD use NTP [RFC1305] or		0, if not available.
	some similar protocol to synchronize their clocks to a globally
	accurate time standard.
	A response's age can be calculated in two entirely independent ways:		date_value
	1. now minus date_value, if the local clock is reasonably well		HTTP/1.1 requires origin servers to send a Date header, if
	synchronized to the origin server's clock. If the result is		possible, with every response, giving the time at which the
	negative, the result is replaced by zero.		response was generated. The term "date_value" denotes the value
			of the Date header, in a form appropriate for arithmetic
			operations. See Section 9.3 of [Part1] for the definition of the
			Date header, and for requirements regarding responses without a
			Date response header.
	2. age_value, if all of the caches along the response path implement		now
	HTTP/1.1.
	These are combined as		The term "now" means "the current value of the clock at the host
			performing the calculation". Hosts that use HTTP, but especially
			hosts running origin servers and caches, SHOULD use NTP
			([RFC1305]) or some similar protocol to synchronize their clocks
			to a globally accurate time standard.
	corrected_received_age = max(now - date_value, age_value)		request_time
	When an Age value is received, it MUST be interpreted relative to the		The current value of the clock at the host at the time the request
	time the request was initiated, not the time that the response was		resulting in the stored response was made.
	received.
	corrected_initial_age = corrected_received_age		response_time
	+ (now - request_time)
	where "request_time" is the time (according to the local clock) when		The current value of the clock at the host at the time the
	the request that elicited this response was sent.		response was received.
	The current_age of a stored response can then be calculated by adding		A response's age can be calculated in two entirely independent ways:
	the amount of time (in seconds) since the stored response was last
	validated by the origin server to the corrected_initial_age.
	In summary:		1. the "apparent_age": response_time minus date_value, if the local
			clock is reasonably well synchronized to the origin server's
			clock. If the result is negative, the result is replaced by
			zero.
	age_value - Age header field-value received with the response		2. the "corrected_age_value", if all of the caches along the
	date_value - Date header field-value received with the response		response path implement HTTP/1.1; note this value MUST be
	request_time - local time when the cache made the request		interpreted relative to the time the request was initiated, not
	resulting in the stored response		the time that the response was received.
	response_time - local time when the cache received the response
	now - current local time
	apparent_age = max(0, response_time - date_value);		apparent_age = max(0, response_time - date_value);
	corrected_received_age = max(apparent_age, age_value);
	response_delay = response_time - request_time;		response_delay = response_time - request_time;
	corrected_initial_age = corrected_received_age + response_delay;		corrected_age_value = age_value + response_delay;
			These are combined as
			corrected_initial_age = max(apparent_age, corrected_age_value);
			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
			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;
	2.3.3. Serving Stale Responses		2.3.3. Serving Stale Responses
	A "stale" response is one that either has explicit expiry		A "stale" response is one that either has explicit expiry information
	information, or is allowed to have heuristic expiry calculated, but		or is allowed to have heuristic expiry calculated, but is not fresh
	is not fresh according to the calculations in Section 2.3.		according to the calculations in Section 2.3.
	Caches MUST NOT return a stale response if it is prohibited by an		Caches MUST NOT return a stale response if it is prohibited by an
	explicit in-protocol directive (e.g., by a "no-store" or "no-cache"		explicit in-protocol directive (e.g., by a "no-store" or "no-cache"
	cache directive, a "must-revalidate" cache-response-directive, or an		cache directive, a "must-revalidate" cache-response-directive, or an
	applicable "s-maxage" or "proxy-revalidate" cache-response-directive;		applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
	see Section 3.2.2).		see Section 3.2.2).
	Caches SHOULD NOT return stale responses unless they are disconnected		Caches SHOULD NOT return stale responses unless they are disconnected
	(i.e., it cannot contact the origin server or otherwise find a		(i.e., it cannot contact the origin server or otherwise find a
	forward path) or otherwise explicitly allowed (e.g., the max-stale		forward path) or otherwise explicitly allowed (e.g., the max-stale
	skipping to change at page 14, line 14		skipping to change at page 14, line 17
	the requesting client, and the received response is no longer fresh,		the requesting client, and the received response is no longer fresh,
	the cache SHOULD forward it to the requesting client without adding a		the cache SHOULD forward it to the requesting client without adding a
	new Warning (but without removing any existing Warning headers). A		new Warning (but without removing any existing Warning headers). A
	cache SHOULD NOT attempt to validate a response simply because that		cache SHOULD NOT attempt to validate a response simply because that
	response became stale in transit.		response became stale in transit.
	2.4. Validation Model		2.4. Validation Model
	When a cache has one or more stored responses for a requested URI,		When a cache has one or more stored responses for a requested URI,
	but cannot serve any of them (e.g., because they are not fresh, or		but cannot serve any of them (e.g., because they are not fresh, or
	one cannot be selected; see Section 2.6), it can use the conditional		one cannot be selected; see Section 2.7), it can use the conditional
	request mechanism [Part4] in the forwarded request to give the origin		request mechanism [Part4] in the forwarded request to give the origin
	server an opportunity to both select a valid stored response to be		server an opportunity to both select a valid stored response to be
	used, and to update it. This process is known as "validating" or		used, and to update it. This process is known as "validating" or
	"revalidating" the stored response.		"revalidating" the stored response.
	When sending such a conditional request, the cache SHOULD add an If-		When sending such a conditional request, the cache SHOULD add an If-
	Modified-Since header whose value is that of the Last-Modified header		Modified-Since header whose value is that of the Last-Modified header
	from the selected (see Section 2.6) stored response, if available.		from the selected (see Section 2.7) stored response, if available.
	Additionally, the cache SHOULD add an If-None-Match header whose		Additionally, the cache SHOULD add an If-None-Match header whose
	value is that of the ETag header(s) from all responses stored for the		value is that of the ETag header(s) from all responses stored for the
	requested URI, if present. However, if any of the stored responses		requested URI, if present. However, if any of the stored responses
	contains only partial content, its entity-tag SHOULD NOT be included		contains only partial content, its entity-tag SHOULD NOT be included
	in the If-None-Match header field unless the request is for a range		in the If-None-Match header field unless the request is for a range
	that would be fully satisfied by that stored response.		that would be fully satisfied by that stored response.
	A 304 (Not Modified) response status code indicates that the stored		A 304 (Not Modified) response status code indicates that the stored
	response can be updated and reused; see Section 2.7.		response can be updated and reused; see Section 2.8.
	A full response (i.e., one with a response body) indicates that none		A full response (i.e., one with a response body) indicates that none
	of the stored responses nominated in the conditional request is		of the stored responses nominated in the conditional request is
	suitable. Instead, the full response is used both to satisfy the		suitable. Instead, the full response is used both to satisfy the
	request and replace the stored response. [[TODO-req-missing: Should		request and replace the stored response. [[TODO-req-missing: Should
	there be a requirement here?]]		there be a requirement here?]]
	If a cache receives a 5xx response while attempting to validate a		If a cache receives a 5xx response while attempting to validate a
	response, it MAY either forward this response to the requesting		response, it MAY either forward this response to the requesting
	client, or act as if the server failed to respond. In the latter		client, or act as if the server failed to respond. In the latter
	case, it MAY return a previously stored response (see Section 2.3.3).		case, it MAY return a previously stored response (see Section 2.3.3).
	2.5. Request Methods that Invalidate		2.5. Request Methods that Invalidate
	Because unsafe methods (Section 7.1.1 of [Part2]) have the potential		Because unsafe methods (Section 7.1.1 of [Part2]) have the potential
	for changing state on the origin server, intervening caches can use		for changing state on the origin server, intervening caches can use
	them to keep their contents up-to-date.		them to keep their contents up-to-date.
	The following HTTP methods MUST cause a cache to invalidate the		The following HTTP methods MUST cause a cache to invalidate the
	Request-URI as well as the URI(s) in the Location and Content-		Effective Request URI (Section 4.3 of [Part1]) as well as the URI(s)
	Location headers (if present):		in the Location and Content-Location headers (if present):
	o PUT		o PUT
	o DELETE		o DELETE
	o POST		o POST
	An invalidation based on a URI from a Location or Content-Location		An invalidation based on a URI from a Location or Content-Location
	header MUST NOT be performed if the host part of that URI differs		header MUST NOT be performed if the host part of that URI differs
	from the host part in the Request-URI. This helps prevent denial of		from the host part in the Effective Request URI (Section 4.3 of
	service attacks.		[Part1]). This helps prevent denial of service attacks.
	[[TODO-def-host-part: "host part" needs to be specified better.]]		[[TODO-def-host-part: "host part" needs to be specified better.]]
	A cache that passes through requests for methods it does not		A cache that passes through requests for methods it does not
	understand SHOULD invalidate the Request-URI.		understand SHOULD invalidate the Effective Request URI (Section 4.3
			of [Part1]).
	Here, "invalidate" means that the cache will either remove all stored		Here, "invalidate" means that the cache will either remove all stored
	responses related to the Request-URI, or will mark these as "invalid"		responses related to the Effective Request URI, or will mark these as
	and in need of a mandatory validation before they can be returned in		"invalid" and in need of a mandatory validation before they can be
	response to a subsequent request.		returned in response to a subsequent request.
	Note that this does not guarantee that all appropriate responses are		Note that this does not guarantee that all appropriate responses are
	invalidated. For example, the request that caused the change at the		invalidated. For example, the request that caused the change at the
	origin server might not have gone through the cache where a response		origin server might not have gone through the cache where a response
	is stored.		is stored.
	[[TODO-spec-success-invalidate: specify that only successful (2xx,		[[TODO-spec-success-invalidate: specify that only successful (2xx,
	3xx?) responses invalidate.]]		3xx?) responses invalidate.]]
	2.6. Caching Negotiated Responses		2.6. Shared Caching of Authenticated Responses
			Shared caches MUST NOT use a cached response to a request with an
			Authorization header (Section 3.1 of [Part7]) to satisfy any
			subsequent request unless a cache directive that allows such
			responses to be stored is present in the response.
			In this specification, the following Cache-Control response
			directives (Section 3.2.2) have such an effect: must-revalidate,
			public, s-maxage.
			Note that cached responses that contain the "must-revalidate" and/or
			"s-maxage" response directives are not allowed to be served stale
			(Section 2.3.3) by shared caches. In particular, a response with
			either "max-age=0, must-revalidate" or "s-maxage=0" cannot be used to
			satisfy a subsequent request without revalidating it on the origin
			server.
			2.7. Caching Negotiated Responses
	When a cache receives a request that can be satisfied by a stored		When a cache receives a request that can be satisfied by a stored
	response that has a Vary header field (Section 3.5), it MUST NOT use		response that has a Vary header field (Section 3.5), it MUST NOT use
	that response unless all of the selecting request-headers nominated		that response unless all of the selecting request-headers nominated
	by the Vary header match in both the original request (i.e., that		by the Vary header match in both the original request (i.e., that
	associated with the stored response), and the presented request.		associated with the stored response), and the presented request.
	The selecting request-headers from two requests are defined to match		The selecting request-headers from two requests are defined to match
	if and only if those in the first request can be transformed to those		if and only if those in the first request can be transformed to those
	in the second request by applying any of the following:		in the second request by applying any of the following:
	skipping to change at page 16, line 29		skipping to change at page 16, line 47
	subsequent requests to that resource can only be properly interpreted		subsequent requests to that resource can only be properly interpreted
	by the origin server.		by the origin server.
	The stored response with matching selecting request-headers is known		The stored response with matching selecting request-headers is known
	as the selected response.		as the selected response.
	If no selected response is available, the cache MAY forward the		If no selected response is available, the cache MAY forward the
	presented request to the origin server in a conditional request; see		presented request to the origin server in a conditional request; see
	Section 2.4.		Section 2.4.
	2.7. Combining Responses		2.8. Combining Responses
	When a cache receives a 304 (Not Modified) response or a 206 (Partial		When a cache receives a 304 (Not Modified) response or a 206 (Partial
	Content) response (in this section, the "new" response"), it needs to		Content) response (in this section, the "new" response"), it needs to
	created an updated response by combining the stored response with the		created an updated response by combining the stored response with the
	new one, so that the updated response can be used to satisfy the		new one, so that the updated response can be used to satisfy the
	request.		request.
	If the new response contains an ETag, it identifies the stored		If the new response contains an ETag, it identifies the stored
	response to use. [[TODO-mention-CL: may need language about Content-		response to use. [[TODO-mention-CL: may need language about Content-
	Location here]][[TODO-inm-mult-etags: cover case where INM with		Location here]][[TODO-inm-mult-etags: cover case where INM with
	skipping to change at page 18, line 9		skipping to change at page 18, line 27
	MUST transmit an Age header with a field-value of 2147483648 (2^31).		MUST transmit an Age header with a field-value of 2147483648 (2^31).
	Caches SHOULD use an arithmetic type of at least 31 bits of range.		Caches SHOULD use an arithmetic type of at least 31 bits of range.
	The presence of an Age header field in a response implies that a		The presence of an Age header field in a response implies that a
	response is not first-hand. However, the converse is not true, since		response is not first-hand. However, the converse is not true, since
	HTTP/1.0 caches may not implement the Age header field.		HTTP/1.0 caches may not implement the Age header field.
	3.2. Cache-Control		3.2. Cache-Control
	The "Cache-Control" general-header field is used to specify		The "Cache-Control" general-header field is used to specify
	directives that MUST be obeyed by all caches along the request/		directives for caches along the request/response chain. Such cache
	response chain. Such cache directives are unidirectional in that the		directives are unidirectional in that the presence of a directive in
	presence of a directive in a request does not imply that the same		a request does not imply that the same directive is to be given in
	directive is to be given in the response.		the response.
	Note that HTTP/1.0 caches might not implement Cache-Control and		HTTP/1.1 caches MUST obey the requirements of the Cache-Control
	might only implement Pragma: no-cache (see Section 3.4).		directives defined in this section. See Section 3.2.3 for
			information about how Cache-Control directives defined elsewhere are
			handled.
			Note: HTTP/1.0 caches might not implement Cache-Control and might
			only implement Pragma: no-cache (see Section 3.4).
	Cache directives MUST be passed through by a proxy or gateway		Cache directives MUST be passed through by a proxy or gateway
	application, regardless of their significance to that application,		application, regardless of their significance to that application,
	since the directives might be applicable to all recipients along the		since the directives might be applicable to all recipients along the
	request/response chain. It is not possible to target a directive to		request/response chain. It is not possible to target a directive to
	a specific cache.		a specific cache.
	Cache-Control = "Cache-Control" ":" OWS Cache-Control-v		Cache-Control = "Cache-Control" ":" OWS Cache-Control-v
	Cache-Control-v = 1#cache-directive		Cache-Control-v = 1#cache-directive
	skipping to change at page 19, line 21		skipping to change at page 19, line 44
	This directive is NOT a reliable or sufficient mechanism for		This directive is NOT a reliable or sufficient mechanism for
	ensuring privacy. In particular, malicious or compromised caches		ensuring privacy. In particular, malicious or compromised caches
	might not recognize or obey this directive, and communications		might not recognize or obey this directive, and communications
	networks may be vulnerable to eavesdropping.		networks may be vulnerable to eavesdropping.
	max-age		max-age
	The max-age request directive indicates that the client is willing		The max-age request directive indicates that the client is willing
	to accept a response whose age is no greater than the specified		to accept a response whose age is no greater than the specified
	time in seconds. Unless max-stale directive is also included, the		time in seconds. Unless the max-stale request directive is also
	client is not willing to accept a stale response.		present, the client is not willing to accept a stale response.
	max-stale		max-stale
	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 expiration		willing to accept a response that has exceeded its expiration
	time. If max-stale is assigned a value, then the client is		time. If max-stale is assigned a value, then the client is
	willing to accept a response that has exceeded its expiration time		willing to accept a response that has exceeded its expiration time
	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		assigned to max-stale, then the client is willing to accept a
	stale response of any age. [[TODO-staleness: of any staleness?		stale response of any age. [[TODO-staleness: of any staleness?
	skipping to change at page 23, line 31		skipping to change at page 24, line 8
	does not understand the community cache-extension, since it will also		does not understand the community cache-extension, since it will also
	see and understand the private directive and thus default to the safe		see and understand the private directive and thus default to the safe
	behavior.		behavior.
	Unrecognized cache directives MUST be ignored; it is assumed that any		Unrecognized cache directives MUST be ignored; it is assumed that any
	cache directive likely to be unrecognized by an HTTP/1.1 cache will		cache directive likely to be unrecognized by an HTTP/1.1 cache will
	be combined with standard directives (or the response's default		be combined with standard directives (or the response's default
	cacheability) such that the cache behavior will remain minimally		cacheability) such that the cache behavior will remain minimally
	correct even if the cache does not understand the extension(s).		correct even if the cache does not understand the extension(s).
			The HTTP Cache Directive Registry defines the name space for the
			cache directives.
			Registrations MUST include the following fields:
			o Cache Directive Name
			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-cache-directives>.
	3.3. Expires		3.3. Expires
	The "Expires" entity-header field gives the date/time after which the		The "Expires" entity-header field gives the date/time after which the
	response is considered stale. See Section 2.3 for further discussion		response is considered stale. See Section 2.3 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 25, line 4		skipping to change at page 25, line 43
	This mechanism is deprecated; no new Pragma directives will be		This mechanism is deprecated; no new Pragma directives will be
	defined in HTTP.		defined in HTTP.
	3.5. Vary		3.5. Vary
	The "Vary" response-header field conveys the set of request-header		The "Vary" response-header field conveys the set of request-header
	fields that were used to select the representation.		fields that were used to select the representation.
	Caches use this information, in part, to determine whether a stored		Caches use this information, in part, to determine whether a stored
	response can be used to satisfy a given request; see Section 2.6.		response can be used to satisfy a given request; see Section 2.7.
	determines, while the response is fresh, whether a cache is permitted		determines, while the response is fresh, whether a cache is permitted
	to use the response to reply to a subsequent request without		to use the response to reply to a subsequent request without
	validation; see Section 2.6.		validation; see Section 2.7.
	In uncacheable or stale responses, the Vary field value advises the		In uncacheable or stale responses, the Vary field value advises the
	user agent about the criteria that were used to select the		user agent about the criteria that were used to select the
	representation.		representation.
	Vary = "Vary" ":" OWS Vary-v		Vary = "Vary" ":" OWS Vary-v
	Vary-v = "*" / 1#field-name		Vary-v = "*" / 1#field-name
	The set of header fields named by the Vary field value is known as		The set of header fields named by the Vary field value is known as
	the selecting request-headers.		the selecting request-headers.
	skipping to change at page 28, line 27		skipping to change at page 29, line 22
	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		5. IANA Considerations
	5.1. Message Header Registration		5.1. Cache Directive Registry
			The registration procedure for HTTP Cache Directives is defined by
			Section 3.2.3 of this document.
			The HTTP Cache Directive Registry should be created at
			<http://www.iana.org/assignments/http-cache-directives> and be
			populated with the registrations below:
			+------------------------+------------------------------+
			| Cache Directive | Reference |
			+------------------------+------------------------------+
			| max-age | Section 3.2.1, Section 3.2.2 |
			| max-stale | Section 3.2.1 |
			| min-fresh | Section 3.2.1 |
			| must-revalidate | Section 3.2.2 |
			| no-cache | Section 3.2.1, Section 3.2.2 |
			| no-store | 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 |
			| private | Section 3.2.2 |
			| proxy-revalidate | Section 3.2.2 |
			| public | Section 3.2.2 |
			| s-maxage | Section 3.2.2 |
			| stale-if-error | [RFC5861], Section 4 |
			| stale-while-revalidate | [RFC5861], Section 3 |
			+------------------------+------------------------------+
			5.2. Message Header Registration
	The Message Header Registry located at <http://www.iana.org/		The Message Header Registry located at <http://www.iana.org/
	assignments/message-headers/message-header-index.html> should be		assignments/message-headers/message-header-index.html> should 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 |
	skipping to change at page 29, line 24		skipping to change at page 30, line 48
	suggestions and comments from individuals including: Shel Kaphan,		suggestions and comments from individuals including: Shel Kaphan,
	Paul Leach, Koen Holtman, David Morris, and Larry Masinter.		Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
	8. References		8. References
	8.1. Normative References		8.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-09		and Message Parsing", draft-ietf-httpbis-p1-messaging-10
	(work in progress), March 2010.		(work in progress), July 2010.
	[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-09 (work in		Semantics", draft-ietf-httpbis-p2-semantics-10 (work in
	progress), March 2010.		progress), July 2010.
	[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-09 (work in		Requests", draft-ietf-httpbis-p4-conditional-10 (work in
	progress), March 2010.		progress), July 2010.
	[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-09 (work		Partial Responses", draft-ietf-httpbis-p5-range-10 (work
	in progress), March 2010.		in progress), July 2010.
	[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-09 (work in progress),		draft-ietf-httpbis-p7-auth-10 (work in progress),
	March 2010.		July 2010.
	[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		8.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,
	September 2004.		September 2004.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
			[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
			Content", RFC 5861, April 2010.
	Appendix A. Compatibility with Previous Versions		Appendix A. Compatibility with Previous Versions
	A.1. Changes from RFC 2068		A.1. Changes from RFC 2068
	A case was missed in the Cache-Control model of HTTP/1.1; s-maxage		A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
	was introduced to add this missing case. (Sections 2.1, 3.2).		was introduced to add this missing case. (Sections 2.1, 3.2).
	Range request responses would become very verbose if all meta-data		Range request responses would become very verbose if all meta-data
	were always returned; by allowing the server to only send needed		were always returned; by allowing the server to only send needed
	headers in a 206 response, this problem can be avoided.		headers in a 206 response, this problem can be avoided.
	(Section 2.7)		(Section 2.8)
	The Cache-Control: max-age directive was not properly defined for		The Cache-Control: max-age directive was not properly defined for
	responses. (Section 3.2.2)		responses. (Section 3.2.2)
	Warnings could be cached incorrectly, or not updated appropriately.		Warnings could be cached incorrectly, or not updated appropriately.
	(Section 2.3, 2.7, 3.2, and 3.6) Warning also needed to be a general		(Section 2.3, 2.8, 3.2, and 3.6) Warning also needed to be a general
	header, as PUT or other methods may have need for it in requests.		header, as PUT or other methods may have need for it in requests.
	A.2. Changes from RFC 2616		A.2. Changes from RFC 2616
			Make the specified age calculation algorithm less conservative.
			(Section 2.3.2)
	Remove requirement to consider Content-Location in successful		Remove requirement to consider Content-Location in successful
	responses in order to determine the appropriate response to use.		responses in order to determine the appropriate response to use.
	(Section 2.4)		(Section 2.4)
	Clarify denial of service attack avoidance requirement.		Clarify denial of service attack avoidance requirement.
	(Section 2.5)		(Section 2.5)
	Do not mention RFC 2047 encoding and multiple languages in Warning		Do not mention RFC 2047 encoding and multiple languages in Warning
	headers anymore, as these aspects never were implemented.		headers anymore, as these aspects never were implemented.
	(Section 3.6)		(Section 3.6)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	Age = "Age:" OWS Age-v		Age = "Age:" OWS Age-v
	Age-v = delta-seconds		Age-v = delta-seconds
	Cache-Control = "Cache-Control:" OWS Cache-Control-v		Cache-Control = "Cache-Control:" OWS Cache-Control-v
	skipping to change at page 34, line 34		skipping to change at page 36, line 17
	C.7. Since draft-ietf-httpbis-p6-cache-05		C.7. Since draft-ietf-httpbis-p6-cache-05
	This is a total rewrite of this part of the specification.		This is a total rewrite of this part of the specification.
	Affected issues:		Affected issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of		o <http://tools.ietf.org/wg/httpbis/trac/ticket/54>: "Definition of
	1xx Warn-Codes"		1xx Warn-Codes"
	o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement		o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
	of 13.5.1 and 13.5.2"		13.5.1 and 13.5.2"
	o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/138>: "The role		o <http://tools.ietf.org/wg/httpbis/trac/ticket/138>: "The role of
	of Warning and Semantic Transparency in Caching"		Warning and Semantic Transparency in Caching"
	o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods		o <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and
	and Caching"		Caching"
	In addition: Final work on ABNF conversion		In addition: Final work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Add appendix containing collected and expanded ABNF, reorganize		o Add appendix containing collected and expanded ABNF, reorganize
	ABNF introduction.		ABNF introduction.
	C.8. Since draft-ietf-httpbis-p6-cache-06		C.8. Since draft-ietf-httpbis-p6-cache-06
	Closed issues:		Closed issues:
	skipping to change at page 36, line 5		skipping to change at page 37, line 31
	Affected issues:		Affected issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes		o <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: Status codes
	and caching		and caching
	Partly resolved issues:		Partly resolved issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of		o <http://tools.ietf.org/wg/httpbis/trac/ticket/60>: "Placement of
	13.5.1 and 13.5.2"		13.5.1 and 13.5.2"
			C.11. Since draft-ietf-httpbis-p6-cache-09
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/29>: "Age
			calculation"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/168>: "Clarify
			differences between / requirements for request and response CC
			directives"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/174>: "Caching
			authenticated responses"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/208>: "IANA registry
			for cache-control directives"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/211>: "Heuristic
			caching of URLs with query components"
			Partly resolved issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
			requested resource's URI"
	Index		Index
	A		A
	age 6		age 6
	Age header 17		Age header 17
	C		C
	cache 5		cache 5
	Cache Directives		Cache Directives
	max-age 19, 22		max-age 19, 22
	max-stale 19		max-stale 19
	min-fresh 19		min-fresh 20
	must-revalidate 21		must-revalidate 22
	no-cache 18, 21		no-cache 19, 21
	no-store 18, 21		no-store 19, 22
	no-transform 19, 22		no-transform 20, 23
	only-if-cached 19		only-if-cached 20
	private 20		private 21
	proxy-revalidate 22		proxy-revalidate 22
	public 20		public 20
	s-maxage 22		s-maxage 22
	Cache-Control header 18		Cache-Control header 18
	cacheable 5		cacheable 5
	E		E
	Expires header 23		Expires header 24
	explicit expiration time 5		explicit expiration time 5
	F		F
	first-hand 6		first-hand 6
	fresh 6		fresh 6
	freshness lifetime 6		freshness lifetime 6
	G		G
	Grammar		Grammar
	Age 17		Age 18
	Age-v 17		Age-v 18
	Cache-Control 18		Cache-Control 18
	Cache-Control-v 18		Cache-Control-v 18
	cache-extension 18		cache-extension 18
	cache-request-directive 18		cache-request-directive 19
	cache-response-directive 20		cache-response-directive 20
	delta-seconds 17		delta-seconds 18
	Expires 23		Expires 24
	Expires-v 23		Expires-v 24
	extension-pragma 24		extension-pragma 25
	Pragma 24		Pragma 25
	pragma-directive 24		pragma-directive 25
	Pragma-v 24		Pragma-v 25
	Vary 25		Vary 26
	Vary-v 25		Vary-v 26
	warn-agent 26		warn-agent 27
	warn-code 26		warn-code 27
	warn-date 26		warn-date 27
	warn-text 26		warn-text 27
	Warning 26		Warning 27
	Warning-v 26		Warning-v 27
	warning-value 26		warning-value 27
	H		H
	Headers		Headers
	Age 17		Age 17
	Cache-Control 18		Cache-Control 18
	Expires 23		Expires 24
	Pragma 24		Pragma 25
	Vary 24		Vary 25
	Warning 25		Warning 26
	heuristic expiration time 5		heuristic expiration time 5
	M		M
	max-age		max-age
	Cache Directive 19, 22		Cache Directive 19, 22
	max-stale		max-stale
	Cache Directive 19		Cache Directive 19
	min-fresh		min-fresh
	Cache Directive 19		Cache Directive 20
	must-revalidate		must-revalidate
	Cache Directive 21		Cache Directive 22
	N		N
	no-cache		no-cache
	Cache Directive 18, 21		Cache Directive 19, 21
	no-store		no-store
	Cache Directive 18, 21
	no-transform
	Cache Directive 19, 22		Cache Directive 19, 22
			no-transform
			Cache Directive 20, 23
	O		O
	only-if-cached		only-if-cached
	Cache Directive 19		Cache Directive 20
	P		P
	Pragma header 24		Pragma header 25
	private		private
	Cache Directive 20		Cache Directive 21
	proxy-revalidate		proxy-revalidate
	Cache Directive 22		Cache Directive 22
	public		public
	Cache Directive 20		Cache Directive 20
	S		S
	s-maxage		s-maxage
	Cache Directive 22		Cache Directive 22
	stale 6		stale 6
	V		V
	validator 6		validator 6
	Vary header 24		Vary header 25
	W		W
	Warning header 25		Warning header 26
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
	Fax: +1-949-706-5305		Fax: +1-949-706-5305
	Email: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Jim Gettys		Jim Gettys
	One Laptop per Child		Alcatel-Lucent Bell Labs
	21 Oak Knoll Road		21 Oak Knoll Road
	Carlisle, MA 01741		Carlisle, MA 01741
	USA		USA
	Email: jg@laptop.org		EMail: jg@freedesktop.org
	URI: http://www.laptop.org/		URI: http://gettys.wordpress.com/
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Hewlett-Packard Company		Hewlett-Packard Company
	HP Labs, Large Scale Systems Group		HP Labs, Large Scale Systems Group
	1501 Page Mill Road, MS 1177		1501 Page Mill Road, MS 1177
	Palo Alto, CA 94304		Palo Alto, CA 94304
	USA		USA
	Email: JeffMogul@acm.org		EMail: JeffMogul@acm.org
	Henrik Frystyk Nielsen		Henrik Frystyk Nielsen
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Email: henrikn@microsoft.com		EMail: henrikn@microsoft.com
	Larry Masinter		Larry Masinter
	Adobe Systems, Incorporated		Adobe Systems, Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	Email: LMM@acm.org		EMail: LMM@acm.org
	URI: http://larry.masinter.net/		URI: http://larry.masinter.net/
	Paul J. Leach		Paul J. Leach
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Email: paulle@microsoft.com		EMail: paulle@microsoft.com
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory		MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32		The Stata Center, Building 32
	32 Vassar Street		32 Vassar Street
	Cambridge, MA 02139		Cambridge, MA 02139
	USA		USA
	Email: timbl@w3.org		EMail: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/		URI: http://www.w3.org/People/Berners-Lee/
	Yves Lafon (editor)		Yves Lafon (editor)
	World Wide Web Consortium		World Wide Web Consortium
	W3C / ERCIM		W3C / ERCIM
	2004, rte des Lucioles		2004, rte des Lucioles
	Sophia-Antipolis, AM 06902		Sophia-Antipolis, AM 06902
	France		France
	Email: ylafon@w3.org		EMail: ylafon@w3.org
	URI: http://www.raubacapeu.net/people/yves/		URI: http://www.raubacapeu.net/people/yves/
	Mark Nottingham (editor)		Mark Nottingham (editor)
	Email: mnot@mnot.net		EMail: mnot@mnot.net
	URI: http://www.mnot.net/		URI: http://www.mnot.net/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
	Phone: +49 251 2807760		Phone: +49 251 2807760
	Fax: +49 251 2807761		Fax: +49 251 2807761
	Email: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
End of changes. 97 change blocks.
	210 lines changed or deleted		314 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/