draft-ietf-httpbis-p6-cache-14.txt		draft-ietf-httpbis-p6-cache-15.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: October 20, 2011 J. Mogul		Expires: January 12, 2012 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	M. Nottingham, Ed.		M. Nottingham, Ed.
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	April 18, 2011		July 11, 2011
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-14		draft-ietf-httpbis-p6-cache-15
	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.
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org), which is archived at		group mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.15.		The changes in this draft are summarized in Appendix C.16.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 20, 2011.		This Internet-Draft will expire on January 12, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 10		skipping to change at page 3, line 10
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7		1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
	1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7		1.4. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
	1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7		1.4.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
	1.4.2. ABNF Rules defined in other Parts of the		1.4.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 7		Specification . . . . . . . . . . . . . . . . . . . . 7
			1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
	2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8		2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 8		2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 8
	2.1.1. Storing Partial and Incomplete Responses . . . . . . . 9		2.1.1. Storing Partial and Incomplete Responses . . . . . . . 9
	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 . . . . . . . . . . . . . . . 14
	2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14		2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14
	2.5. Request Methods that Invalidate . . . . . . . . . . . . . 15		2.5. Request Methods that Invalidate . . . . . . . . . . . . . 15
	2.6. Shared Caching of Authenticated Responses . . . . . . . . 15		2.6. Shared Caching of Authenticated Responses . . . . . . . . 16
	2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16		2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16
	2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 17		2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 17
	3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17		3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 18
	3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18		3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18
	3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19		3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19
	3.2.2. Response Cache-Control Directives . . . . . . . . . . 21		3.2.2. Response Cache-Control Directives . . . . . . . . . . 21
	3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23		3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23
	3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24		3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24
	3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25		3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 26		3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 27
	4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29		4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29		5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29
	5.2. Header Field Registration . . . . . . . . . . . . . . . . 30		5.2. Header Field Registration . . . . . . . . . . . . . . . . 30
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 30		6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 31		8.1. Normative References . . . . . . . . . . . . . . . . . . . 31
	8.2. Informative References . . . . . . . . . . . . . . . . . . 32		8.2. Informative References . . . . . . . . . . . . . . . . . . 32
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32
	skipping to change at page 4, line 13		skipping to change at page 4, line 14
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35		C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36		C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36
	C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36		C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36
	C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36		C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36
	C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37		C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37
	C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37		C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37
	C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 38		C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 38
	C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38		C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38
	C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38		C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38
	C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 38		C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 38
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38		C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 38
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 7, line 48		skipping to change at page 7, line 48
	quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>		quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 1.2.2>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	1.4.2. ABNF Rules defined in other Parts of the Specification		1.4.2. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	field-name = <field-name, defined in [Part1], Section 3.2>		field-name = <field-name, defined in [Part1], Section 3.2>
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
	port = <port, defined in [Part1], Section 2.6>		port = <port, defined in [Part1], Section 2.7>
	pseudonym = <pseudonym, defined in [Part1], Section 9.9>		pseudonym = <pseudonym, defined in [Part1], Section 9.9>
	uri-host = <uri-host, defined in [Part1], Section 2.6>		uri-host = <uri-host, defined in [Part1], Section 2.7>
			1.5. Delta Seconds
			The delta-seconds rule specifies a non-negative integer, representing
			time in seconds.
			delta-seconds = 1*DIGIT
			If an implementation receives a delta-seconds value larger than the
			largest positive integer it can represent, or if any of its
			subsequent calculations overflows, it MUST consider the value to be
			2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD
			use an arithmetic type of at least 31 bits of range, and senders MUST
			NOT send delta-seconds with a value greater than 2147483648.
	2. Cache Operation		2. Cache Operation
	2.1. Response Cacheability		2.1. Response Cacheability
	A cache MUST NOT store a response to any request, unless:		A cache MUST NOT store a response to any request, unless:
	o The request method is understood by the cache and defined as being		o The request method is understood by the cache and defined as being
	cacheable, and		cacheable, and
	skipping to change at page 8, line 42		skipping to change at page 9, line 8
	* 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
	* contains a Cache Control Extension (see Section 3.2.3) that		* contains a Cache Control Extension (see Section 3.2.3) that
	allows it to be cached, or		allows it to be cached, or
	* has a status code that can be served with heuristic freshness		* has a status code that can be served with heuristic freshness
	(see Section 2.3.1.1).		(see Section 2.3.1.1).
			Note that any of the requirements listed above can be overridden by a
			cache-control extension; see Section 3.2.3.
	In this context, a cache has "understood" a request method or a		In this context, a cache has "understood" a request method or a
	response status code if it recognises it and implements any cache-		response status code if it recognises it and implements any cache-
	specific behaviour. In particular, 206 Partial Content responses		specific behavior. In particular, 206 Partial Content responses
	cannot be cached by an implementation that does not handle partial		cannot be cached by an implementation that does not handle partial
	content (see Section 2.1.1).		content (see Section 2.1.1).
	Note that in normal operation, most caches will not store a response		Note that in normal operation, most caches will not store a response
	that has neither a cache validator nor an explicit expiration time,		that has neither a cache validator nor an explicit expiration time,
	as such responses are not usually useful to store. However, caches		as such responses are not usually useful to store. However, caches
	are not prohibited from storing such responses.		are not prohibited from storing such responses.
	2.1.1. Storing Partial and Incomplete Responses		2.1.1. Storing Partial and Incomplete Responses
	skipping to change at page 9, line 44		skipping to change at page 10, line 13
	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
	* successfully validated (see Section 2.4).		* successfully validated (see Section 2.4).
			Note that any of the requirements listed above can be overridden by a
			cache-control extension; see Section 3.2.3.
	When a stored response is used to satisfy a request without		When a stored response is used to satisfy a request without
	validation, a cache MUST include a single Age header field		validation, a cache MUST include a single Age header field
	(Section 3.1) in the response with a value equal to the stored		(Section 3.1) in the response with a value equal to the stored
	response's current_age; see Section 2.3.2.		response's current_age; see Section 2.3.2.
	A cache MUST write through requests with methods that are unsafe		A cache MUST write through requests with methods that are unsafe
	(Section 7.1.1 of [Part2]) to the origin server; i.e., a cache must		(Section 7.1.1 of [Part2]) to the origin server; i.e., a cache must
	not generate a reply to such a request before having forwarded the		not generate a reply to such a request before having forwarded the
	request and having received a corresponding response.		request and 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.
	A cache MUST use the most recent response (as determined by the Date		When more than one suitable response is stored, a cache MUST use the
	header field) when more than one suitable response is stored. It can		most recent response (as determined by the Date header field). It
	also forward a request with "Cache-Control: max-age=0" or "Cache-		can 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.
	A cache that does not have a clock available MUST NOT use stored		A cache that does not have a clock available MUST NOT use stored
	responses without revalidating them on every use. A cache,		responses without revalidating them on every use. A cache,
	especially a shared cache, SHOULD use a mechanism, such as NTP		especially a shared cache, SHOULD use a mechanism, such as NTP
	[RFC1305], to synchronize its clock with a reliable external		[RFC1305], to synchronize its clock with a reliable external
	standard.		standard.
	2.3. Freshness Model		2.3. Freshness Model
	skipping to change at page 11, line 10		skipping to change at page 11, line 30
	response_is_fresh = (freshness_lifetime > current_age)		response_is_fresh = (freshness_lifetime > current_age)
	The freshness_lifetime is defined in Section 2.3.1; the current_age		The freshness_lifetime is defined in Section 2.3.1; the current_age
	is defined in Section 2.3.2.		is defined in Section 2.3.2.
	Additionally, clients might need to influence freshness calculation.		Additionally, clients might need to influence freshness calculation.
	They can do this using several request cache directives, with the		They can do this using several request cache directives, with the
	effect of either increasing or loosening constraints on freshness.		effect of either increasing or loosening constraints on freshness.
	See Section 3.2.1.		See Section 3.2.1.
	[[ISSUE-no-req-for-directives: there are not requirements directly
	applying to cache-request-directives and freshness.]]
	Note that freshness applies only to cache operation; it cannot be		Note that freshness applies only to cache operation; it cannot be
	used to force a user agent to refresh its display or reload a		used to force a user agent to refresh its display or reload a
	resource. See Section 4 for an explanation of the difference between		resource. See Section 4 for an explanation of the difference between
	caches and history mechanisms.		caches and history mechanisms.
	2.3.1. Calculating Freshness Lifetime		2.3.1. Calculating Freshness Lifetime
	A cache can calculate the freshness lifetime (denoted as		A cache can calculate the freshness lifetime (denoted as
	freshness_lifetime) of a response by using the first match of:		freshness_lifetime) of a response by using the first match of:
	skipping to change at page 15, line 13		skipping to change at page 15, line 33
	suitable. Instead, a cache SHOULD use the full response to satisfy		suitable. Instead, a cache SHOULD use the full response to satisfy
	the request and MAY replace the stored response.		the request and MAY replace the stored response.
	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 request methods (Section 7.1.1 of [Part2]) have the		Because unsafe request methods (Section 7.1.1 of [Part2]) such as
	potential for changing state on the origin server, intervening caches		PUT, POST or DELETE have the potential for changing state on the
	can use them to keep their contents up-to-date.		origin server, intervening caches can use them to keep their contents
			up-to-date.
	A cache MUST invalidate the effective Request URI (Section 4.3 of		A cache MUST invalidate the effective Request URI (Section 4.3 of
	[Part1]) as well as the URI(s) in the Location and Content-Location		[Part1]) as well as the URI(s) in the Location and Content-Location
	header fields (if present) when the following request methods are		header fields (if present) when a non-error response to a request
	received:		with an unsafe method is received.
	o PUT
	o DELETE
	o POST
	However, a cache MUST NOT invalidate a URI from a Location or		However, a cache MUST NOT invalidate a URI from a Location or
	Content-Location header field if the host part of that URI differs		Content-Location header field if the host part of that URI differs
	from the host part in the effective request URI (Section 4.3 of		from the host part in the effective request URI (Section 4.3 of
	[Part1]). This helps prevent denial of service attacks.		[Part1]). This helps prevent denial of service attacks.
	A cache that passes through requests with methods it does not		A cache SHOULD invalidate the effective request URI (Section 4.3 of
	understand SHOULD invalidate the effective request URI (Section 4.3		[Part1]) when it receives a non-error response to a request with a
	of [Part1]).		method whose safety is unknown.
	Here, "invalidate" means that the cache will either remove all stored		Here, a "non-error response" is one with a 2xx or 3xx status code.
			"Invalidate" means that the cache will either remove all stored
	responses related to the effective request URI, or will mark these as		responses related to the effective request URI, or will mark these as
	"invalid" and in need of a mandatory validation before they can be		"invalid" and in need of a mandatory validation before they can be
	returned in 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.
	2.6. Shared Caching of Authenticated Responses		2.6. Shared Caching of Authenticated Responses
	skipping to change at page 17, line 5		skipping to change at page 17, line 22
	absent from a request, it can only match another request if it is		absent from a request, it can only match another request if it is
	also absent there.		also absent there.
	A Vary header field-value of "*" always fails to match, and		A Vary header field-value of "*" always fails to match, and
	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 header fields is known as		The stored response with matching selecting header fields is known as
	the selected response.		the selected response.
			If multiple selected responses are available, the most recent
			response (as determined by the Date header field) is used; see
			Section 2.2.
	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.8. 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
	create an updated response by combining the stored response with the		create 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
	skipping to change at page 18, line 15		skipping to change at page 18, line 34
	3.1. Age		3.1. Age
	The "Age" header field conveys the sender's estimate of the amount of		The "Age" header field conveys the sender's estimate of the amount of
	time since the response was generated or successfully validated at		time since the response was generated or successfully validated at
	the origin server. Age values are calculated as specified in		the origin server. Age values are calculated as specified in
	Section 2.3.2.		Section 2.3.2.
	Age = delta-seconds		Age = delta-seconds
	Age field-values are non-negative integers, representing time in		Age field-values are non-negative integers, representing time in
	seconds.		seconds (see Section 1.5).
	delta-seconds = 1*DIGIT
	If a cache receives a value larger than the largest positive integer
	it can represent, or if any of its age calculations overflows, it
	MUST transmit an Age header field with a field-value of 2147483648
	(2^31). Recipients parsing the Age header field-value 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 might not implement the Age header field.		HTTP/1.0 caches might not implement the Age header field.
	3.2. Cache-Control		3.2. Cache-Control
	The "Cache-Control" header field is used to specify directives for		The "Cache-Control" header field is used to specify directives for
	caches along the request/response chain. Such cache directives are		caches along the request/response chain. Such cache directives are
	unidirectional in that the presence of a directive in a request does		unidirectional in that the presence of a directive in a request does
	skipping to change at page 19, line 51		skipping to change at page 20, line 11
	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 might be vulnerable to eavesdropping.		networks might be vulnerable to eavesdropping.
	Note that if a request containing this directive is satisfied from		Note that if a request containing this directive is satisfied from
	a cache, the no-store request directive does not apply to the		a cache, the no-store request directive does not apply to the
	already stored response.		already stored response.
	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
	to accept a response whose age is no greater than the specified		unwilling to accept a response whose age is greater than the
	time in seconds. Unless the max-stale request directive is also		specified number of seconds. Unless the max-stale request
	present, the client is not willing to accept a stale response.		directive is also 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.		stale response of any age.
	skipping to change at page 20, line 35		skipping to change at page 20, line 45
	no-transform		no-transform
	The no-transform request directive indicates that an intermediary		The no-transform request directive indicates that an intermediary
	(whether or not it implements a cache) MUST NOT change the		(whether or not it implements a cache) MUST NOT change the
	Content-Encoding, Content-Range or Content-Type request header		Content-Encoding, Content-Range or Content-Type request header
	fields, nor the request representation.		fields, nor the request representation.
	only-if-cached		only-if-cached
	The only-if-cached request directive indicates that the client		The only-if-cached request directive indicates that the client
	only wishes to return a stored response. If it receives this		only wishes to obtain a stored response. If it receives this
	directive, a cache SHOULD either respond using a stored response		directive, a cache SHOULD either respond using a stored response
	that is consistent with the other constraints of the request, or		that is consistent with the other constraints of the request, or
	respond with a 504 (Gateway Timeout) status code. If a group of		respond with a 504 (Gateway Timeout) status code. If a group of
	caches is being operated as a unified system with good internal		caches is being operated as a unified system with good internal
	connectivity, a member cache MAY forward such a request within		connectivity, a member cache MAY forward such a request within
	that group of caches.		that group of caches.
	3.2.2. Response Cache-Control Directives		3.2.2. Response Cache-Control Directives
	cache-response-directive =		cache-response-directive =
	skipping to change at page 24, line 20		skipping to change at page 24, line 20
	wishing to allow the UCI community to use an otherwise private		wishing to allow the UCI community to use an otherwise private
	response in their shared cache(s) could do so by including		response in their shared cache(s) could do so by including
	Cache-Control: private, community="UCI"		Cache-Control: private, community="UCI"
	A cache seeing this header field will act correctly even if the cache		A cache seeing this header field will act correctly even if the cache
	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.
	A cache MUST be ignore unrecognized cache directives; it is assumed		A cache MUST ignore unrecognized cache directives; it is assumed that
	that any cache directive likely to be unrecognized by an HTTP/1.1		any cache directive likely to be unrecognized by an HTTP/1.1 cache
	cache will be combined with standard directives (or the response's		will be combined with standard directives (or the response's default
	default cacheability) such that the cache behavior will remain		cacheability) such that the cache behavior will remain minimally
	minimally correct even if the cache does not understand the		correct even if the cache does not understand the extension(s).
	extension(s).
	The HTTP Cache Directive Registry defines the name space for the		The HTTP Cache Directive Registry defines the name space for the
	cache directives.		cache directives.
	A registration MUST include the following fields:		A registration MUST include the following fields:
	o Cache Directive Name		o Cache Directive Name
	o Pointer to specification text		o Pointer to specification text
	skipping to change at page 25, line 25		skipping to change at page 25, line 24
	in shared caches.		in shared caches.
	A server SHOULD NOT send Expires dates more than one year in the		A server SHOULD NOT send Expires dates more than one year in the
	future.		future.
	A cache MUST treat other invalid date formats, especially including		A cache MUST treat other invalid date formats, especially including
	the value "0", as in the past (i.e., "already expired").		the value "0", as in the past (i.e., "already expired").
	3.4. Pragma		3.4. Pragma
	The "Pragma" header field is used to include implementation-specific		The "Pragma" header field allows backwards compatibility with
	directives that might apply to any recipient along the request/		HTTP/1.0 caches, so that clients can specify a "no-cache" request
	response chain. All pragma directives specify optional behavior from		that they will understand (as Cache-Control was not defined until
	the viewpoint of the protocol; however, some systems MAY require that		HTTP/1.1). When the Cache-Control header is also present and
	behavior be consistent with the directives.		understood in a request, Pragma is ignored.
			In HTTP/1.0, Pragma was defined as an extensible field for
			implementation-specified directives for recipients. This
			specification deprecates such extensions to improve interoperability.
	Pragma = 1#pragma-directive		Pragma = 1#pragma-directive
	pragma-directive = "no-cache" / extension-pragma		pragma-directive = "no-cache" / extension-pragma
	extension-pragma = token [ "=" ( token / quoted-string ) ]		extension-pragma = token [ "=" ( token / quoted-string ) ]
	When the no-cache directive is present in a request message, a cache		When the Cache-Control header is not present in a request, the no-
	SHOULD forward the request toward the origin server even if it has a		cache request pragma-directive MUST have the same effect on caches as
	stored copy of what is being requested. This pragma directive has		if "Cache-Control: no-cache" were present (see Section 3.2.1).
	the same semantics as the no-cache response directive (see
	Section 3.2.2) and is defined here for backward compatibility with
	HTTP/1.0. A client SHOULD include both header fields when a no-cache
	request is sent to a server not known to be HTTP/1.1 compliant. A
	cache SHOULD treat "Pragma: no-cache" as if the client had sent
	"Cache-Control: no-cache".
	Note: Because the meaning of "Pragma: no-cache" as a header field		When sending a no-cache request, a client SHOULD include both pragma
	is not actually specified, it does not provide a reliable		and cache-control directives unless Cache-Control: no-cache is
	replacement for "Cache-Control: no-cache" in a response.		purposefully omitted to target other Cache-Control response
			directives at HTTP/1.1 caches. For example:
	This mechanism is deprecated; no new Pragma directives will be		GET / HTTP/1.1
	defined in HTTP.		Host: www.example.com
			Cache-Control: max-age=30
			Pragma: no-cache
			will constrain HTTP/1.1 caches to serve a response no older than 30
			seconds, while precluding implementations that do not understand
			Cache-Control from serving a cached response.
			Note: Because the meaning of "Pragma: no-cache" in responses is
			not specified, it does not provide a reliable replacement for
			"Cache-Control: no-cache" in them.
	3.5. Vary		3.5. Vary
	The "Vary" header field conveys the set of header fields that were		The "Vary" header field conveys the set of header fields that were
	used to select the representation.		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.7.		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
	skipping to change at page 31, line 18		skipping to change at page 31, line 18
	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-14		and Message Parsing", draft-ietf-httpbis-p1-messaging-15
	(work in progress), April 2011.		(work in progress), July 2011.
	[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-14 (work in		Semantics", draft-ietf-httpbis-p2-semantics-15 (work in
	progress), April 2011.		progress), July 2011.
	[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-14 (work in		Requests", draft-ietf-httpbis-p4-conditional-15 (work in
	progress), April 2011.		progress), July 2011.
	[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-14 (work		Partial Responses", draft-ietf-httpbis-p5-range-15 (work
	in progress), April 2011.		in progress), July 2011.
	[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-14 (work in progress),		draft-ietf-httpbis-p7-auth-15 (work in progress),
	April 2011.		July 2011.
	[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)
	skipping to change at page 33, line 36		skipping to change at page 33, line 36
	field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" /		field-name ] ) DQUOTE ] ) / "no-store" / "no-transform" /
	"must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds		"must-revalidate" / "proxy-revalidate" / ( "max-age=" delta-seconds
	) / ( "s-maxage=" delta-seconds ) / cache-extension		) / ( "s-maxage=" delta-seconds ) / cache-extension
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	extension-pragma = token [ "=" ( token / quoted-string ) ]		extension-pragma = token [ "=" ( token / quoted-string ) ]
	field-name = <field-name, defined in [Part1], Section 3.2>		field-name = <field-name, defined in [Part1], Section 3.2>
	port = <port, defined in [Part1], Section 2.6>		port = <port, defined in [Part1], Section 2.7>
	pragma-directive = "no-cache" / extension-pragma		pragma-directive = "no-cache" / extension-pragma
	pseudonym = <pseudonym, defined in [Part1], Section 9.9>		pseudonym = <pseudonym, defined in [Part1], Section 9.9>
	quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>		quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 1.2.2>
	uri-host = <uri-host, defined in [Part1], Section 2.6>		uri-host = <uri-host, defined in [Part1], Section 2.7>
	warn-agent = ( uri-host [ ":" port ] ) / pseudonym		warn-agent = ( uri-host [ ":" port ] ) / pseudonym
	warn-code = 3DIGIT		warn-code = 3DIGIT
	warn-date = DQUOTE HTTP-date DQUOTE		warn-date = DQUOTE HTTP-date DQUOTE
	warn-text = quoted-string		warn-text = quoted-string
	warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date		warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
	]		]
	ABNF diagnostics:		ABNF diagnostics:
	skipping to change at page 37, line 18		skipping to change at page 37, line 18
	C.10. Since draft-ietf-httpbis-p6-cache-08		C.10. Since draft-ietf-httpbis-p6-cache-08
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/147>: "serving		o <http://tools.ietf.org/wg/httpbis/trac/ticket/147>: "serving
	negotiated responses from cache: header-specific canonicalization"		negotiated responses from cache: header-specific canonicalization"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/197>: "Effect of CC		o <http://tools.ietf.org/wg/httpbis/trac/ticket/197>: "Effect of CC
	directives on history lists"		directives on history lists"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/291>: "Cache
			Extensions can override no-store, etc."
	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"
	skipping to change at page 38, line 18		skipping to change at page 38, line 21
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify		o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
	entity / representation / variant terminology"		entity / representation / variant terminology"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider		o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
	removing the 'changes from 2068' sections"		removing the 'changes from 2068' sections"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing		o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
	heuristic caching for new status codes"		heuristic caching for new status codes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
	heuristic caching for new status codes"
	o Clean up TODOs and prose in "Combining Responses."		o Clean up TODOs and prose in "Combining Responses."
	C.13. Since draft-ietf-httpbis-p6-cache-11		C.13. Since draft-ietf-httpbis-p6-cache-11
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about		o <http://tools.ietf.org/wg/httpbis/trac/ticket/204>: "Text about
	clock requirement for caches belongs in p6"		clock requirement for caches belongs in p6"
	C.14. Since draft-ietf-httpbis-p6-cache-12		C.14. Since draft-ietf-httpbis-p6-cache-12
	skipping to change at page 38, line 47		skipping to change at page 38, line 47
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/268>: "Clarify		o <http://tools.ietf.org/wg/httpbis/trac/ticket/268>: "Clarify
	'public'"		'public'"
	C.15. Since draft-ietf-httpbis-p6-cache-13		C.15. Since draft-ietf-httpbis-p6-cache-13
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle		o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
	ABNFs for header fields"		ABNFs for header fields"
			C.16. Since draft-ietf-httpbis-p6-cache-14
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/38>: "Mismatch Vary"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/235>: "Cache
			Invalidation only happens upon successful responses"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
			minimum sizes for protocol elements"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/289>: "Proxies don't
			'understand' methods"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma"
	Index		Index
	A		A
	age 6		age 6
	Age header field 18		Age header field 18
	C		C
	cache 5		cache 5
	Cache Directives		Cache Directives
	max-age 19, 23		max-age 20, 23
	max-stale 20		max-stale 20
	min-fresh 20		min-fresh 20
	must-revalidate 22		must-revalidate 22
	no-cache 19, 21		no-cache 19, 21
	no-store 19, 22		no-store 19, 22
	no-transform 20, 23		no-transform 20, 23
	only-if-cached 20		only-if-cached 20
	private 21		private 21
	proxy-revalidate 23		proxy-revalidate 23
	public 21		public 21
	skipping to change at page 39, line 39		skipping to change at page 40, line 7
	fresh 6		fresh 6
	freshness lifetime 6		freshness lifetime 6
	G		G
	Grammar		Grammar
	Age 18		Age 18
	Cache-Control 19		Cache-Control 19
	cache-extension 19		cache-extension 19
	cache-request-directive 19		cache-request-directive 19
	cache-response-directive 21		cache-response-directive 21
	delta-seconds 18		delta-seconds 8
	Expires 25		Expires 25
	extension-pragma 25		extension-pragma 25
	Pragma 25		Pragma 25
	pragma-directive 25		pragma-directive 25
	Vary 26		Vary 26
	warn-agent 27		warn-agent 27
	warn-code 27		warn-code 27
	warn-date 27		warn-date 27
	warn-text 27		warn-text 27
	Warning 27		Warning 27
	warning-value 27		warning-value 27
	H		H
	Header Fields		Header Fields
	Age 18		Age 18
	Cache-Control 18		Cache-Control 18
	Expires 24		Expires 24
	Pragma 25		Pragma 25
	Vary 26		Vary 26
	Warning 26		Warning 27
	heuristic expiration time 6		heuristic expiration time 6
	M		M
	max-age		max-age
	Cache Directive 19, 23		Cache Directive 20, 23
	max-stale		max-stale
	Cache Directive 20		Cache Directive 20
	min-fresh		min-fresh
	Cache Directive 20		Cache Directive 20
	must-revalidate		must-revalidate
	Cache Directive 22		Cache Directive 22
	N		N
	no-cache		no-cache
	Cache Directive 19, 21		Cache Directive 19, 21
	skipping to change at page 41, line 8		skipping to change at page 41, line 26
	s-maxage		s-maxage
	Cache Directive 23		Cache Directive 23
	shared cache 5		shared cache 5
	stale 6		stale 6
	V		V
	validator 6		validator 6
	Vary header field 26		Vary header field 26
	W		W
	Warning header field 26		Warning header field 27
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
End of changes. 46 change blocks.
	93 lines changed or deleted		129 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/