draft-ietf-httpbis-p6-cache-06.txt		draft-ietf-httpbis-p6-cache-07.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Expires: September 10, 2009 J. Mogul		Expires: January 14, 2010 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
			M. Nottingham, Ed.
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 9, 2009		July 13, 2009
	HTTP/1.1, part 6: Caching		HTTP/1.1, part 6: Caching
	draft-ietf-httpbis-p6-cache-06		draft-ietf-httpbis-p6-cache-07
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 2, line 4		skipping to change at page 2, line 6
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 10, 2009.		This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 41		skipping to change at page 2, line 44
	or indicate cacheable response messages.		or indicate cacheable response messages.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.7.		The changes in this draft are summarized in Appendix C.8.
	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 . . . . . . . . . . . . . . . . . . . . . . . 6		1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	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
	skipping to change at page 3, line 27		skipping to change at page 3, line 27
	2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8		2.1.1. Storing Partial and Incomplete Responses . . . . . . . 8
	2.2. Constructing Responses from Caches . . . . . . . . . . . . 8		2.2. Constructing Responses from Caches . . . . . . . . . . . . 8
	2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9		2.3. Freshness Model . . . . . . . . . . . . . . . . . . . . . 9
	2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10		2.3.1. Calculating Freshness Lifetime . . . . . . . . . . . . 10
	2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11		2.3.2. Calculating Age . . . . . . . . . . . . . . . . . . . 11
	2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13		2.3.3. Serving Stale Responses . . . . . . . . . . . . . . . 13
	2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13		2.4. Validation Model . . . . . . . . . . . . . . . . . . . . . 13
	2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14		2.5. Request Methods that Invalidate . . . . . . . . . . . . . 14
	2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15		2.6. Caching Negotiated Responses . . . . . . . . . . . . . . . 15
	2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16		2.7. Combining Responses . . . . . . . . . . . . . . . . . . . 16
	3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 16		3. Header Field Definitions . . . . . . . . . . . . . . . . . . . 17
	3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		3.1. Age . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17		3.2. Cache-Control . . . . . . . . . . . . . . . . . . . . . . 17
	3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18		3.2.1. Request Cache-Control Directives . . . . . . . . . . . 18
	3.2.2. Response Cache-Control Directives . . . . . . . . . . 20		3.2.2. Response Cache-Control Directives . . . . . . . . . . 20
	3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22		3.2.3. Cache Control Extensions . . . . . . . . . . . . . . . 22
	3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23		3.3. Expires . . . . . . . . . . . . . . . . . . . . . . . . . 23
	3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 23		3.4. Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		3.5. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25		3.6. Warning . . . . . . . . . . . . . . . . . . . . . . . . . 25
	4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28		4. History Lists . . . . . . . . . . . . . . . . . . . . . . . . 28
	skipping to change at page 4, line 9		skipping to change at page 4, line 9
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 31
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 33		publication) . . . . . . . . . . . . . . . . . . . . 33
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 33
	C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33		C.2. Since draft-ietf-httpbis-p6-cache-00 . . . . . . . . . . . 33
	C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34		C.3. Since draft-ietf-httpbis-p6-cache-01 . . . . . . . . . . . 34
	C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34		C.4. Since draft-ietf-httpbis-p6-cache-02 . . . . . . . . . . . 34
	C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34		C.5. Since draft-ietf-httpbis-p6-cache-03 . . . . . . . . . . . 34
	C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35		C.6. Since draft-ietf-httpbis-p6-cache-04 . . . . . . . . . . . 35
	C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35		C.7. Since draft-ietf-httpbis-p6-cache-05 . . . . . . . . . . . 35
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35		C.8. Since draft-ietf-httpbis-p6-cache-06 . . . . . . . . . . . 35
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	HTTP is typically used for distributed information systems, where		HTTP is typically used for distributed information systems, where
	performance can be improved by the use of response caches. This		performance can be improved by the use of response caches. This
	document defines aspects of HTTP/1.1 related to caching and reusing		document defines aspects of HTTP/1.1 related to caching and reusing
	response messages.		response messages.
	1.1. Purpose		1.1. Purpose
	skipping to change at page 7, line 39		skipping to change at page 7, line 39
	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 4.2>		field-name = <field-name, defined in [Part1], Section 4.2>
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
	port = <port, defined in [Part1], Section 2.1>		port = <port, defined in [Part1], Section 2.1>
	pseudonym = <pseudonym, defined in [Part1], Section 8.9>		pseudonym = <pseudonym, defined in [Part1], Section 8.9>
	uri-host = <uri-host, defined in [Part1], Section 2.1>		uri-host = <uri-host, defined in [Part1], Section 2.1>
	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:
	skipping to change at page 8, line 45		skipping to change at page 8, line 45
	A cache that does not support the Range and Content-Range headers		A cache that does not support the Range and Content-Range headers
	MUST NOT store incomplete or partial responses.		MUST NOT store incomplete or partial responses.
	2.2. Constructing Responses from Caches		2.2. Constructing Responses from Caches
	For a presented request, a cache MUST NOT return a stored response,		For a presented request, a cache MUST NOT return a stored response,
	unless:		unless:
	o The presented Request-URI and that of the stored response match		o The presented Request-URI and that of the stored response match
	(see [[anchor1: TBD]]), and		([[TODO-Request-URI: Need to find a new term for this, as Part 1
			doesn't define Request-URI anymore; the new term request-target
			does not work for this.]]), and
	o the request method associated with the stored response allows it		o the request method associated with the stored response allows it
	to be used for the presented request, and		to be used for the presented request, and
	o selecting request-headers nominated by the stored response (if		o selecting request-headers nominated by the stored response (if
	any) match those presented (see Section 2.6), and		any) match those presented (see Section 2.6), and
	o the presented request and stored response are free from directives		o the presented request and stored response are free from directives
	that would prevent its use (see Section 3.2 and Section 3.4), and		that would prevent its use (see Section 3.2 and Section 3.4), and
	o the stored response is either:		o the stored response is either:
	* fresh (see Section 2.3), or		* fresh (see Section 2.3), or
	* allowed to be served stale (see Section 2.3.3), or		* allowed to be served stale (see Section 2.3.3), or
	* successfully validated (see Section 2.4).		* successfully validated (see Section 2.4).
	skipping to change at page 9, line 15		skipping to change at page 9, line 18
	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).
	[[anchor2: TODO: define method cacheability for GET, HEAD and POST in		[[TODO-method-cacheability: define method cacheability for GET, HEAD
	p2-semantics.]]		and POST in p2-semantics.]]
	When a stored response is used to satisfy a request, caches MUST		When a stored response is used to satisfy a request, caches MUST
	include a single Age header field Section 3.1 in the response with a		include a single Age header field (Section 3.1) in the response with
	value equal to the stored response's current_age; see Section 2.3.2.		a value equal to the stored response's current_age; see
	[[anchor3: DISCUSS: this currently includes successfully validated		Section 2.3.2. [[anchor1: DISCUSS: this currently includes
	responses.]]		successfully validated responses.]]
	Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST		Requests with methods that are unsafe (Section 7.1.1 of [Part2]) MUST
	be written through the cache to the origin server; i.e., A cache must		be written through the cache to the origin server; i.e., A cache must
	not reply to such a request before having forwarded the request and		not reply to such a request before having forwarded the request and
	having received a corresponding response.		having received a corresponding response.
	Also, note that unsafe requests might invalidate already stored		Also, note that unsafe requests might invalidate already stored
	responses; see Section 2.5.		responses; see Section 2.5.
	Caches MUST use the most recent response (as determined by the Date		Caches MUST use the most recent response (as determined by the Date
	header) when more than one suitable response is stored. They can		header) when more than one suitable response is stored. They can
	also forward a request with "Cache-Control: max-age=0" or "Cache-		also forward a request with "Cache-Control: max-age=0" or "Cache-
	Control: no-cache" to disambiguate which response to use.		Control: no-cache" to disambiguate which response to use.
	[[anchor4: TODO: end-to-end and hop-by-hop headers, non-modifiable		[[TODO-header-properties: end-to-end and hop-by-hop headers, non-
	headers removed; re-spec in p1]]		modifiable headers removed; re-spec in p1]]
	2.3. Freshness Model		2.3. Freshness Model
	When a response is "fresh" in the cache, it can be used to satisfy		When a response is "fresh" in the cache, it can be used to satisfy
	subsequent requests without contacting the origin server, thereby		subsequent requests without contacting the origin server, thereby
	improving efficiency.		improving efficiency.
	The primary mechanism for determining freshness is for an origin		The primary mechanism for determining freshness is for an origin
	server to provide an explicit expiration time in the future, using		server to provide an explicit expiration time in the future, using
	either the Expires header (Section 3.3) or the max-age response cache		either the Expires header (Section 3.3) or the max-age response cache
	directive (Section 3.2.2). Generally, origin servers will assign		directive (Section 3.2.2). Generally, origin servers will assign
	future explicit expiration times to responses in the belief that the		future explicit expiration times to responses in the belief that the
	entity is not likely to change in a semantically significant way		entity is not likely to change in a semantically significant way
	before the expiration time is reached.		before the expiration time is reached.
	If an origin server wishes to force a cache to validate every		If an origin server wishes to force a cache to validate every
	request, it can assign an explicit expiration time in the past. This		request, it can assign an explicit expiration time in the past. This
	means that the response is always stale, so that caches should		means that the response is always stale, so that caches should
	validate it before using it for subsequent requests. [[anchor5: This		validate it before using it for subsequent requests. [[anchor2: This
	wording may cause confusion, because the response may still be served		wording may cause confusion, because the response may still be served
	stale.]]		stale.]]
	Since origin servers do not always provide explicit expiration times,		Since origin servers do not always provide explicit expiration times,
	HTTP caches may also assign heuristic expiration times when they are		HTTP caches may also assign heuristic expiration times when they are
	not specified, employing algorithms that use other header values		not specified, employing algorithms that use other header values
	(such as the Last-Modified time) to estimate a plausible expiration		(such as the Last-Modified time) to estimate a plausible expiration
	time. The HTTP/1.1 specification does not provide specific		time. The HTTP/1.1 specification does not provide specific
	algorithms, but does impose worst-case constraints on their results.		algorithms, but does impose worst-case constraints on their results.
	skipping to change at page 10, line 32		skipping to change at page 10, line 35
	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 may need to influence freshness calculation.		Additionally, clients may 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.
	[[anchor6: ISSUE: there are not requirements directly applying to		[[anchor3: ISSUE: there are not requirements directly applying to
	cache-request-directives and freshness.]]		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
	skipping to change at page 11, line 30		skipping to change at page 11, line 33
	When a heuristic is used to calculate freshness lifetime, the cache		When a heuristic is used to calculate freshness lifetime, the cache
	SHOULD attach a Warning header with a 113 warn-code to the response		SHOULD attach a Warning header with a 113 warn-code to the response
	if its current_age is more than 24 hours and such a warning is not		if its current_age is more than 24 hours and such a warning is not
	already present.		already present.
	Also, if the response has a Last-Modified header (Section 6.6 of		Also, if the response has a Last-Modified header (Section 6.6 of
	[Part4]), the heuristic expiration value SHOULD be no more than some		[Part4]), the heuristic expiration value SHOULD be no more than some
	fraction of the interval since that time. A typical setting of this		fraction of the interval since that time. A typical setting of this
	fraction might be 10%.		fraction might be 10%.
	[[anchor7: REVIEW: took away HTTP/1.0 query string heuristic		[[anchor4: REVIEW: took away HTTP/1.0 query string heuristic
	uncacheability.]]		uncacheability.]]
	2.3.2. Calculating Age		2.3.2. Calculating Age
	HTTP/1.1 uses the Age response-header to convey the estimated age of		HTTP/1.1 uses the Age response-header to convey the estimated age of
	the response message when obtained from a cache. The Age field value		the response message when obtained from a cache. The Age field value
	is the cache's estimate of the amount of time since the response was		is the cache's estimate of the amount of time since the response was
	generated or validated by the origin server. In essence, the Age		generated or validated by the origin server. In essence, the Age
	value is the sum of the time that the response has been resident in		value is the sum of the time that the response has been resident in
	each of the caches along the path from the origin server, plus the		each of the caches along the path from the origin server, plus the
	skipping to change at page 13, line 36		skipping to change at page 13, line 50
	If a cache receives a first-hand response (either an entire response,		If a cache receives a first-hand response (either an entire response,
	or a 304 (Not Modified) response) that it would normally forward to		or a 304 (Not Modified) response) that it would normally forward to
	the requesting client, and the received response is no longer fresh,		the requesting client, and the received response is no longer fresh,
	the cache SHOULD forward it to the requesting client without adding a		the cache SHOULD forward it to the requesting client without adding a
	new Warning (but without removing any existing Warning headers). A		new Warning (but without removing any existing Warning headers). A
	cache SHOULD NOT attempt to validate a response simply because that		cache SHOULD NOT attempt to validate a response simply because that
	response became stale in transit.		response became stale in transit.
	2.4. Validation Model		2.4. Validation Model
	Checking with the origin server to see if a stale or otherwise		When a cache has one or more stored responses for a requested URI,
	unusable cached response can be reused is called "validating" or		but cannot serve any of them (e.g., because they are not fresh, or
	"revalidating." Doing so potentially avoids the overhead of		one cannot be selected; see Section 2.6), it can use the conditional
	retransmitting the response body when the stored response is valid.		request mechanism [Part4] in the forwarded request to give the origin
			server an opportunity to both select a valid stored response to be
			used, and to update it. This process is known as "validating" or
			"revalidating" the stored response.
	HTTP's conditional request mechanism [Part4] is used for this		When sending such a conditional request, the cache SHOULD add an If-
	purpose. When a stored response includes one or more validators,		Modified-Since header whose value is that of the Last-Modified header
	such as the field values of an ETag or Last-Modified header field,		from the selected (see Section 2.6) stored response, if available.
	then a validating request SHOULD be made conditional to those field
	values.		Additionally, the cache SHOULD add an If-None-Match header whose
			value is that of the ETag header(s) from all responses stored for the
			requested URI, if present. However, if any of the stored responses
			contains only partial content, its entity-tag SHOULD NOT be included
			in the If-None-Match header field unless the request is for a range
			that would be fully satisfied by that stored response.
	A 304 (Not Modified) response status code indicates that the stored		A 304 (Not Modified) response status code indicates that the stored
	response can be updated and reused; see Section 2.7.		response can be updated and reused; see Section 2.7.
	If instead the cache receives a full response (i.e., one with a		A full response (i.e., one with a response body) indicates that none
	response body), it is used to satisfy the request and replace the		of the stored responses nominated in the conditional request is
	stored response. [[anchor8: Should there be a requirement here?]]		suitable. Instead, the full response is used both to satisfy the
			request and replace the stored response. [[anchor5: Should there be a
			requirement here?]]
	If a cache receives a 5xx response while attempting to validate a		If a cache receives a 5xx response while attempting to validate a
	response, it MAY either forward this response to the requesting		response, it MAY either forward this response to the requesting
	client, or act as if the server failed to respond. In the latter		client, or act as if the server failed to respond. In the latter
	case, it MAY return a previously stored response (which SHOULD		case, it MAY return a previously stored response (see Section 2.3.3).
	include the 111 warn-code; see Section 3.6) unless the stored
	response includes the "must-revalidate" cache directive (see		If a cache receives a successful response whose Content-Location
	Section 2.3.3).		field matches that of an existing stored response for the same
			Request-URI, whose entity-tag differs from that of the existing
			stored response, and whose Date is more recent than that of the
			existing response, the existing response SHOULD NOT be returned in
			response to future requests and SHOULD be deleted from the cache.
			[[anchor6: DISCUSS: Not sure if this is necessary.]]
	2.5. Request Methods that Invalidate		2.5. Request Methods that Invalidate
	Because unsafe methods (Section 7.1.1 of [Part2]) have the potential		Because unsafe methods (Section 7.1.1 of [Part2]) have the potential
	for changing state on the origin server, intervening caches can use		for changing state on the origin server, intervening caches can use
	them to keep their contents up-to-date.		them to keep their contents up-to-date.
	The following HTTP methods MUST cause a cache to invalidate the		The following HTTP methods MUST cause a cache to invalidate the
	Request-URI as well as the Location and Content-Location headers (if		Request-URI as well as the URI(s) in the Location and Content-
	present):		Location headers (if present):
	o PUT		o PUT
	o DELETE		o DELETE
	o POST		o POST
	An invalidation based on the URI in a Location or Content-Location		An invalidation based on a URI from a Location or Content-Location
	header MUST NOT be performed if the host part of that URI differs		header MUST NOT be performed if the host part of that URI differs
	from the host part in the Request-URI. This helps prevent denial of		from the host part in the Request-URI. This helps prevent denial of
	service attacks.		service attacks.
	[[anchor9: TODO: "host part" needs to be specified better.]]		[[anchor7: TODO: "host part" needs to be specified better.]]
	A cache that passes through requests for methods it does not		A cache that passes through requests for methods it does not
	understand SHOULD invalidate the Request-URI.		understand SHOULD invalidate the Request-URI.
	Here, "invalidate" means that the cache will either remove all stored		Here, "invalidate" means that the cache will either remove all stored
	responses related to the Request-URI, or will mark these as "invalid"		responses related to the Request-URI, or will mark these as "invalid"
	and in need of a mandatory validation before they can be returned in		and in need of a mandatory validation before they can be returned in
	response to a subsequent request.		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.
	[[anchor10: TODO: specify that only successful (2xx, 3xx?) responses		[[anchor8: TODO: specify that only successful (2xx, 3xx?) responses
	invalidate.]]		invalidate.]]
	2.6. Caching Negotiated Responses		2.6. Caching Negotiated Responses
	Use of server-driven content negotiation (Section 4.1 of [Part3])
	alters the conditions under which a cache can use the response for
	subsequent requests.
	When a cache receives a request that can be satisfied by a stored		When a cache receives a request that can be satisfied by a stored
	response that includes a Vary header field (Section 3.5), it MUST NOT		response that has a Vary header field (Section 3.5), it MUST NOT use
	use that response unless all of the selecting request-headers in the		that response unless all of the selecting request-headers nominated
	presented request match the corresponding stored request-headers from		by the Vary header match in both the original request (i.e., that
	the original request.		associated with the stored response), and the presented request.
	The selecting request-headers from two requests are defined to match		The selecting request-headers from two requests are defined to match
	if and only if the selecting request-headers in the first request can		if and only if the selecting request-headers in the first request can
	be transformed to the selecting request-headers in the second request		be transformed to the selecting request-headers in the second request
	by adding or removing linear white space [[anchor11: [ref]]] at		by adding or removing linear white space [[anchor9: [ref]]] at places
	places where this is allowed by the corresponding ABNF, and/or		where this is allowed by the corresponding ABNF, and/or combining
	combining multiple message-header fields with the same field name		multiple message-header fields with the same field name following the
	following the rules about message headers in Section 4.2 of [Part1].		rules about message headers in Section 4.2 of [Part1].
	[[anchor12: DISCUSS: header-specific canonicalisation]]
			If a header field is absent from a request, it can only match another
			request if it is 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.
	If no stored response matches, the cache MAY forward the presented		The stored response with matching selecting request-headers is known
	request to the origin server in a conditional request, and SHOULD		as the selected response.
	include all ETags stored with potentially suitable responses in an
	If-None-Match request header. If the server responds with 304 (Not
	Modified) and includes an entity tag or Content-Location that
	indicates the entity to be used, that cached response MUST be used to
	satisfy the presented request, and SHOULD be used to update the
	corresponding stored response; see Section 2.7.
	If any of the stored responses contains only partial content, its
	entity-tag SHOULD NOT be included in the If-None-Match header field
	unless the request is for a range that would be fully satisfied by
	that stored response.
	If a cache receives a successful response whose Content-Location		If no selected response is available, the cache MAY forward the
	field matches that of an existing stored response for the same		presented request to the origin server in a conditional request; see
	Request-URI, whose entity-tag differs from that of the existing		Section 2.4.
	stored response, and whose Date is more recent than that of the
	existing response, the existing response SHOULD NOT be returned in
	response to future requests and SHOULD be deleted from the
	cache.[[anchor13: DISCUSS: Not sure if this is necessary.]]
	2.7. Combining Responses		2.7. 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, it needs to update the stored response with the		Content) response (in this section, the "new" response"), it needs to
	new one, so that the updated response can be sent to the client.		created an updated response by combining the stored response with the
			new one, so that the updated response can be used to satisfy the
			request.
	If the status code is 304 (Not Modified), the cache SHOULD use the		If the new response contains an ETag, it identifies the stored
	stored entity-body as the updated entity-body. If the status code is		response to use. [[anchor10: may need language about Content-Location
	206 (Partial Content) and the ETag or Last-Modified headers match		here]][[anchor11: cover case where INM with multiple etags was sent]]
	exactly, the cache MAY combine the stored entity-body in the stored
	response with the updated entity-body received in the response and
	use the result as the updated entity-body (see Section 4 of [Part5]).
	The stored response headers are used for the updated response, except		If the status code is 206 (partial content), both the stored and new
	that		responses MUST have ETags, and those ETags MUST match using the
			strong comparison function (see Section 4 of [Part4]). Otherwise,
			the responses MUST NOT be combined.
			The stored response headers are used as those of the updated
			response, except that
	o any stored Warning headers with warn-code 1xx (see Section 3.6)		o any stored Warning headers with warn-code 1xx (see Section 3.6)
	MUST be deleted from the stored response and the forwarded		MUST be deleted from the stored response and the updated response.
	response.
	o any stored Warning headers with warn-code 2xx MUST be retained in		o any stored Warning headers with warn-code 2xx MUST be retained in
	the stored response and the forwarded response.		the stored response and the updated response.
	o any headers provided in the 304 or 206 response MUST replace the		o any headers provided in the new response MUST replace the
	corresponding headers from the stored response.		corresponding headers from the stored response.
	A cache MUST also replace any stored headers with corresponding		If a header field-name in the new response matches more than one
	headers received in the incoming response, except for Warning headers		header in the stored response, all such stored headers MUST be
	as described immediately above. If a header field-name in the		replaced.
	incoming response matches more than one header in the stored
	response, all such old headers MUST be replaced. It MAY store the
	combined entity-body.
	[[anchor14: ISSUE: discuss how to handle HEAD updates]]		The updated response can [[[[anchor12: requirement?]]]] be used to
			replace the stored response in cache. In the case of a 206 response,
			the combined entity-body MAY be stored.
			[[anchor13: ISSUE: discuss how to handle HEAD updates]]
	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.
	For entity-header fields, both sender and recipient refer to either		For entity-header fields, both sender and recipient refer to either
	the client or the server, depending on who sends and who receives the		the client or the server, depending on who sends and who receives the
	entity.		entity.
	3.1. Age		3.1. Age
	The response-header field "Age" conveys the sender's estimate of the		The response-header field "Age" conveys the sender's estimate of the
	amount of time since the response (or its validation) was generated		amount of time since the response (or its validation) was generated
	at the origin server. Age values are calculated as specified in		at the origin server. Age values are calculated as specified in
	Section 2.3.2.		Section 2.3.2.
	Age = "Age" ":" OWS Age-v		Age = "Age" ":" OWS Age-v
	Age-v = delta-seconds		Age-v = delta-seconds
	Age field-values are non-negative decimal integers, representing time		Age field-values are non-negative integers, representing time in
	in seconds.		seconds.
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	If a cache receives a value larger than the largest positive integer		If a cache receives a value larger than the largest positive integer
	it can represent, or if any of its age calculations overflows, it		it can represent, or if any of its age calculations overflows, it
	MUST transmit an Age header with a field-value of 2147483648 (2^31).		MUST transmit an Age header with a field-value of 2147483648 (2^31).
	Caches SHOULD use an arithmetic type of at least 31 bits of range.		Caches SHOULD use an arithmetic type of at least 31 bits of range.
	The presence of an Age header field in a response implies that a		The presence of an Age header field in a response implies that a
	response is not first-hand. However, the converse is not true, since		response is not first-hand. However, the converse is not true, since
	skipping to change at page 19, line 13		skipping to change at page 19, line 21
	client is not willing to accept a stale response.		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. [[anchor15: of any staleness? --mnot]]		stale response of any age. [[anchor14: of any staleness? --mnot]]
	min-fresh		min-fresh
	The min-fresh request directive indicates that the client is		The min-fresh request directive indicates that the client is
	willing to accept a response whose freshness lifetime is no less		willing to accept a response whose freshness lifetime is no less
	than its current age plus the specified time in seconds. That is,		than its current age plus the specified time in seconds. That is,
	the client wants a response that will still be fresh for at least		the client wants a response that will still be fresh for at least
	the specified number of seconds.		the specified number of seconds.
	no-transform		no-transform
	skipping to change at page 20, line 51		skipping to change at page 20, line 51
	no-cache		no-cache
	The no-cache response directive indicates that the response MUST		The no-cache response directive indicates that the response MUST
	NOT be used to satisfy a subsequent request without successful		NOT be used to satisfy a subsequent request without successful
	validation on the origin server. This allows an origin server to		validation on the origin server. This allows an origin server to
	prevent caching even by caches that have been configured to return		prevent caching even by caches that have been configured to return
	stale responses.		stale responses.
	If the no-cache response directive specifies one or more field-		If the no-cache response directive specifies one or more field-
	names, this requirement is limited to the field-values assosicated		names, this requirement is limited to the field-values associated
	with the listed response headers. That is, the specified field-		with the listed response headers. That is, the specified field-
	name(s) MUST NOT be sent in the response to a subsequent request		name(s) MUST NOT be sent in the response to a subsequent request
	without successful validation on the origin server. This allows		without successful validation on the origin server. This allows
	an origin server to prevent the re-use of certain header fields in		an origin server to prevent the re-use of certain header fields in
	a response, while still allowing caching of the rest of the		a response, while still allowing caching of the rest of the
	response.		response.
	Note: Most HTTP/1.0 caches will not recognize or obey this		Note: Most HTTP/1.0 caches will not recognize or obey this
	directive.		directive.
	skipping to change at page 23, line 26		skipping to change at page 23, line 26
	The entity-header field "Expires" gives the date/time after which the		The entity-header field "Expires" gives the date/time after which the
	response is considered stale. See Section 2.3 for further discussion		response is considered stale. See Section 2.3 for further discussion
	of the freshness model.		of the freshness model.
	The presence of an Expires field does not imply that the original		The presence of an Expires field does not imply that the original
	resource will change or cease to exist at, before, or after that		resource will change or cease to exist at, before, or after that
	time.		time.
	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 3.2.1 of [Part1]; it MUST be sent in rfc1123-date format.		in Section 3.2 of [Part1]; it MUST be sent in rfc1123-date format.
	Expires = "Expires" ":" OWS Expires-v		Expires = "Expires" ":" OWS Expires-v
	Expires-v = HTTP-date		Expires-v = HTTP-date
	For example		For example
	Expires: Thu, 01 Dec 1994 16:00:00 GMT		Expires: Thu, 01 Dec 1994 16:00:00 GMT
	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
	skipping to change at page 29, line 48		skipping to change at page 29, line 48
	[ISO-8859-1]		[ISO-8859-1]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded graphic		"Information technology -- 8-bit single-byte coded graphic
	character sets -- Part 1: Latin alphabet No. 1", ISO/		character sets -- Part 1: Latin alphabet No. 1", ISO/
	IEC 8859-1:1998, 1998.		IEC 8859-1:1998, 1998.
	[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-06		and Message Parsing", draft-ietf-httpbis-p1-messaging-07
	(work in progress), March 2009.		(work in progress), July 2009.
	[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-06 (work in		Semantics", draft-ietf-httpbis-p2-semantics-07 (work in
	progress), March 2009.		progress), July 2009.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] 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 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-06		and Content Negotiation", draft-ietf-httpbis-p3-payload-07
	(work in progress), March 2009.		(work in progress), July 2009.
	[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-06 (work in		Requests", draft-ietf-httpbis-p4-conditional-07 (work in
	progress), March 2009.		progress), July 2009.
	[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-06 (work		Partial Responses", draft-ietf-httpbis-p5-range-07 (work
	in progress), March 2009.		in progress), July 2009.
	[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-06 (work in progress),		draft-ietf-httpbis-p7-auth-07 (work in progress),
	March 2009.		July 2009.
	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)		[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
	Part Three: Message Header Extensions for Non-ASCII Text",		Part Three: Message Header Extensions for Non-ASCII Text",
	RFC 2047, November 1996.		RFC 2047, November 1996.
	[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.
	skipping to change at page 31, line 20		skipping to change at page 31, line 20
	A.1. Changes from RFC 2068		A.1. Changes from RFC 2068
	A case was missed in the Cache-Control model of HTTP/1.1; s-maxage		A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
	was introduced to add this missing case. (Sections 2.1, 3.2).		was introduced to add this missing case. (Sections 2.1, 3.2).
	Transfer-coding and message lengths all interact in ways that		Transfer-coding and message lengths all interact in ways that
	required fixing exactly when chunked encoding is used (to allow for		required fixing exactly when chunked encoding is used (to allow for
	transfer encoding that may not be self delimiting); it was important		transfer encoding that may not be self delimiting); it was important
	to straighten out exactly how message lengths are computed. (see also		to straighten out exactly how message lengths are computed. (see also
	[Part1], [Part3] and [Part5]) [[anchor18: This used to refer to the		[Part1], [Part3] and [Part5]) [[anchor17: This used to refer to the
	text about non-modifiable headers, and will have to be updated later		text about non-modifiable headers, and will have to be updated later
	on. --jre]]		on. --jre]]
	Proxies should be able to add Content-Length when appropriate.		Proxies should be able to add Content-Length when appropriate.
	[[anchor19: This used to refer to the text about non-modifiable		[[anchor18: This used to refer to the text about non-modifiable
	headers, and will have to be updated later on. --jre]]		headers, and will have to be updated later on. --jre]]
	Range request responses would become very verbose if all meta-data		Range request responses would become very verbose if all meta-data
	were always returned; by allowing the server to only send needed		were always returned; by allowing the server to only send needed
	headers in a 206 response, this problem can be avoided.		headers in a 206 response, this problem can be avoided.
	(Section 2.7)		(Section 2.7)
	The Cache-Control: max-age directive was not properly defined for		The Cache-Control: max-age directive was not properly defined for
	responses. (Section 3.2.2)		responses. (Section 3.2.2)
	skipping to change at page 32, line 10		skipping to change at page 32, line 10
	Age = "Age:" OWS Age-v		Age = "Age:" OWS Age-v
	Age-v = delta-seconds		Age-v = delta-seconds
	Cache-Control = "Cache-Control:" OWS Cache-Control-v		Cache-Control = "Cache-Control:" OWS Cache-Control-v
	Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS		Cache-Control-v = *( "," OWS ) cache-directive *( OWS "," [ OWS
	cache-directive ] )		cache-directive ] )
	Expires = "Expires:" OWS Expires-v		Expires = "Expires:" OWS Expires-v
	Expires-v = HTTP-date		Expires-v = HTTP-date
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	Pragma = "Pragma:" OWS Pragma-v		Pragma = "Pragma:" OWS Pragma-v
	Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS		Pragma-v = *( "," OWS ) pragma-directive *( OWS "," [ OWS
	pragma-directive ] )		pragma-directive ] )
	Vary = "Vary:" OWS Vary-v		Vary = "Vary:" OWS Vary-v
	Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name		Vary-v = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name
	] ) )		] ) )
	skipping to change at page 35, line 42		skipping to change at page 35, line 42
	o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods		o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods
	and Caching"		and Caching"
	In addition: Final work on ABNF conversion		In addition: Final work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Add appendix containing collected and expanded ABNF, reorganize		o Add appendix containing collected and expanded ABNF, reorganize
	ABNF introduction.		ABNF introduction.
			C.8. Since draft-ietf-httpbis-p6-cache-06
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/161>: "base for
			numeric protocol elements"
			Affected issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/37>: Vary and non-
			existant headers
	Index		Index
	A		A
	age 6		age 6
	Age header 17		Age header 17
	C		C
	cache 5		cache 5
	Cache Directives		Cache Directives
	max-age 18, 21		max-age 19, 21
	max-stale 19		max-stale 19
	min-fresh 19		min-fresh 19
	must-revalidate 21		must-revalidate 21
	no-cache 18, 20		no-cache 18, 20
	no-store 18, 21		no-store 18, 21
	no-transform 19, 22		no-transform 19, 22
	only-if-cached 19		only-if-cached 19
	private 20		private 20
	proxy-revalidate 21		proxy-revalidate 21
	public 20		public 20
	skipping to change at page 37, line 16		skipping to change at page 37, line 27
	Age 17		Age 17
	Cache-Control 17		Cache-Control 17
	Expires 23		Expires 23
	Pragma 23		Pragma 23
	Vary 24		Vary 24
	Warning 25		Warning 25
	heuristic expiration time 5		heuristic expiration time 5
	M		M
	max-age		max-age
	Cache Directive 18, 21		Cache Directive 19, 21
	max-stale		max-stale
	Cache Directive 19		Cache Directive 19
	min-fresh		min-fresh
	Cache Directive 19		Cache Directive 19
	must-revalidate		must-revalidate
	Cache Directive 21		Cache Directive 21
	N		N
	no-cache		no-cache
	Cache Directive 18, 20		Cache Directive 18, 20
	skipping to change at page 39, line 30		skipping to change at page 40, line 4
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory		MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32		The Stata Center, Building 32
	32 Vassar Street		32 Vassar Street
	Cambridge, MA 02139		Cambridge, MA 02139
	USA		USA
	Email: timbl@w3.org		Email: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/		URI: http://www.w3.org/People/Berners-Lee/
	Yves Lafon (editor)		Yves Lafon (editor)
	World Wide Web Consortium		World Wide Web Consortium
	W3C / ERCIM		W3C / ERCIM
	2004, rte des Lucioles		2004, rte des Lucioles
	Sophia-Antipolis, AM 06902		Sophia-Antipolis, AM 06902
	France		France
	Email: ylafon@w3.org		Email: ylafon@w3.org
	URI: http://www.raubacapeu.net/people/yves/		URI: http://www.raubacapeu.net/people/yves/
			Mark Nottingham (editor)
			Email: mnot@mnot.net
			URI: http://www.mnot.net/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
	Phone: +49 251 2807760		Phone: +49 251 2807760
	Fax: +49 251 2807761		Fax: +49 251 2807761
	Email: julian.reschke@greenbytes.de		Email: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
End of changes. 58 change blocks.
	119 lines changed or deleted		145 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/