draft-ietf-httpbis-p4-conditional-11.txt		draft-ietf-httpbis-p4-conditional-12.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 Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: February 5, 2011 J. Mogul		Expires: April 28, 2011 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
	August 4, 2010		October 25, 2010
	HTTP/1.1, part 4: Conditional Requests		HTTP/1.1, part 4: Conditional Requests
	draft-ietf-httpbis-p4-conditional-11		draft-ietf-httpbis-p4-conditional-12
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 4 of the		information initiative since 1990. This document is Part 4 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
	request header fields for indicating conditional requests and the		request header fields for indicating conditional requests and the
	rules for constructing responses to those requests.		rules for constructing responses to those requests.
	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/3> and related		at <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.12.		The changes in this draft are summarized in Appendix C.13.
	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 February 5, 2011.		This Internet-Draft will expire on April 28, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 7		skipping to change at page 3, line 7
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5		1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . . 6
	2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Example: Entity-tags varying on Content-Negotiated		2.1. Example: Entity-tags varying on Content-Negotiated
	Resources . . . . . . . . . . . . . . . . . . . . . . . . 6		Resources . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 8
	3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7		3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 8
	3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 7		3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 8
	4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8		4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 9
	5. Rules for When to Use Entity-tags and Last-Modified Dates . . 10		5. Rules for When to Use Entity-tags and Last-Modified Dates . . 11
	6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12		6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 13
	6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14		6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15
	6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16		6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 17
	6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17		6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18
	6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18		6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19		7.1. Status Code Registration . . . . . . . . . . . . . . . . . 20
	7.2. Header Field Registration . . . . . . . . . . . . . . . . 19		7.2. Header Field Registration . . . . . . . . . . . . . . . . 20
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 19		10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	10.2. Informative References . . . . . . . . . . . . . . . . . . 20		10.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 21		publication) . . . . . . . . . . . . . . . . . . . . 22
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
	C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22		C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23
	C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22		C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23
	C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22		C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23
	C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22		C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23
	C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23		C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24
	C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23		C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24
	C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23		C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24
	C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23		C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24
	C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23		C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24
	C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23		C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24
	C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24		C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	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
	unbeknownst to the requesting client.		unbeknownst to the requesting client.
	This document is currently disorganized in order to minimize the		This document is currently disorganized in order to minimize the
	changes between drafts and enable reviewers to see the smaller errata		changes between drafts and enable reviewers to see the smaller errata
	changes. The next draft will reorganize the sections to better		changes. A future draft will reorganize the sections to better
	reflect the content. In particular, the sections on resource		reflect the content. In particular, the sections on resource
	metadata will be discussed first and then followed by each		metadata will be discussed first and then followed by each
	conditional request-header, concluding with a definition of		conditional request-header field, concluding with a definition of
	precedence and the expectation of ordering strong validator checks		precedence and the expectation of ordering strong validator checks
	before weak validator checks. It is likely that more content from		before weak validator checks. It is likely that more content from
	[Part6] will migrate to this part, where appropriate. The current		[Part6] will migrate to this part, where appropriate. The current
	mess reflects how widely dispersed these topics and associated		mess reflects how widely dispersed these topics and associated
	requirements had become in [RFC2616].		requirements had become in [RFC2616].
	1.1. Requirements		1.1. 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
	skipping to change at page 10, line 5		skipping to change at page 11, line 5
	o The validator is being compared by an origin server to the actual		o The validator is being compared by an origin server to the actual
	current validator for the representation and,		current validator for the representation and,
	o That origin server reliably knows that the associated		o That origin server reliably knows that the associated
	representation did not change twice during the second covered by		representation did not change twice during the second covered by
	the presented validator.		the presented validator.
	or		or
	o The validator is about to be used by a client in an If-Modified-		o The validator is about to be used by a client in an If-Modified-
	Since or If-Unmodified-Since header, because the client has a		Since or If-Unmodified-Since header field, because the client has
	cache entry for the associated representation, and		a cache entry for the associated representation, and
	o That cache entry includes a Date value, which gives the time when		o That cache entry includes a Date value, which gives the time when
	the origin server sent the original response, and		the origin server sent the original response, and
	o The presented Last-Modified time is at least 60 seconds before the		o The presented Last-Modified time is at least 60 seconds before the
	Date value.		Date value.
	or		or
	o The validator is being compared by an intermediate cache to the		o The validator is being compared by an intermediate cache to the
	skipping to change at page 11, line 17		skipping to change at page 12, line 17
	o SHOULD send an entity-tag validator unless it is not feasible to		o SHOULD send an entity-tag validator unless it is not feasible to
	generate one.		generate one.
	o MAY send a weak entity-tag instead of a strong entity-tag, if		o MAY send a weak entity-tag instead of a strong entity-tag, if
	performance considerations support the use of weak entity-tags, or		performance considerations support the use of weak entity-tags, or
	if it is unfeasible to send a strong entity-tag.		if it is unfeasible to send a strong entity-tag.
	o SHOULD send a Last-Modified value if it is feasible to send one,		o SHOULD send a Last-Modified value if it is feasible to send one,
	unless the risk of a breakdown in semantic transparency that could		unless the risk of a breakdown in semantic transparency that could
	result from using this date in an If-Modified-Since header would		result from using this date in an If-Modified-Since header field
	lead to serious problems.		would 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 representation changes in any way. A weak entity-tag		associated representation changes in any way. A weak entity-tag
	SHOULD change whenever the associated representation changes in a		SHOULD change whenever the associated representation changes in a
	semantically significant way.		semantically significant way.
	Note: In order to provide semantically transparent caching, an		Note: In order to provide semantically transparent caching, an
	skipping to change at page 13, line 23		skipping to change at page 14, line 23
	more reliable validation than modification dates in situations where		more reliable validation than modification dates in situations where
	it is inconvenient to store modification dates, where the one-second		it is inconvenient to store modification dates, where the one-second
	resolution of HTTP date values is not sufficient, or where the origin		resolution of HTTP date values is not sufficient, or where the origin
	server wishes to avoid certain paradoxes that might arise from the		server wishes to avoid certain paradoxes that might arise from the
	use of modification dates.		use of modification dates.
	The principle behind entity-tags is that only the service author		The principle behind entity-tags is that only the service author
	knows the semantics of a resource well enough to select an		knows the semantics of a resource well enough to select an
	appropriate cache validation mechanism, and the specification of any		appropriate cache validation mechanism, and the specification of any
	validator comparison function more complex than byte-equality would		validator comparison function more complex than byte-equality would
	open up a can of worms. Thus, comparisons of any other headers		open up a can of worms. Thus, comparisons of any other header fields
	(except Last-Modified, for compatibility with HTTP/1.0) are never		(except Last-Modified, for compatibility with HTTP/1.0) are never
	used for purposes of validating a cache entry.		used for purposes of validating a cache entry.
	6.2. If-Match		6.2. If-Match
	The "If-Match" request-header field is used to make a request method		The "If-Match" request-header field is used to make a request method
	conditional. A client that has one or more representations		conditional. A client that has one or more representations
	previously obtained from the resource can verify that one of those		previously obtained from the resource can verify that one of those
	representations is current by including a list of their associated		representations is current by including a list of their associated
	entity-tags in the If-Match header field.		entity-tags in the If-Match header field.
	skipping to change at page 13, line 46		skipping to change at page 14, line 46
	amount of transaction overhead. It is also used when updating		amount of transaction overhead. It is also used when updating
	resources, to prevent inadvertent modification of the wrong version		resources, to prevent inadvertent modification of the wrong version
	of a resource. As a special case, the value "*" matches any current		of a resource. As a special case, the value "*" matches any current
	representation of the resource.		representation of the resource.
	If-Match = "If-Match" ":" OWS If-Match-v		If-Match = "If-Match" ":" OWS If-Match-v
	If-Match-v = "*" / 1#entity-tag		If-Match-v = "*" / 1#entity-tag
	If any of the entity-tags match the entity-tag of the representation		If any of the entity-tags match the entity-tag of the representation
	that would have been returned in the response to a similar GET		that would have been returned in the response to a similar GET
	request (without the If-Match header) on that resource, or if "*" is		request (without the If-Match header field) on that resource, or if
	given and any current representation exists for that resource, then		"*" is given and any current representation exists for that resource,
	the server MAY perform the requested method as if the If-Match header		then the server MAY perform the requested method as if the If-Match
	field did not exist.		header field did not exist.
	If none of the entity-tags match, or if "*" is given and no current		If none of the entity-tags match, or if "*" is given and no current
	representation exists, the server MUST NOT perform the requested		representation exists, the server MUST NOT perform the requested
	method, and MUST return a 412 (Precondition Failed) response. This		method, and MUST return a 412 (Precondition Failed) response. This
	behavior is most useful when the client wants to prevent an updating		behavior is most useful when the client wants to prevent an updating
	method, such as PUT, from modifying a resource that has changed since		method, such as PUT, from modifying a resource that has changed since
	the client last retrieved it.		the client last retrieved it.
	If the request would, without the If-Match header field, result in		If the request would, without the If-Match header field, result in
	anything other than a 2xx or 412 status code, then the If-Match		anything other than a 2xx or 412 status code, then the If-Match
	header MUST be ignored.		header field MUST be ignored.
	The meaning of "If-Match: *" is that the method SHOULD be performed		The meaning of "If-Match: *" is that the method SHOULD be performed
	if the representation selected by the origin server (or by a cache,		if the representation selected by the origin server (or by a cache,
	possibly using the Vary mechanism, see Section 3.5 of [Part6])		possibly using the Vary mechanism, see Section 3.5 of [Part6])
	exists, and MUST NOT be performed if the representation does not		exists, and MUST NOT be performed if the representation does not
	exist.		exist.
	A request intended to update a resource (e.g., a PUT) MAY include an		A request intended to update a resource (e.g., a PUT) MAY include an
	If-Match header field to signal that the request method MUST NOT be		If-Match header field to signal that the request method MUST NOT be
	applied if the representation corresponding to the If-Match value (a		applied if the representation corresponding to the If-Match value (a
	skipping to change at page 15, line 5		skipping to change at page 16, line 5
	the method; instead, respond as detailed below.		the method; instead, respond as detailed below.
	If-Modified-Since = "If-Modified-Since" ":" OWS		If-Modified-Since = "If-Modified-Since" ":" OWS
	If-Modified-Since-v		If-Modified-Since-v
	If-Modified-Since-v = HTTP-date		If-Modified-Since-v = HTTP-date
	An example of the field is:		An example of the field is:
	If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT		If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
	A GET method with an If-Modified-Since header and no Range header		A GET method with an If-Modified-Since header field and no Range
	requests that the representation be transferred only if it has been		header field requests that the representation be transferred only if
	modified since the date given by the If-Modified-Since header. The		it has been modified since the date given by the If-Modified-Since
	algorithm for determining this includes the following cases:		header field. The algorithm for determining this includes the
			following cases:
	1. If the request would normally result in anything other than a 200		1. If the request would normally result in anything other than a 200
	(OK) status code, or if the passed If-Modified-Since date is		(OK) status code, or if the passed If-Modified-Since date is
	invalid, the response is exactly the same as for a normal GET. A		invalid, the response is exactly the same as for a normal GET. A
	date which is later than the server's current time is invalid.		date which is later than the server's current time is invalid.
	2. If the representation has been modified since the If-Modified-		2. If the representation has been modified since the If-Modified-
	Since date, the response is exactly the same as for a normal GET.		Since date, the response is exactly the same as for a normal GET.
	3. If the representation has not been modified since a valid If-		3. If the representation has not been modified since a valid If-
	skipping to change at page 15, line 40		skipping to change at page 16, line 41
	Note: When handling an If-Modified-Since header field, some		Note: When handling an If-Modified-Since header field, some
	servers will use an exact date comparison function, rather than a		servers will use an exact date comparison function, rather than a
	less-than function, for deciding whether to send a 304 (Not		less-than function, for deciding whether to send a 304 (Not
	Modified) response. To get best results when sending an If-		Modified) response. To get best results when sending an If-
	Modified-Since header field for cache validation, clients are		Modified-Since header field for cache validation, clients are
	advised to use the exact date string received in a previous Last-		advised to use the exact date string received in a previous Last-
	Modified header field whenever possible.		Modified header field whenever possible.
	Note: If a client uses an arbitrary date in the If-Modified-Since		Note: If a client uses an arbitrary date in the If-Modified-Since
	header instead of a date taken from the Last-Modified header for		header field instead of a date taken from the Last-Modified header
	the same request, the client needs to be aware that this date is		field for the same request, the client needs to be aware that this
	interpreted in the server's understanding of time. Unsynchronized		date is interpreted in the server's understanding of time.
	clocks and rounding problems, due to the different encodings of		Unsynchronized clocks and rounding problems, due to the different
	time between the client and server, are concerns. This includes		encodings of time between the client and server, are concerns.
	the possibility of race conditions if the document has changed		This includes the possibility of race conditions if the document
	between the time it was first requested and the If-Modified-Since		has changed between the time it was first requested and the If-
	date of a subsequent request, and the possibility of clock-skew-		Modified-Since date of a subsequent request, and the possibility
	related problems if the If-Modified-Since date is derived from the		of clock-skew-related problems if the If-Modified-Since date is
	client's clock without correction to the server's clock.		derived from the client's clock without correction to the server's
	Corrections for different time bases between client and server are		clock. Corrections for different time bases between client and
	at best approximate due to network latency.		server are at best approximate due to network latency.
	The result of a request having both an If-Modified-Since header field		The result of a request having both an If-Modified-Since header field
	and either an If-Match or an If-Unmodified-Since header fields is		and either an If-Match or an If-Unmodified-Since header fields is
	undefined by this specification.		undefined by this specification.
	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 representations		method conditional. A client that has one or more representations
	previously obtained from the resource can verify that none of those		previously obtained from the resource can verify that none of those
	skipping to change at page 16, line 30		skipping to change at page 17, line 30
	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 representation		As a special case, the value "*" matches any current representation
	of the resource.		of the 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 representation		If any of the entity-tags match the entity-tag of the representation
	that would have been returned in the response to a similar GET		that would have been returned in the response to a similar GET
	request (without the If-None-Match header) on that resource, or if		request (without the If-None-Match header field) on that resource, or
	"*" is given and any current representation exists for that resource,		if "*" is given and any current representation exists for that
	then the server MUST NOT perform the requested method, unless		resource, then the server MUST NOT perform the requested method,
	required to do so because the resource's modification date fails to		unless required to do so because the resource's modification date
	match that supplied in an If-Modified-Since header field in the		fails to match that supplied in an If-Modified-Since header field in
	request. Instead, if the request method was GET or HEAD, the server		the request. Instead, if the request method was GET or HEAD, the
	SHOULD respond with a 304 (Not Modified) response, including the		server SHOULD respond with a 304 (Not Modified) response, including
	cache-related header fields (particularly ETag) of one of the		the cache-related header fields (particularly ETag) of one of the
	representations that matched. For all other request methods, the		representations that matched. For all other request methods, the
	server MUST respond with a 412 (Precondition Failed) status code.		server MUST respond with a 412 (Precondition Failed) status code.
	If none of the entity-tags match, then the server MAY perform the		If none of the entity-tags match, then the server MAY perform the
	requested method as if the If-None-Match header field did not exist,		requested method as if the If-None-Match header field did not exist,
	but MUST also ignore any If-Modified-Since header field(s) in the		but MUST also ignore any If-Modified-Since header field(s) in the
	request. That is, if no entity-tags match, then the server MUST NOT		request. That is, if no entity-tags match, then the server MUST NOT
	return a 304 (Not Modified) response.		return a 304 (Not Modified) response.
	If the request would, without the If-None-Match header field, result		If the request would, without the If-None-Match header field, result
	in anything other than a 2xx or 304 status code, then the If-None-		in anything other than a 2xx or 304 status code, then the If-None-
	Match header MUST be ignored. (See Section 5 for a discussion of		Match header field MUST be ignored. (See Section 5 for a discussion
	server behavior when both If-Modified-Since and If-None-Match appear		of server behavior when both If-Modified-Since and If-None-Match
	in the same request.)		appear in the same request.)
	The meaning of "If-None-Match: *" is that the method MUST NOT be		The meaning of "If-None-Match: *" is that the method MUST NOT be
	performed if the representation selected by the origin server (or by		performed if the representation selected by the origin server (or by
	a cache, possibly using the Vary mechanism, see Section 3.5 of		a cache, possibly using the Vary mechanism, see Section 3.5 of
	[Part6]) exists, and SHOULD be performed if the representation does		[Part6]) exists, and SHOULD be performed if the representation does
	not exist. This feature is intended to be useful in preventing races		not exist. This feature is intended to be useful in preventing races
	between PUT operations.		between PUT operations.
	Examples:		Examples:
	If-None-Match: "xyzzy"		If-None-Match: "xyzzy"
	skipping to change at page 17, line 30		skipping to change at page 18, line 30
	either an If-Match or an If-Unmodified-Since header fields is		either an If-Match or an If-Unmodified-Since header fields is
	undefined by this specification.		undefined by this specification.
	6.5. If-Unmodified-Since		6.5. If-Unmodified-Since
	The "If-Unmodified-Since" request-header field is used to make a		The "If-Unmodified-Since" request-header field is used to make a
	request method conditional. If the representation that would have		request method conditional. If the representation that would have
	been transferred in a 200 response to a GET request on the same		been transferred in a 200 response to a GET request on the same
	resource has not been modified since the time specified in this		resource has not been modified since the time specified in this
	field, the server SHOULD perform the requested operation as if the		field, the server SHOULD perform the requested operation as if the
	If-Unmodified-Since header were not present.		If-Unmodified-Since header field were not present.
	If the representation has been modified since the specified time, the		If the representation has been modified since the specified time, the
	server MUST NOT perform the requested operation, and MUST return a		server MUST NOT perform the requested operation, and MUST return a
	412 (Precondition Failed).		412 (Precondition Failed).
	If-Unmodified-Since = "If-Unmodified-Since" ":" OWS		If-Unmodified-Since = "If-Unmodified-Since" ":" OWS
	If-Unmodified-Since-v		If-Unmodified-Since-v
	If-Unmodified-Since-v = HTTP-date		If-Unmodified-Since-v = HTTP-date
	An example of the field is:		An example of the field is:
	If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT		If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
	If the request normally (i.e., without the If-Unmodified-Since		If the request normally (i.e., without the If-Unmodified-Since header
	header) would result in anything other than a 2xx or 412 status code,		field) would result in anything other than a 2xx or 412 status code,
	the If-Unmodified-Since header SHOULD be ignored.		the If-Unmodified-Since header field SHOULD be ignored.
	If the specified date is invalid, the header is ignored.		If the specified date is invalid, the header field is ignored.
	The result of a request having both an If-Unmodified-Since header		The result of a request having both an If-Unmodified-Since header
	field and either an If-None-Match or an If-Modified-Since header		field and either an If-None-Match or an If-Modified-Since header
	fields is undefined by this specification.		fields is undefined by this specification.
	6.6. Last-Modified		6.6. Last-Modified
	The "Last-Modified" header field indicates the date and time at which		The "Last-Modified" header field indicates the date and time at which
	the origin server believes the representation was last modified.		the origin server believes the representation was last modified.
	skipping to change at page 19, line 51		skipping to change at page 20, line 51
	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-11		and Message Parsing", draft-ietf-httpbis-p1-messaging-12
	(work in progress), August 2010.		(work in progress), October 2010.
	[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-11		and Content Negotiation", draft-ietf-httpbis-p3-payload-12
	(work in progress), August 2010.		(work in progress), October 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-11 (work		Partial Responses", draft-ietf-httpbis-p5-range-12 (work
	in progress), August 2010.		in progress), October 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-11 (work in		6: Caching", draft-ietf-httpbis-p6-cache-12 (work in
	progress), August 2010.		progress), October 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 21, line 48		skipping to change at page 22, line 48
	; ETag defined but not used		; ETag defined but not used
	; If-Match defined but not used		; If-Match defined but not used
	; If-Modified-Since defined but not used		; If-Modified-Since defined but not used
	; If-None-Match defined but not used		; If-None-Match defined but not used
	; If-Unmodified-Since defined but not used		; If-Unmodified-Since defined but not used
	; Last-Modified defined but not used		; Last-Modified defined but not used
	Appendix C. Change Log (to be removed by RFC Editor before publication)		Appendix C. Change Log (to be removed by RFC Editor before publication)
	C.1. Since RFC2616		C.1. Since RFC 2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	C.2. Since draft-ietf-httpbis-p4-conditional-00		C.2. Since draft-ietf-httpbis-p4-conditional-00
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and		o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
	Informative references"		Informative references"
	skipping to change at page 22, line 31		skipping to change at page 23, line 31
	o Add explicit references to BNF syntax and rules imported from		o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.		other parts of the specification.
	C.4. Since draft-ietf-httpbis-p4-conditional-02		C.4. Since draft-ietf-httpbis-p4-conditional-02
	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"		non-GET requests"
	Ongoing work on IANA Message Header Registration		Ongoing work on IANA Message Header Field Registration
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	o Reference RFC 3984, and update header registrations for headers		o Reference RFC 3984, and update header field registrations for
	defined in this document.		header fields defined in this document.
	C.5. Since draft-ietf-httpbis-p4-conditional-03		C.5. Since draft-ietf-httpbis-p4-conditional-03
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for		o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for
	ETag matching"		ETag matching"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity		o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity
	value' undefined"		value' undefined"
	skipping to change at page 23, line 16		skipping to change at page 24, line 16
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Use "/" instead of "|" for alternatives.		o Use "/" instead of "|" for alternatives.
	o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional		o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
	whitespace ("OWS") and required whitespace ("RWS").		whitespace ("OWS") and required whitespace ("RWS").
	o Rewrite ABNFs to spell out whitespace rules, factor out header		o Rewrite ABNFs to spell out whitespace rules, factor out header
	value format definitions.		field value format definitions.
	C.7. Since draft-ietf-httpbis-p4-conditional-05		C.7. Since draft-ietf-httpbis-p4-conditional-05
	Final work on ABNF conversion		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-p4-conditional-06		C.8. Since draft-ietf-httpbis-p4-conditional-06
	skipping to change at page 24, line 18		skipping to change at page 25, line 18
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify		o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
	'Requested Variant'"		'Requested Variant'"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify		o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
	entity / representation / variant terminology"		entity / representation / variant terminology"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider		o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
	removing the 'changes from 2068' sections"		removing the 'changes from 2068' sections"
			C.13. Since draft-ietf-httpbis-p4-conditional-11
			None.
	Index		Index
	3		3
	304 Not Modified (status code) 7		304 Not Modified (status code) 8
	4		4
	412 Precondition Failed (status code) 7		412 Precondition Failed (status code) 8
	E		E
	ETag header 12		ETag header 13
	G		G
	Grammar		Grammar
	entity-tag 5		entity-tag 6
	ETag 12		ETag 13
	ETag-v 12		ETag-v 13
	If-Match 13		If-Match 14
	If-Match-v 13		If-Match-v 14
	If-Modified-Since 14		If-Modified-Since 15
	If-Modified-Since-v 14		If-Modified-Since-v 15
	If-None-Match 16		If-None-Match 17
	If-None-Match-v 16		If-None-Match-v 17
	If-Unmodified-Since 17		If-Unmodified-Since 18
	If-Unmodified-Since-v 17		If-Unmodified-Since-v 18
	Last-Modified 18		Last-Modified 19
	Last-Modified-v 18		Last-Modified-v 19
	opaque-tag 5		opaque-tag 6
	weak 5		weak 6
	H		H
	Headers		Headers
	ETag 12		ETag 13
	If-Match 13		If-Match 14
	If-Modified-Since 14		If-Modified-Since 15
	If-None-Match 16		If-None-Match 17
	If-Unmodified-Since 17		If-Unmodified-Since 18
	Last-Modified 18		Last-Modified 19
	I		I
	If-Match header 13		If-Match header 14
	If-Modified-Since header 14		If-Modified-Since header 15
	If-None-Match header 16		If-None-Match header 17
	If-Unmodified-Since header 17		If-Unmodified-Since header 18
	L		L
	Last-Modified header 18		Last-Modified header 19
	S		S
	Status Codes		Status Codes
	304 Not Modified 7		304 Not Modified 8
	412 Precondition Failed 7		412 Precondition Failed 8
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
End of changes. 40 change blocks.
	136 lines changed or deleted		143 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/