draft-ietf-httpbis-p6-cache-09.txt		draft-ietf-httpbis-p6-cache-latest.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 One Laptop per Child
	Expires: September 9, 2010 J. Mogul		Expires: September 18, 2010 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		March 17, 2010
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-09		draft-ietf-httpbis-p6-cache-latest
	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/11> 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 to IETF 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), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 23		skipping to change at page 2, line 23
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.		This Internet-Draft will expire on September 18, 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
	skipping to change at page 3, line 24		skipping to change at page 3, line 24
	Specification . . . . . . . . . . . . . . . . . . . . 7		Specification . . . . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . 15
	2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15		2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15
	2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16		2.7. 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 . . . . . . . . . . . 18
	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 . . . . . . . . . . . . . . . 22
	3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23		3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23
	3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24		3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25		3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25
	4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28		4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	5.1. Message Header Registration . . . . . . . . . . . . . . . 28		5.1. Message Header Registration . . . . . . . . . . . . . . . 28
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 28		6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 29		8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	8.2. Informative References . . . . . . . . . . . . . . . . . . 30		8.2. Informative References . . . . . . . . . . . . . . . . . . 30
	Appendix A. Compatibility with Previous Versions . . . . . . . . 30		Appendix A. Compatibility with Previous Versions . . . . . . . . 30
	A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 30		A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 30
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 30		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 31
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31
	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) . . . . . . . . . . . . . . . . . . . . 33
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 32		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
	C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 32		C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33
	C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 33		C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34
	C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 33		C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34
	C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34		C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34		C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 34
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 34		C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35
	C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35		C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
	C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35		C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 35
	C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 35		C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 36
			C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 36
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
	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 10, line 14		skipping to change at page 10, line 14
	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 29
	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 19		skipping to change at page 12, line 18
	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 19, line 21		skipping to change at page 19, line 27
	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 29, line 24		skipping to change at page 29, line 42
	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",
	(work in progress), March 2010.		draft-ietf-httpbis-p1-messaging-latest (work in progress),
			March 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-latest (work
	progress), March 2010.		in progress), March 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-latest (work
	progress), March 2010.		in progress), March 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-latest
	in progress), March 2010.		(work in progress), March 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-latest (work in progress),
	March 2010.		March 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
	skipping to change at page 36, line 5		skipping to change at page 36, line 28
	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"
	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 19
	must-revalidate 21		must-revalidate 21
	no-cache 18, 21		no-cache 18, 21
	no-store 18, 21		no-store 19, 21
	no-transform 19, 22		no-transform 19, 22
	only-if-cached 19		only-if-cached 20
	private 20		private 20
	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 23
	explicit expiration time 5		explicit expiration time 5
	skipping to change at page 36, line 48		skipping to change at page 37, line 30
	G		G
	Grammar		Grammar
	Age 17		Age 17
	Age-v 17		Age-v 17
	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 18
	cache-response-directive 20		cache-response-directive 20
	delta-seconds 17		delta-seconds 17
	Expires 23		Expires 24
	Expires-v 23		Expires-v 24
	extension-pragma 24		extension-pragma 24
	Pragma 24		Pragma 24
	pragma-directive 24		pragma-directive 24
	Pragma-v 24		Pragma-v 24
	Vary 25		Vary 25
	Vary-v 25		Vary-v 25
	warn-agent 26		warn-agent 26
	warn-code 26		warn-code 26
	warn-date 26		warn-date 26
	warn-text 26		warn-text 26
	Warning 26		Warning 26
	Warning-v 26		Warning-v 26
	warning-value 26		warning-value 26
	H		H
	Headers		Headers
	Age 17		Age 17
	Cache-Control 18		Cache-Control 18
	Expires 23		Expires 23
	Pragma 24		Pragma 24
	Vary 24		Vary 25
	Warning 25		Warning 25
	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 19
	must-revalidate		must-revalidate
	Cache Directive 21		Cache Directive 21
	N		N
	no-cache		no-cache
	Cache Directive 18, 21		Cache Directive 18, 21
	no-store		no-store
	Cache Directive 18, 21		Cache Directive 19, 21
	no-transform		no-transform
	Cache Directive 19, 22		Cache Directive 19, 22
	O		O
	only-if-cached		only-if-cached
	Cache Directive 19		Cache Directive 20
	P		P
	Pragma header 24		Pragma header 24
	private		private
	Cache Directive 20		Cache Directive 20
	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 25
	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
End of changes. 47 change blocks.
	84 lines changed or deleted		97 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/