draft-ietf-httpbis-p6-cache-15.txt		draft-ietf-httpbis-p6-cache-16.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: January 12, 2012 J. Mogul		Expires: February 25, 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
	July 11, 2011		August 24, 2011
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-15		draft-ietf-httpbis-p6-cache-16
	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, hypertext information
	systems. This document is Part 6 of the seven-part specification		systems. HTTP has been in use by the World Wide Web global
	that defines the protocol referred to as "HTTP/1.1" and, taken		information initiative since 1990. This document is Part 6 of the
	together, obsoletes RFC 2616. Part 6 defines requirements on HTTP		seven-part specification that defines the protocol referred to as
	caches and the associated header fields that control cache behavior		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	or indicate cacheable response messages.
			Part 6 defines requirements on HTTP caches and the associated header
			fields that control cache behavior 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), 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.16.		The changes in this draft are summarized in Appendix C.17.
	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 January 12, 2012.		This Internet-Draft will expire on February 25, 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 9		skipping to change at page 3, line 14
	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 . . . . . . . . . . . . . . . . . . . . 8
	1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8		1.5. Delta Seconds . . . . . . . . . . . . . . . . . . . . . . 8
	2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8		2. Cache Operation . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 8		2.1. Response Cacheability . . . . . . . . . . . . . . . . . . 9
	2.1.1. Storing Partial and Incomplete Responses . . . . . . . 9		2.2. Constructing Responses from Caches . . . . . . . . . . . . 10
	2.2. Constructing Responses from Caches . . . . . . . . . . . . 9		2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 11
	2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 10		2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 12
	2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 11		2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 13
	2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 12		2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 15
	2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 14		2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 16
	2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 14		2.5. Request Methods that Invalidate . . . . . . . . . . . . . 16
	2.5. Request Methods that Invalidate . . . . . . . . . . . . . 15		2.6. Shared Caching of Authenticated Responses . . . . . . . . 17
	2.6. Shared Caching of Authenticated Responses . . . . . . . . 16		2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 18
	2.7. Caching Negotiated Responses . . . . . . . . . . . . . . . 16		2.8. Combining Partial Content . . . . . . . . . . . . . . . . 18
	2.8. Combining Responses . . . . . . . . . . . . . . . . . . . 17		2.9. Freshening Responses . . . . . . . . . . . . . . . . . . . 19
	3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 18		3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
	3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 18		3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 20
	3.2.1. Request Cache-Control Directives . . . . . . . . . . . 19		3.2.1. Request Cache-Control Directives . . . . . . . . . . . 21
	3.2.2. Response Cache-Control Directives . . . . . . . . . . 21		3.2.2. Response Cache-Control Directives . . . . . . . . . . 23
	3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 23		3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 25
	3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 24		3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 26
	3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 25		3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 27		3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 29
	4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 29		4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 31
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 29		5.1. Cache Directive Registry . . . . . . . . . . . . . . . . . 31
	5.2. Header Field Registration . . . . . . . . . . . . . . . . 30		5.2. Header Field Registration . . . . . . . . . . . . . . . . 32
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 30		6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 31		8.1. Normative References . . . . . . . . . . . . . . . . . . . 33
	8.2. Informative References . . . . . . . . . . . . . . . . . . 32		8.2. Informative References . . . . . . . . . . . . . . . . . . 33
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 32		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 34
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 32		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 34
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 34		publication) . . . . . . . . . . . . . . . . . . . . 36
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 34		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 36
	C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 34		C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 36
	C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 35		C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 37
	C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 35		C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 37
	C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 35		C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 37
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35		C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 37
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 36		C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 38
	C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 36		C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 38
	C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 36		C.9. Since draft-ietf-httpbis-p6-cache-07 . . . . . . . . . . . 38
	C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 37		C.10. Since draft-ietf-httpbis-p6-cache-08 . . . . . . . . . . . 39
	C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 37		C.11. Since draft-ietf-httpbis-p6-cache-09 . . . . . . . . . . . 39
	C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 38		C.12. Since draft-ietf-httpbis-p6-cache-10 . . . . . . . . . . . 40
	C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 38		C.13. Since draft-ietf-httpbis-p6-cache-11 . . . . . . . . . . . 40
	C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 38		C.14. Since draft-ietf-httpbis-p6-cache-12 . . . . . . . . . . . 40
	C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 38		C.15. Since draft-ietf-httpbis-p6-cache-13 . . . . . . . . . . . 40
	C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 38		C.16. Since draft-ietf-httpbis-p6-cache-14 . . . . . . . . . . . 40
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39		C.17. Since draft-ietf-httpbis-p6-cache-15 . . . . . . . . . . . 41
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	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
	An HTTP cache is a local store of response messages and the subsystem		An HTTP cache is a local store of response messages and the subsystem
	that controls its message storage, retrieval, and deletion. A cache		that controls its message storage, retrieval, and deletion. A cache
	stores cacheable responses in order to reduce the response time and		stores cacheable responses in order to reduce the response time and
	network bandwidth consumption on future, equivalent requests. Any		network bandwidth consumption on future, equivalent requests. Any
	client or server MAY employ a cache, though a cache cannot be used by		client or server MAY employ a cache, though a cache cannot be used by
	a server that is acting as a tunnel.		a server that is acting as a tunnel.
	Caching would be useless if it did not significantly improve		The goal of caching in HTTP/1.1 is to significantly improve
	performance. The goal of caching in HTTP/1.1 is to reuse a prior		performance by reusing a prior response message to satisfy a current
	response message to satisfy a current request. In some cases, a		request. A stored response is considered "fresh", as defined in
	stored response can be reused without the need for a network request,		Section 2.3, if the response can be reused without "validation"
	reducing latency and network round-trips; a "freshness" mechanism is		(checking with the origin server to see if the cached response
	used for this purpose (see Section 2.3). Even when a new request is		remains valid for this request). A fresh cache response can
	required, it is often possible to reuse all or parts of the payload		therefore reduce both latency and network transfers each time it is
	of a prior response to satisfy the request, thereby reducing network		reused. When a cached response is not fresh, it might still be
	bandwidth usage; a "validation" mechanism is used for this purpose		reusable if it can be freshened by validation (Section 2.4) or if the
	(see Section 2.4).		origin is unavailable.
	1.2. Terminology		1.2. Terminology
	This specification uses a number of terms to refer to the roles		This specification uses a number of terms to refer to the roles
	played by participants in, and objects of, HTTP caching.		played by participants in, and objects of, HTTP caching.
	cache		cache
	A conformant implementation of a HTTP cache. Note that this		A conformant implementation of a HTTP cache. Note that this
	implies an HTTP/1.1 cache; this specification does not define		implies an HTTP/1.1 cache; this specification does not define
	conformance for HTTP/1.0 caches.		conformance for HTTP/1.0 caches.
	shared cache		shared cache
	A cache that is accessible to more than one user; usually (but not		A cache that stores responses to be reused by more than one user;
	always) deployed as part of an intermediary.		usually (but not always) deployed as part of an intermediary.
	private cache		private cache
	A cache that is dedicated to a single user.		A cache that is dedicated to a single user.
	cacheable		cacheable
	A response is cacheable if a cache is allowed to store a copy of		A response is cacheable if a cache is allowed to store a copy of
	the response message for use in answering subsequent requests.		the response message for use in answering subsequent requests.
	Even when a response is cacheable, there might be additional		Even when a response is cacheable, there might be additional
	skipping to change at page 6, line 52		skipping to change at page 6, line 52
	stale		stale
	A response is stale if its age has passed its freshness lifetime		A response is stale if its age has passed its freshness lifetime
	(either explicit or heuristic).		(either explicit or heuristic).
	validator		validator
	A protocol element (e.g., an entity-tag or a Last-Modified time)		A protocol element (e.g., an entity-tag or a Last-Modified time)
	that is used to find out whether a stored response is an		that is used to find out whether a stored response is an
	equivalent copy of a representation.		equivalent copy of a representation. See Section 2.1 of [Part4].
			strong validator
			A validator that is defined by the origin server such that its
			current value will change if the representation body changes;
			i.e., an entity-tag that is not marked as weak (Section 2.3 of
			[Part4]) or, if no entity-tag is provided, a Last-Modified value
			that is strong in the sense defined by Section 2.2.2 of [Part4].
	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
	skipping to change at page 7, line 36		skipping to change at page 7, line 44
	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
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), VCHAR (any visible USASCII character),		sequence of data), SP (space), VCHAR (any visible USASCII character),
	and WSP (whitespace).		and WSP (whitespace).
	1.4.1. Core Rules		1.4.1. Core Rules
	The core rules below are defined in Section 1.2.2 of [Part1]:		The core rules below are defined in [Part1]:
	quoted-string = <quoted-string, 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>
			quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
			token = <token, defined in [Part1], Section 3.2.3>
	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.7>		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.7>		uri-host = <uri-host, defined in [Part1], Section 2.7>
	skipping to change at page 8, line 21		skipping to change at page 8, line 31
	If an implementation receives a delta-seconds value larger than the		If an implementation receives a delta-seconds value larger than the
	largest positive integer it can represent, or if any of its		largest positive integer it can represent, or if any of its
	subsequent calculations overflows, it MUST consider the value to be		subsequent calculations overflows, it MUST consider the value to be
	2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD		2147483648 (2^31). Recipients parsing a delta-seconds value SHOULD
	use an arithmetic type of at least 31 bits of range, and senders MUST		use an arithmetic type of at least 31 bits of range, and senders MUST
	NOT send delta-seconds with a value greater than 2147483648.		NOT send delta-seconds with a value greater than 2147483648.
	2. Cache Operation		2. Cache Operation
			Proper cache operation preserves the semantics of HTTP transfers
			([Part2]) while eliminating the transfer of information already held
			in the cache. Although caching is an entirely OPTIONAL feature of
			HTTP, we assume that reusing the cached response is desirable and
			that such reuse is the default behavior when no requirement or
			locally-desired configuration prevents it. Therefore, HTTP cache
			requirements are focused on preventing a cache from either storing a
			non-reusable response or reusing a stored response inappropriately.
			Each cache entry consists of a cache key and one or more HTTP
			responses corresponding to prior requests that used the same key.
			The most common form of cache entry is a successful result of a
			retrieval request: i.e., a 200 (OK) response containing a
			representation of the resource identified by the request target.
			However, it is also possible to cache negative results (e.g., 404 not
			found), incomplete results (e.g., 206 partial content), and responses
			to safe methods other than GET if the method's definition allows such
			caching and defines something suitable for use as a cache key.
			The default cache key consists of the request method and target URI.
			However, since HTTP caches in common use today are typically limited
			to caching responses to GET, most implementations simply decline
			other methods and use only the URI as the key.
			If a request target is subject to content negotiation, its cache
			entry might consist of multiple stored responses, each differentiated
			by a secondary key for the values of the original request's selecting
			header fields (Section 2.7).
	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
	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
	skipping to change at page 9, line 12		skipping to change at page 9, line 50
	* 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		Note that any of the requirements listed above can be overridden by a
	cache-control extension; see Section 3.2.3.		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 recognizes it and implements any cache-
	specific behavior. In particular, 206 Partial Content responses		specific behavior.
	cannot be cached by an implementation that does not handle partial
	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		A response message is considered complete when all of the octets
			indicated by the message framing ([Part1]) are received prior to the
	A cache that receives an incomplete response (for example, with fewer		connection being closed. If the request is GET, the response status
	bytes of data than specified in a Content-Length header field) can		is 200 (OK), and the entire response header block has been received,
	store the response, but MUST treat it as a partial response [Part5].		a cache MAY store an incomplete response message-body if the cache
	Partial responses can be combined as described in Section 4 of		entry is recorded as incomplete. Likewise, a 206 (Partial Content)
	[Part5]; the result might be a full response or might still be		response MAY be stored as if it were an incomplete 200 (OK) cache
	partial. A cache MUST NOT return a partial response to a client		entry. However, a cache MUST NOT store incomplete or partial content
	without explicitly marking it as such using the 206 (Partial Content)		responses if it does not support the Range and Content-Range header
	status code.		fields or if it does not understand the range units used in those
			fields.
	A cache that does not support the Range and Content-Range header		A cache MAY complete a stored incomplete response by making a
	fields MUST NOT store incomplete or partial responses.		subsequent range request ([Part5]) and combining the successful
			response with the stored entry, as defined in Section 2.8. A cache
			MUST NOT use an incomplete response to answer requests unless the
			response has been made complete or the request is partial and
			specifies a range that is wholly within the incomplete response. A
			cache MUST NOT send a partial response to a client without explicitly
			marking it as such using the 206 (Partial Content) status code.
	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 effective request URI (Section 4.3 of [Part1]) and		o The presented effective request URI (Section 4.3 of [Part1]) and
	that of the stored response match, and		that of the stored response match, and
	o the request method associated with the stored response allows it		o the request method associated with the stored response allows it
	skipping to change at page 12, line 22		skipping to change at page 13, line 19
	used (including the following in Section 8 of [Part2]: 200, 203, 206,		used (including the following in Section 8 of [Part2]: 200, 203, 206,
	300, 301 and 410), a cache MAY calculate a heuristic expiration time.		300, 301 and 410), a cache MAY calculate a heuristic expiration time.
	A cache MUST NOT use heuristics to determine freshness for responses		A cache MUST NOT use heuristics to determine freshness for responses
	with status codes that do not explicitly allow it.		with status codes that do not explicitly allow it.
	When a heuristic is used to calculate freshness lifetime, a cache		When a heuristic is used to calculate freshness lifetime, a cache
	SHOULD attach a Warning header field with a 113 warn-code to the		SHOULD attach a Warning header field with a 113 warn-code to the
	response if its current_age is more than 24 hours and such a warning		response if its current_age is more than 24 hours and such a warning
	is not already present.		is not already present.
	Also, if the response has a Last-Modified header field (Section 2.1		Also, if the response has a Last-Modified header field (Section 2.2
	of [Part4]), a cache SHOULD NOT use a heuristic expiration value that		of [Part4]), a cache SHOULD NOT use a heuristic expiration value that
	is more than some fraction of the interval since that time. A		is more than some fraction of the interval since that time. A
	typical setting of this fraction might be 10%.		typical setting of this fraction might be 10%.
	Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do		Note: RFC 2616 ([RFC2616], Section 13.9) required that caches do
	not calculate heuristic freshness for URIs with query components		not calculate heuristic freshness for URIs with query components
	(i.e., those containing '?'). In practice, this has not been		(i.e., those containing '?'). In practice, this has not been
	widely implemented. Therefore, servers are encouraged to send		widely implemented. Therefore, servers are encouraged to send
	explicit directives (e.g., Cache-Control: no-cache) if they wish		explicit directives (e.g., Cache-Control: no-cache) if they wish
	to preclude caching.		to preclude caching.
	skipping to change at page 14, line 16		skipping to change at page 15, line 8
	corrected_initial_age = max(apparent_age, corrected_age_value);		corrected_initial_age = max(apparent_age, corrected_age_value);
	The current_age of a stored response can then be calculated by adding		The current_age of a stored response can then be calculated by adding
	the amount of time (in seconds) since the stored response was last		the amount of time (in seconds) since the stored response was last
	validated by the origin server to the corrected_initial_age.		validated by the origin server to the corrected_initial_age.
	resident_time = now - response_time;		resident_time = now - response_time;
	current_age = corrected_initial_age + resident_time;		current_age = corrected_initial_age + resident_time;
			Additional rules for requirements on parsing and encoding of dates
			and other potential problems with date encodings include:
			o HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
			which appears to be more than 50 years in the future is in fact in
			the past (this helps solve the "year 2000" problem).
			o Although all date formats are specified to be case-sensitive,
			recipients SHOULD match day, week and timezone names case-
			insensitively.
			o An HTTP/1.1 implementation MAY internally represent a parsed
			Expires date as earlier than the proper value, but MUST NOT
			internally represent a parsed Expires date as later than the
			proper value.
			o All expiration-related calculations MUST be done in GMT. The
			local time zone MUST NOT influence the calculation or comparison
			of an age or expiration time.
			o If an HTTP header field incorrectly carries a date value with a
			time zone other than GMT, it MUST be converted into GMT using the
			most conservative possible conversion.
	2.3.3. Serving Stale Responses		2.3.3. Serving Stale Responses
	A "stale" response is one that either has explicit expiry information		A "stale" response is one that either has explicit expiry information
	or is allowed to have heuristic expiry calculated, but is not fresh		or is allowed to have heuristic expiry calculated, but is not fresh
	according to the calculations in Section 2.3.		according to the calculations in Section 2.3.
	A cache MUST NOT return a stale response if it is prohibited by an		A cache 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;
	skipping to change at page 15, line 19		skipping to change at page 16, line 36
	available.		available.
	Additionally, a cache SHOULD add an If-None-Match header field whose		Additionally, a cache SHOULD add an If-None-Match header field whose
	value is that of the ETag header field(s) from all responses stored		value is that of the ETag header field(s) from all responses stored
	for the requested URI, if present. However, if any of the stored		for the requested URI, if present. However, if any of the stored
	responses contains only partial content, the cache SHOULD NOT include		responses contains only partial content, the cache SHOULD NOT include
	its entity-tag in the If-None-Match header field unless the request		its entity-tag in the If-None-Match header field unless the request
	is for a range that would be fully satisfied by that stored response.		is for a range 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.8.		response can be updated and reused; see Section 2.9.
	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, 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(s).
	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]) such as		Because unsafe request methods (Section 7.1.1 of [Part2]) such as
	PUT, POST or DELETE have the potential for changing state on the		PUT, POST or DELETE have the potential for changing state on the
	skipping to change at page 17, line 30		skipping to change at page 18, line 48
	the selected response.		the selected response.
	If multiple selected responses are available, the most recent		If multiple selected responses are available, the most recent
	response (as determined by the Date header field) is used; see		response (as determined by the Date header field) is used; see
	Section 2.2.		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 Partial Content
	When a cache receives a 304 (Not Modified) response or a 206 (Partial		A response might transfer only a partial representation if the
	Content) response (in this section, the "new" response"), it needs to		connection closed prematurely or if the request used one or more
	create an updated response by combining the stored response with the		Range specifiers ([Part5]). After several such transfers, a cache
	new one, so that the updated response can be used to satisfy the		might have received several ranges of the same representation. A
	request, and potentially update the cached response.		cache MAY combine these ranges into a single stored response, and
			reuse that response to satisfy later requests, if they all share the
			same strong validator and the cache complies with the client
			requirements in Section 4 of [Part5].
	If the new response contains an ETag, it identifies the stored		When combining the new response with one or more stored responses, a
	response to use. [[TODO-mention-CL: might need language about		cache MUST:
	Content-Location here]][[TODO-select-for-combine: Shouldn't this be
	the selected response?]]
	When the new response's status code is 206 (partial content), a cache		o delete any Warning header fields in the stored response with warn-
	MUST NOT combine it with the old response if either response does not		code 1xx (see Section 3.6);
	have a validator, and MUST NOT combine it with the old response when
	those validators do not match with the strong comparison function
	(see Section 2.2.2 of [Part4]).
	The stored response header fields are used as those of the updated		o retain any Warning header fields in the stored response with warn-
	response, except that		code 2xx; and,
	o a cache MUST delete any stored Warning header fields with warn-
	code 1xx (see Section 3.6).
	o a cache MUST retain any stored Warning header fields with warn-		o use other header fields provided in the new response, aside from
	code 2xx.		Content-Range, to replace all instances of the corresponding
			header fields in the stored response.
	o a cache MUST use other header fields provided in the new response		2.9. Freshening Responses
	to replace all instances of the corresponding header fields from
	the stored response.
	A cache MUST use the updated response header fields to replace those		When a cache receives a 304 (Not Modified) response and already has
	of the stored response (unless the stored response is removed). In		one or more stored 200 (OK) responses for the same cache key, the
	the case of a 206 response, a cache MAY store the combined		cache needs to identify which of the stored responses are updated by
	representation.		this new response and then update the stored response(s) with the new
			information provided in the 304 response.
			o If the new response contains a strong validator, then that strong
			validator identifies the selected representation. All of the
			stored responses with the same strong validator are selected. If
			none of the stored responses contain the same strong validator,
			then this new response corresponds to a new selected
			representation and MUST NOT update the existing stored responses.
			o If the new response contains a weak validator and that validator
			corresponds to one of the cache's stored responses, then the most
			recent of those matching stored responses is selected.
			o If the new response does not include any form of validator, there
			is only one stored response, and that stored response also lacks a
			validator, then that stored response is selected.
			If a stored response is selected for update, the cache MUST:
			o delete any Warning header fields in the stored response with warn-
			code 1xx (see Section 3.6);
			o retain any Warning header fields in the stored response with warn-
			code 2xx; and,
			o use other header fields provided in the 304 response to replace
			all instances of the corresponding header fields in the stored
			response.
	3. Header Field Definitions		3. Header Field Definitions
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to caching.		fields related to caching.
	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
	skipping to change at page 25, line 11		skipping to change at page 27, line 11
	The field-value is an absolute date and time as defined by HTTP-date		The field-value is an absolute date and time as defined by HTTP-date
	in Section 6.1 of [Part1]; a sender MUST use the rfc1123-date format.		in Section 6.1 of [Part1]; a sender MUST use the rfc1123-date format.
	Expires = HTTP-date		Expires = HTTP-date
	For example		For example
	Expires: Thu, 01 Dec 1994 16:00:00 GMT		Expires: Thu, 01 Dec 1994 16:00:00 GMT
			A cache MUST treat other invalid date formats, especially including
			the value "0", as in the past (i.e., "already expired").
	Note: If a response includes a Cache-Control field with the max-		Note: If a response includes a Cache-Control field with the max-
	age directive (see Section 3.2.2), that directive overrides the		age directive (see Section 3.2.2), that directive overrides the
	Expires field. Likewise, the s-maxage directive overrides Expires		Expires field. Likewise, the s-maxage directive overrides Expires
	in shared caches.		in shared caches.
	A server SHOULD NOT send Expires dates more than one year in the		Historically, HTTP required the Expires field-value to be no more
	future.		than a year in the future. While longer freshness lifetimes are no
			longer prohibited, extremely large values have been demonstrated to
	A cache MUST treat other invalid date formats, especially including		cause problems (e.g., clock overflows due to use of 32-bit integers
	the value "0", as in the past (i.e., "already expired").		for time values), and most caches will evict a response far sooner
			than that. Therefore, senders ought not produce them.
	3.4. Pragma		3.4. Pragma
	The "Pragma" header field allows backwards compatibility with		The "Pragma" header field allows backwards compatibility with
	HTTP/1.0 caches, so that clients can specify a "no-cache" request		HTTP/1.0 caches, so that clients can specify a "no-cache" request
	that they will understand (as Cache-Control was not defined until		that they will understand (as Cache-Control was not defined until
	HTTP/1.1). When the Cache-Control header is also present and		HTTP/1.1). When the Cache-Control header is also present and
	understood in a request, Pragma is ignored.		understood in a request, Pragma is ignored.
	In HTTP/1.0, Pragma was defined as an extensible field for		In HTTP/1.0, Pragma was defined as an extensible field for
	skipping to change at page 31, line 7		skipping to change at page 33, line 7
	Caches expose additional potential vulnerabilities, since the		Caches expose additional potential vulnerabilities, since the
	contents of the cache represent an attractive target for malicious		contents of the cache represent an attractive target for malicious
	exploitation. Because cache contents persist after an HTTP request		exploitation. Because cache contents persist after an HTTP request
	is complete, an attack on the cache can reveal information long after		is complete, an attack on the cache can reveal information long after
	a user believes that the information has been removed from the		a user believes that the information has been removed from the
	network. Therefore, cache contents need to be protected as sensitive		network. Therefore, cache contents need to be protected as sensitive
	information.		information.
	7. Acknowledgments		7. Acknowledgments
	Much of the content and presentation of the caching design is due to		See Section 12 of [Part1].
	suggestions and comments from individuals including: Shel Kaphan,
	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-15		and Message Parsing", draft-ietf-httpbis-p1-messaging-16
	(work in progress), July 2011.		(work in progress), August 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-15 (work in		Semantics", draft-ietf-httpbis-p2-semantics-16 (work in
	progress), July 2011.		progress), August 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-15 (work in		Requests", draft-ietf-httpbis-p4-conditional-16 (work in
	progress), July 2011.		progress), August 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-15 (work		Partial Responses", draft-ietf-httpbis-p5-range-16 (work
	in progress), July 2011.		in progress), August 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-15 (work in progress),		draft-ietf-httpbis-p7-auth-16 (work in progress),
	July 2011.		August 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 40		skipping to change at page 35, line 36
	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.7>		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 3.2.3>
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 3.2.3>
	uri-host = <uri-host, defined in [Part1], Section 2.7>		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
	]		]
	skipping to change at page 39, line 13		skipping to change at page 41, line 13
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/38>: "Mismatch Vary"		o <http://tools.ietf.org/wg/httpbis/trac/ticket/38>: "Mismatch Vary"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/235>: "Cache		o <http://tools.ietf.org/wg/httpbis/trac/ticket/235>: "Cache
	Invalidation only happens upon successful responses"		Invalidation only happens upon successful responses"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend		o <http://tools.ietf.org/wg/httpbis/trac/ticket/282>: "Recommend
	minimum sizes for protocol elements"		minimum sizes for protocol elements"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/289>: "Proxies don't		o <http://tools.ietf.org/wg/httpbis/trac/ticket/289>: "Proxies don't
	'understand' methods"		'understand' methods"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/291>: "Cache
			Extensions can override no-store, etc."
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma"		o <http://tools.ietf.org/wg/httpbis/trac/ticket/292>: "Pragma"
			C.17. Since draft-ietf-httpbis-p6-cache-15
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/290>: "Motivate one-
			year limit for Expires"
	Index		Index
	A		A
	age 6		age 6
	Age header field 18		Age header field 20
	C		C
	cache 5		cache 5
	Cache Directives		Cache Directives
	max-age 20, 23		max-age 21, 25
	max-stale 20		max-stale 22
	min-fresh 20		min-fresh 22
	must-revalidate 22		must-revalidate 24
	no-cache 19, 21		no-cache 21, 23
	no-store 19, 22		no-store 21, 24
	no-transform 20, 23		no-transform 22, 25
	only-if-cached 20		only-if-cached 22
	private 21		private 23
	proxy-revalidate 23		proxy-revalidate 25
	public 21		public 23
	s-maxage 23		s-maxage 25
	Cache-Control header field 18		cache entry 8
			cache key 8
			Cache-Control header field 20
	cacheable 5		cacheable 5
	E		E
	Expires header field 24		Expires header field 26
	explicit expiration time 6		explicit expiration time 6
	F		F
	first-hand 6		first-hand 6
	fresh 6		fresh 6
	freshness lifetime 6		freshness lifetime 6
	G		G
	Grammar		Grammar
	Age 18		Age 20
	Cache-Control 19		Cache-Control 21
	cache-extension 19		cache-extension 21
	cache-request-directive 19		cache-request-directive 21
	cache-response-directive 21		cache-response-directive 23
	delta-seconds 8		delta-seconds 8
	Expires 25		Expires 27
	extension-pragma 25		extension-pragma 27
	Pragma 25		Pragma 27
	pragma-directive 25		pragma-directive 27
	Vary 26		Vary 28
	warn-agent 27		warn-agent 29
	warn-code 27		warn-code 29
	warn-date 27		warn-date 29
	warn-text 27		warn-text 29
	Warning 27		Warning 29
	warning-value 27		warning-value 29
	H		H
	Header Fields		Header Fields
	Age 18		Age 20
	Cache-Control 18		Cache-Control 20
	Expires 24		Expires 26
	Pragma 25		Pragma 27
	Vary 26		Vary 28
	Warning 27		Warning 29
	heuristic expiration time 6		heuristic expiration time 6
	M		M
	max-age		max-age
	Cache Directive 20, 23		Cache Directive 21, 25
	max-stale		max-stale
	Cache Directive 20		Cache Directive 22
	min-fresh		min-fresh
	Cache Directive 20
	must-revalidate
	Cache Directive 22		Cache Directive 22
			must-revalidate
			Cache Directive 24
	N		N
	no-cache		no-cache
	Cache Directive 19, 21		Cache Directive 21, 23
	no-store		no-store
	Cache Directive 19, 22		Cache Directive 21, 24
	no-transform		no-transform
	Cache Directive 20, 23		Cache Directive 22, 25
	O		O
	only-if-cached		only-if-cached
	Cache Directive 20		Cache Directive 22
	P		P
	Pragma header field 25		Pragma header field 27
	private		private
	Cache Directive 21		Cache Directive 23
	private cache 5		private cache 5
	proxy-revalidate		proxy-revalidate
	Cache Directive 23		Cache Directive 25
	public		public
	Cache Directive 21		Cache Directive 23
	S		S
	s-maxage		s-maxage
	Cache Directive 23		Cache Directive 25
	shared cache 5		shared cache 5
	stale 6		stale 6
			strong validator 7
	V		V
	validator 6		validator 6
	Vary header field 26		strong 7
			Vary header field 28
	W		W
	Warning header field 27		Warning header field 29
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
End of changes. 66 change blocks.
	199 lines changed or deleted		308 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/