draft-ietf-httpbis-p4-conditional-08.txt		draft-ietf-httpbis-p4-conditional-09.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: April 29, 2010 J. Mogul		Expires: September 9, 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
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	October 26, 2009		March 8, 2010
	HTTP/1.1, part 4: Conditional Requests		HTTP/1.1, part 4: Conditional Requests
	draft-ietf-httpbis-p4-conditional-08		draft-ietf-httpbis-p4-conditional-09
			Abstract
			The Hypertext Transfer Protocol (HTTP) is an application-level
			protocol for distributed, collaborative, hypermedia information
			systems. HTTP has been in use by the World Wide Web global
			information initiative since 1990. This document is Part 4 of the
			seven-part specification that defines the protocol referred to as
			"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
			request header fields for indicating conditional requests and the
			rules for constructing responses to those requests.
			Editorial Note (To be removed by RFC Editor)
			Discussion of this draft should take place on the HTTPBIS working
			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
			documents (including fancy diffs) can be found at
			<http://tools.ietf.org/wg/httpbis/>.
			The changes in this draft are summarized in Appendix C.10.
	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.
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	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."
	skipping to change at page 2, line 4		skipping to change at page 2, line 15
	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 April 29, 2010.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	The Hypertext Transfer Protocol (HTTP) is an application-level		described in the BSD License.
	protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 4 of the
	seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
	request header fields for indicating conditional requests and the
	rules for constructing responses to those requests.
	Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working
	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
	documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.9.		This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5		1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
	1.2.2. ABNF Rules defined in other Parts of the		1.2.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 5		Specification . . . . . . . . . . . . . . . . . . . . 5
	2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
	skipping to change at page 3, line 48		skipping to change at page 3, line 48
	publication) . . . . . . . . . . . . . . . . . . . . 20		publication) . . . . . . . . . . . . . . . . . . . . 20
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20
	C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21		C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21
	C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21		C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21
	C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21		C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21
	C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21		C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21
	C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22		C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22
	C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22		C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22
	C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22		C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22
	C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22		C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22
			C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 22
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 response metadata for indicating		This document defines HTTP/1.1 response metadata for indicating
	potential changes to payload content, including modification time		potential changes to payload content, including modification time
	stamps and opaque entity-tags, and the HTTP conditional request		stamps and opaque entity-tags, and the HTTP conditional request
	mechanisms that allow preconditions to be placed on a request method.		mechanisms that allow preconditions to be placed on a request method.
	Conditional GET requests allow for efficient cache updates. Other		Conditional GET requests allow for efficient cache updates. Other
	conditional request methods are used to protect against overwriting		conditional request methods are used to protect against overwriting
	or misunderstanding the state of a resource that has been changed		or misunderstanding the state of a resource that has been changed
	skipping to change at page 10, line 22		skipping to change at page 10, line 22
	lead to serious problems.		lead to serious problems.
	In other words, the preferred behavior for an HTTP/1.1 origin server		In other words, the preferred behavior for an HTTP/1.1 origin server
	is to send both a strong entity tag and a Last-Modified value.		is to send both a strong entity tag and a Last-Modified value.
	In order to be legal, a strong entity tag MUST change whenever the		In order to be legal, a strong entity tag MUST change whenever the
	associated entity changes in any way. A weak entity tag SHOULD		associated entity changes in any way. A weak entity tag SHOULD
	change whenever the associated entity changes in a semantically		change whenever the associated entity changes in a semantically
	significant way.		significant way.
	Note: in order to provide semantically transparent caching, an		Note: In order to provide semantically transparent caching, an
	origin server must avoid reusing a specific strong entity tag		origin server must avoid reusing a specific strong entity tag
	value for two different entities, or reusing a specific weak		value for two different entities, or reusing a specific weak
	entity tag value for two semantically different entities. Cache		entity tag value for two semantically different entities. Cache
	entries might persist for arbitrarily long periods, regardless of		entries might persist for arbitrarily long periods, regardless of
	expiration times, so it might be inappropriate to expect that a		expiration times, so it might be inappropriate to expect that a
	cache will never again attempt to validate an entry using a		cache will never again attempt to validate an entry using a
	validator that it obtained at some point in the past.		validator that it obtained at some point in the past.
	HTTP/1.1 clients:		HTTP/1.1 clients:
	o If an entity tag has been provided by the origin server, MUST use		o MUST use that entity tag in any cache-conditional request (using
	that entity tag in any cache-conditional request (using If-Match		If-Match or If-None-Match) if an entity tag has been provided by
	or If-None-Match).		the origin server.
	o If only a Last-Modified value has been provided by the origin		o SHOULD use the Last-Modified value in non-subrange cache-
	server, SHOULD use that value in non-subrange cache-conditional		conditional requests (using If-Modified-Since) if only a Last-
	requests (using If-Modified-Since).		Modified value has been provided by the origin server.
	o If only a Last-Modified value has been provided by an HTTP/1.0		o MAY use the Last-Modified value in subrange cache-conditional
	origin server, MAY use that value in subrange cache-conditional		requests (using If-Unmodified-Since) if only a Last-Modified value
	requests (using If-Unmodified-Since:). The user agent SHOULD		has been provided by an HTTP/1.0 origin server. The user agent
	provide a way to disable this, in case of difficulty.		SHOULD provide a way to disable this, in case of difficulty.
	o If both an entity tag and a Last-Modified value have been provided		o SHOULD use both validators in cache-conditional requests if both
	by the origin server, SHOULD use both validators in cache-		an entity tag and a Last-Modified value have been provided by the
	conditional requests. This allows both HTTP/1.0 and HTTP/1.1		origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
	caches to respond appropriately.		respond appropriately.
	An HTTP/1.1 origin server, upon receiving a conditional request that		An HTTP/1.1 origin server, upon receiving a conditional request that
	includes both a Last-Modified date (e.g., in an If-Modified-Since or		includes both a Last-Modified date (e.g., in an If-Modified-Since or
	If-Unmodified-Since header field) and one or more entity tags (e.g.,		If-Unmodified-Since header field) and one or more entity tags (e.g.,
	in an If-Match, If-None-Match, or If-Range header field) as cache		in an If-Match, If-None-Match, or If-Range header field) as cache
	validators, MUST NOT return a response status of 304 (Not Modified)		validators, MUST NOT return a response status of 304 (Not Modified)
	unless doing so is consistent with all of the conditional header		unless doing so is consistent with all of the conditional header
	fields in the request.		fields in the request.
	An HTTP/1.1 caching proxy, upon receiving a conditional request that		An HTTP/1.1 caching proxy, upon receiving a conditional request that
	skipping to change at page 15, line 17		skipping to change at page 15, line 17
	6.4. If-None-Match		6.4. If-None-Match
	The "If-None-Match" request-header field is used to make a request		The "If-None-Match" request-header field is used to make a request
	method conditional. A client that has one or more entities		method conditional. A client that has one or more entities
	previously obtained from the resource can verify that none of those		previously obtained from the resource can verify that none of those
	entities is current by including a list of their associated entity		entities is current by including a list of their associated entity
	tags in the If-None-Match header field.		tags in the If-None-Match header field.
	This allows efficient updates of cached information with a minimum		This allows efficient updates of cached information with a minimum
	amount of transaction overhead. It is also used to prevent a method		amount of transaction overhead. It is also used to prevent a method
	(e.g. PUT) from inadvertently modifying an existing resource when		(e.g., PUT) from inadvertently modifying an existing resource when
	the client believes that the resource does not exist.		the client believes that the resource does not exist.
	As a special case, the value "*" matches any current entity of the		As a special case, the value "*" matches any current entity of the
	resource.		resource.
	If-None-Match = "If-None-Match" ":" OWS If-None-Match-v		If-None-Match = "If-None-Match" ":" OWS If-None-Match-v
	If-None-Match-v = "*" / 1#entity-tag		If-None-Match-v = "*" / 1#entity-tag
	If any of the entity tags match the entity tag of the entity that		If any of the entity tags match the entity tag of the entity that
	would have been returned in the response to a similar GET request		would have been returned in the response to a similar GET request
	skipping to change at page 18, line 46		skipping to change at page 18, line 46
	9. Acknowledgments		9. Acknowledgments
	10. References		10. References
	10.1. Normative References		10.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-08		and Message Parsing", draft-ietf-httpbis-p1-messaging-09
	(work in progress), October 2009.		(work in progress), March 2010.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-08 (work		Partial Responses", draft-ietf-httpbis-p5-range-09 (work
	in progress), October 2009.		in progress), March 2010.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] 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.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-08 (work in		6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
	progress), October 2009.		progress), March 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	10.2. Informative References		10.2. Informative References
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	skipping to change at page 22, line 44		skipping to change at page 22, line 44
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on		o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
	non-GET requests" (If-Match still was defined to require strong		non-GET requests" (If-Match still was defined to require strong
	matching)		matching)
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
	registrations for optional status codes"		registrations for optional status codes"
			C.10. Since draft-ietf-httpbis-p4-conditional-08
			No significant changes.
	Index		Index
	3		3
	304 Not Modified (status code) 6		304 Not Modified (status code) 6
	4		4
	412 Precondition Failed (status code) 6		412 Precondition Failed (status code) 6
	E		E
	ETag header 11		ETag header 11
End of changes. 21 change blocks.
	63 lines changed or deleted		75 lines changed or added
This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/