draft-ietf-httpbis-p4-conditional-21.txt		draft-ietf-httpbis-p4-conditional-22.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Reschke, Ed.		Obsoletes: 2616 (if approved) J. Reschke, Ed.
	Intended status: Standards Track greenbytes		Intended status: Standards Track greenbytes
	Expires: April 7, 2013 October 4, 2012		Expires: August 27, 2013 February 23, 2013
	Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests		Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
	draft-ietf-httpbis-p4-conditional-21		draft-ietf-httpbis-p4-conditional-22
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. This document defines HTTP/1.1 conditional requests,		systems. This document defines HTTP/1.1 conditional requests,
	including metadata header fields for indicating state changes,		including metadata header fields for indicating state changes,
	request header fields for making preconditions on such state, and		request header fields for making preconditions on such state, and
	rules for constructing the responses to a conditional request when		rules for constructing the responses to a conditional request when
	one or more preconditions evaluate to false.		one or more preconditions evaluate to false.
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.2.		The changes in this draft are summarized in Appendix D.3.
	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 April 7, 2013.		This Internet-Draft will expire on August 27, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 9		skipping to change at page 3, line 9
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5		2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5
	2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7		2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7		2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8		2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8
	2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10		2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10
	2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 10		2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 10
	2.3.3. Example: Entity-tags varying on Content-Negotiated		2.3.3. Example: Entity-tags Varying on Content-Negotiated
	Resources . . . . . . . . . . . . . . . . . . . . . . 11		Resources . . . . . . . . . . . . . . . . . . . . . . 11
	2.4. Rules for When to Use Entity-tags and Last-Modified		2.4. When to Use Entity-tags and Last-Modified Dates . . . . . 12
	Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 13		3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
	3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14		3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14
	3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16		3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15
	3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17		3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16
	3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 17		3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 16
	4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18		4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17
	4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18		4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 17
	4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 18		4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 17
	5. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19		5. Evaluation and Precedence . . . . . . . . . . . . . . . . . . 17
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	6.1. Status Code Registration . . . . . . . . . . . . . . . . . 20		6.1. Status Code Registration . . . . . . . . . . . . . . . . . 20
	6.2. Header Field Registration . . . . . . . . . . . . . . . . 20		6.2. Header Field Registration . . . . . . . . . . . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 21		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 21		9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	9.2. Informative References . . . . . . . . . . . . . . . . . . 22		9.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 22		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 22
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 23		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 23
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 23		publication) . . . . . . . . . . . . . . . . . . . . 23
	D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 23		D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 23
	D.2. Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 24		D.2. Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 24
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		D.3. Since draft-ietf-httpbis-p4-conditional-21 . . . . . . . . 24
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	Conditional requests are HTTP requests [Part2] that include one or		Conditional requests are HTTP requests [Part2] that include one or
	more header fields indicating a precondition to be tested before		more header fields indicating a precondition to be tested before
	applying the method semantics to the target resource. Each		applying the method semantics to the target resource. This document
	precondition is based on metadata that is expected to change if the		defines the HTTP/1.1 conditional request mechanisms in terms of the
	selected representation of the target resource is changed. This		architecture, syntax notation, and conformance criteria defined in
	document defines the HTTP/1.1 conditional request mechanisms in terms		[Part1].
	of the architecture, syntax notation, and conformance criteria
	defined in [Part1].
	Conditional GET requests are the most efficient mechanism for HTTP		Conditional GET requests are the most efficient mechanism for HTTP
	cache updates [Part6]. Conditionals can also be applied to state-		cache updates [Part6]. Conditionals can also be applied to state-
	changing methods, such as PUT and DELETE, to prevent the "lost		changing methods, such as PUT and DELETE, to prevent the "lost
	update" problem: one client accidentally overwriting the work of		update" problem: one client accidentally overwriting the work of
	another client that has been acting in parallel.		another client that has been acting in parallel.
	Conditional request preconditions are based on the state of the		Conditional request preconditions are based on the state of the
	target resource as a whole (its current value set) or the state as		target resource as a whole (its current value set) or the state as
	observed in a previously obtained representation (one value in that		observed in a previously obtained representation (one value in that
	set). A resource might have multiple current representations, each		set). A resource might have multiple current representations, each
	with its own observable state. The conditional request mechanisms		with its own observable state. The conditional request mechanisms
	assume that the mapping of requests to corresponding representations		assume that the mapping of requests to a "selected representation"
	will be consistent over time if the server intends to take advantage		(Section 3 of [Part2]) will be consistent over time if the server
	of conditionals. Regardless, if the mapping is inconsistent and the		intends to take advantage of conditionals. Regardless, if the
	server is unable to select the appropriate representation, then no		mapping is inconsistent and the server is unable to select the
	harm will result when the precondition evaluates to false.		appropriate representation, then no harm will result when the
			precondition evaluates to false.
	We use the term "selected representation" to refer to the current		The conditional request preconditions defined by this specification
	representation of the target resource that would have been selected		are evaluated by comparing the validators provided in the conditional
	in a successful response if the same request had used the method GET		request header fields to the current validators for the selected
	and had excluded all of the conditional request header fields. The		representation in the order defined by Section 5.
	conditional request preconditions are evaluated by comparing the
	values provided in the request header fields to the current metadata
	for the selected representation.
	1.1. Conformance and Error Handling		1.1. Conformance and Error Handling
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Conformance criteria and considerations regarding error handling are		Conformance criteria and considerations regarding error handling are
	defined in Section 2.5 of [Part1].		defined in Section 2.5 of [Part1].
	skipping to change at page 5, line 34		skipping to change at page 5, line 26
	2.1. Weak versus Strong		2.1. Weak versus Strong
	Validators come in two flavors: strong or weak. Weak validators are		Validators come in two flavors: strong or weak. Weak validators are
	easy to generate but are far less useful for comparisons. Strong		easy to generate but are far less useful for comparisons. Strong
	validators are ideal for comparisons but can be very difficult (and		validators are ideal for comparisons but can be very difficult (and
	occasionally impossible) to generate efficiently. Rather than impose		occasionally impossible) to generate efficiently. Rather than impose
	that all forms of resource adhere to the same strength of validator,		that all forms of resource adhere to the same strength of validator,
	HTTP exposes the type of validator in use and imposes restrictions on		HTTP exposes the type of validator in use and imposes restrictions on
	when weak validators can be used as preconditions.		when weak validators can be used as preconditions.
	A "strong validator" is a representation metadata value that MUST be		A "strong validator" is representation metadata that changes value
	changed to a new, previously unused or guaranteed unique, value		whenever a change occurs to the representation data that would be
	whenever a change occurs to the representation data such that a		observable in the payload body of a 200 (OK) response to GET.
	change would be observable in the payload body of a 200 (OK) response
	to GET.
	A strong validator MAY be changed for other reasons, such as when a		A strong validator might change for other reasons, such as when a
	semantically significant part of the representation metadata is		semantically significant part of the representation metadata is
	changed (e.g., Content-Type), but it is in the best interests of the		changed (e.g., Content-Type), but it is in the best interests of the
	origin server to only change the value when it is necessary to		origin server to only change the value when it is necessary to
	invalidate the stored responses held by remote caches and authoring		invalidate the stored responses held by remote caches and authoring
	tools. A strong validator MUST be unique across all representations		tools. A strong validator is unique across all representations of a
	of a given resource, such that no two representations of that		given resource, such that no two representations of that resource can
	resource share the same validator unless their payload body would be		share the same validator unless their representation data is
	identical.		identical.
	Cache entries might persist for arbitrarily long periods, regardless		Cache entries might persist for arbitrarily long periods, regardless
	of expiration times. Thus, a cache might attempt to validate an		of expiration times. Thus, a cache might attempt to validate an
	entry using a validator that it obtained in the distant past. A		entry using a validator that it obtained in the distant past. A
	strong validator MUST be unique across all versions of all		strong validator is unique across all versions of all representations
	representations associated with a particular resource over time.		associated with a particular resource over time. However, there is
	However, there is no implication of uniqueness across representations		no implication of uniqueness across representations of different
	of different resources (i.e., the same strong validator might be in		resources (i.e., the same strong validator might be in use for
	use for representations of multiple resources at the same time and		representations of multiple resources at the same time and does not
	does not imply that those representations are equivalent).		imply that those representations are equivalent).
	There are a variety of strong validators used in practice. The best		There are a variety of strong validators used in practice. The best
	are based on strict revision control, wherein each change to a		are based on strict revision control, wherein each change to a
	representation always results in a unique node name and revision		representation always results in a unique node name and revision
	identifier being assigned before the representation is made		identifier being assigned before the representation is made
	accessible to GET. A collision-resistant hash function applied to		accessible to GET. A collision-resistant hash function applied to
	the representation data is also sufficient if the data is available		the representation data is also sufficient if the data is available
	prior to the response header fields being sent and the digest does		prior to the response header fields being sent and the digest does
	not need to be recalculated every time a validation request is		not need to be recalculated every time a validation request is
	received. However, if a resource has distinct representations that		received. However, if a resource has distinct representations that
	differ only in their metadata, such as might occur with content		differ only in their metadata, such as might occur with content
	negotiation over media types that happen to share the same data		negotiation over media types that happen to share the same data
	format, then the origin server SHOULD incorporate additional		format, then the origin server SHOULD incorporate additional
	information in the validator to distinguish those representations and		information in the validator to distinguish those representations and
	avoid confusing cache behavior.		avoid confusing cache behavior.
	In contrast, a "weak validator" is a representation metadata value		In contrast, a "weak validator" is representation metadata that might
	that might not be changed for every change to the representation		not change for every change to the representation data. This
	data. This weakness might be due to limitations in how the value is		weakness might be due to limitations in how the value is calculated,
	calculated, such as clock resolution or an inability to ensure		such as clock resolution or an inability to ensure uniqueness for all
	uniqueness for all possible representations of the resource, or due		possible representations of the resource, or due to a desire by the
	to a desire by the resource owner to group representations by some		resource owner to group representations by some self-determined set
	self-determined set of equivalency rather than unique sequences of		of equivalency rather than unique sequences of data. An origin
	data. An origin server SHOULD change a weak entity-tag whenever it		server SHOULD change a weak entity-tag whenever it considers prior
	considers prior representations to be unacceptable as a substitute		representations to be unacceptable as a substitute for the current
	for the current representation. In other words, a weak entity-tag		representation. In other words, a weak entity-tag ought to change
	ought to change whenever the origin server wants caches to invalidate		whenever the origin server wants caches to invalidate old responses.
	old responses.
	For example, the representation of a weather report that changes in		For example, the representation of a weather report that changes in
	content every second, based on dynamic measurements, might be grouped		content every second, based on dynamic measurements, might be grouped
	into sets of equivalent representations (from the origin server's		into sets of equivalent representations (from the origin server's
	perspective) with the same weak validator in order to allow cached		perspective) with the same weak validator in order to allow cached
	representations to be valid for a reasonable period of time (perhaps		representations to be valid for a reasonable period of time (perhaps
	adjusted dynamically based on server load or weather quality).		adjusted dynamically based on server load or weather quality).
	Likewise, a representation's modification time, if defined with only		Likewise, a representation's modification time, if defined with only
	one-second resolution, might be a weak validator if it is possible		one-second resolution, might be a weak validator if it is possible
	for the representation to be modified twice during a single second		for the representation to be modified twice during a single second
	and retrieved between those modifications.		and retrieved between those modifications.
			Likewise, a validator is weak if it is shared by two or more
			representations of a given resource at the same time, unless those
			representations have identical representation data. For example, if
			the origin server sends the same validator for a representation with
			a gzip content coding applied as it does for a representation with no
			content coding, then that validator is weak. However, two
			simultaneous representations might share the same strong validator if
			they differ only in the representation metadata, such as when two
			different media types are available for the same representation data.
	A "use" of a validator occurs when either a client generates a		A "use" of a validator occurs when either a client generates a
	request and includes the validator in a precondition or when a server		request and includes the validator in a precondition or when a server
	compares two validators. Weak validators are only usable in contexts		compares two validators. Weak validators are only usable in contexts
	that do not depend on exact equality of a representation's payload		that do not depend on exact equality of the representation data.
	body. Strong validators are usable and preferred for all conditional		Strong validators are usable and preferred for all conditional
	requests, including cache validation, partial content ranges, and		requests, including cache validation, partial content ranges, and
	"lost update" avoidance.		"lost update" avoidance.
	2.2. Last-Modified		2.2. Last-Modified
	The "Last-Modified" header field indicates the date and time at which		The "Last-Modified" header field in a response provides a timestamp
	the origin server believes the selected representation was last		indicating the date and time at which the origin server believes the
	modified.		selected representation was last modified, as determined at the
			conclusion of handling the request.
	Last-Modified = HTTP-date		Last-Modified = HTTP-date
	An example of its use is		An example of its use is
	Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT		Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
	2.2.1. Generation		2.2.1. Generation
	Origin servers SHOULD send Last-Modified for any selected		Origin servers SHOULD send Last-Modified for any selected
	skipping to change at page 9, line 11		skipping to change at page 9, line 11
	same Last-Modified time, then at least one of those responses would		same Last-Modified time, then at least one of those responses would
	have a Date value equal to its Last-Modified time. The arbitrary 60-		have a Date value equal to its Last-Modified time. The arbitrary 60-
	second limit guards against the possibility that the Date and Last-		second limit guards against the possibility that the Date and Last-
	Modified values are generated from different clocks, or at somewhat		Modified values are generated from different clocks, or at somewhat
	different times during the preparation of the response. An		different times during the preparation of the response. An
	implementation MAY use a value larger than 60 seconds, if it is		implementation MAY use a value larger than 60 seconds, if it is
	believed that 60 seconds is too short.		believed that 60 seconds is too short.
	2.3. ETag		2.3. ETag
	The "ETag" header field provides the current entity-tag for the		The "ETag" header field in a response provides the current entity-tag
	selected representation. An entity-tag is an opaque validator for		for the selected representation, as determined at the conclusion of
			handling the request. An entity-tag is an opaque validator for
	differentiating between multiple representations of the same		differentiating between multiple representations of the same
	resource, regardless of whether those multiple representations are		resource, regardless of whether those multiple representations are
	due to resource state changes over time, content negotiation		due to resource state changes over time, content negotiation
	resulting in multiple representations being valid at the same time,		resulting in multiple representations being valid at the same time,
	or both. An entity-tag consists of an opaque quoted string, possibly		or both. An entity-tag consists of an opaque quoted string, possibly
	prefixed by a weakness indicator.		prefixed by a weakness indicator.
	ETag = entity-tag		ETag = entity-tag
	entity-tag = [ weak ] opaque-tag		entity-tag = [ weak ] opaque-tag
	skipping to change at page 9, line 48		skipping to change at page 9, line 49
	Examples:		Examples:
	ETag: "xyzzy"		ETag: "xyzzy"
	ETag: W/"xyzzy"		ETag: W/"xyzzy"
	ETag: ""		ETag: ""
	An entity-tag can be either a weak or strong validator, with strong		An entity-tag can be either a weak or strong validator, with strong
	being the default. If an origin server provides an entity-tag for a		being the default. If an origin server provides an entity-tag for a
	representation and the generation of that entity-tag does not satisfy		representation and the generation of that entity-tag does not satisfy
	the requirements for a strong validator (Section 2.1), then that		all of the characteristics of a strong validator (Section 2.1), then
	entity-tag MUST be marked as weak by prefixing its opaque value with		the origin server MUST mark the entity-tag as weak by prefixing its
	"W/" (case-sensitive).		opaque value with "W/" (case-sensitive).
	2.3.1. Generation		2.3.1. Generation
	The principle behind entity-tags is that only the service author		The principle behind entity-tags is that only the service author
	knows the implementation of a resource well enough to select the most		knows the implementation of a resource well enough to select the most
	accurate and efficient validation mechanism for that resource, and		accurate and efficient validation mechanism for that resource, and
	that any such mechanism can be mapped to a simple sequence of octets		that any such mechanism can be mapped to a simple sequence of octets
	for easy comparison. Since the value is opaque, there is no need for		for easy comparison. Since the value is opaque, there is no need for
	the client to be aware of how each entity-tag is constructed.		the client to be aware of how each entity-tag is constructed.
	skipping to change at page 10, line 35		skipping to change at page 10, line 35
	determined, since the entity-tag's use in conditional requests and		determined, since the entity-tag's use in conditional requests and
	evaluating cache freshness ([Part6]) can result in a substantial		evaluating cache freshness ([Part6]) can result in a substantial
	reduction of HTTP network traffic and can be a significant factor in		reduction of HTTP network traffic and can be a significant factor in
	improving service scalability and reliability.		improving service scalability and reliability.
	2.3.2. Comparison		2.3.2. Comparison
	There are two entity-tag comparison functions, depending on whether		There are two entity-tag comparison functions, depending on whether
	the comparison context allows the use of weak validators or not:		the comparison context allows the use of weak validators or not:
	o The strong comparison function: in order to be considered equal,		o Strong comparison: two entity-tags are equivalent if both are not
	both opaque-tags MUST be identical character-by-character, and		weak and their opaque-tags match character-by-character.
	both MUST NOT be weak.
	o The weak comparison function: in order to be considered equal,		o Weak comparison: two entity-tags are equivalent if their opaque-
	both opaque-tags MUST be identical character-by-character, but		tags match character-by-character, regardless of either or both
	either or both of them MAY be tagged as "weak" without affecting		being tagged as "weak".
	the result.
	The example below shows the results for a set of entity-tag pairs,		The example below shows the results for a set of entity-tag pairs,
	and both the weak and strong comparison function results:		and both the weak and strong comparison function results:
	+--------+--------+-------------------+-----------------+		+--------+--------+-------------------+-----------------+
	| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |		| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
	+--------+--------+-------------------+-----------------+		+--------+--------+-------------------+-----------------+
	| W/"1" | W/"1" | no match | match |		| W/"1" | W/"1" | no match | match |
	| W/"1" | W/"2" | no match | no match |		| W/"1" | W/"2" | no match | no match |
	| W/"1" | "1" | no match | match |		| W/"1" | "1" | no match | match |
	| "1" | "1" | match | match |		| "1" | "1" | match | match |
	+--------+--------+-------------------+-----------------+		+--------+--------+-------------------+-----------------+
	2.3.3. Example: Entity-tags varying on Content-Negotiated Resources		2.3.3. Example: Entity-tags Varying on Content-Negotiated Resources
	Consider a resource that is subject to content negotiation (Section		Consider a resource that is subject to content negotiation (Section
	3.4 of [Part2]), and where the representations returned upon a GET		3.4 of [Part2]), and where the representations sent in response to a
	request vary based on the Accept-Encoding request header field		GET request vary based on the Accept-Encoding request header field
	(Section 6.3.4 of [Part2]):		(Section 5.3.4 of [Part2]):
	>> Request:		>> Request:
	GET /index HTTP/1.1		GET /index HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Accept-Encoding: gzip		Accept-Encoding: gzip
	In this case, the response might or might not use the gzip content		In this case, the response might or might not use the gzip content
	coding. If it does not, the response might look like:		coding. If it does not, the response might look like:
	skipping to change at page 12, line 24		skipping to change at page 12, line 12
	...binary data...		...binary data...
	Note: Content codings are a property of the representation, so		Note: Content codings are a property of the representation, so
	therefore an entity-tag of an encoded representation has to be		therefore an entity-tag of an encoded representation has to be
	distinct from an unencoded representation to prevent conflicts		distinct from an unencoded representation to prevent conflicts
	during cache updates and range requests. In contrast, transfer		during cache updates and range requests. In contrast, transfer
	codings (Section 4 of [Part1]) apply only during message transfer		codings (Section 4 of [Part1]) apply only during message transfer
	and do not require distinct entity-tags.		and do not require distinct entity-tags.
	2.4. Rules for When to Use Entity-tags and Last-Modified Dates		2.4. When to Use Entity-tags and Last-Modified Dates
	We adopt a set of rules and recommendations for origin servers,		We adopt a set of rules and recommendations for origin servers,
	clients, and caches regarding when various validator types ought to		clients, and caches regarding when various validator types ought to
	be used, and for what purposes.		be used, and for what purposes.
	HTTP/1.1 origin servers:		In 200 (OK) responses to GET or HEAD, an origin server:
	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.
	In other words, the preferred behavior for an HTTP/1.1 origin server		In other words, the preferred behavior for an origin server is to
	is to send both a strong entity-tag and a Last-Modified value.		send both a strong entity-tag and a Last-Modified value in successful
			responses to a retrieval request.
	HTTP/1.1 clients:		A client:
	o MUST use that entity-tag in any cache-conditional request (using		o MUST use that entity-tag in any cache-conditional request (using
	If-Match or If-None-Match) if an entity-tag has been provided by		If-Match or If-None-Match) if an entity-tag has been provided by
	the origin server.		the origin server.
	o SHOULD use the Last-Modified value in non-subrange cache-		o SHOULD use the Last-Modified value in non-subrange cache-
	conditional requests (using If-Modified-Since) if only a Last-		conditional requests (using If-Modified-Since) if only a Last-
	Modified value has been provided by the origin server.		Modified value has been provided by the origin server.
	o MAY use the Last-Modified value in subrange cache-conditional		o MAY use the Last-Modified value in subrange cache-conditional
	requests (using If-Unmodified-Since) if only a Last-Modified value		requests (using If-Unmodified-Since) if only a Last-Modified value
	has been provided by an HTTP/1.0 origin server. The user agent		has been provided by an HTTP/1.0 origin server. The user agent
	SHOULD provide a way to disable this, in case of difficulty.		SHOULD provide a way to disable this, in case of difficulty.
	o SHOULD use both validators in cache-conditional requests if both		o SHOULD use both validators in cache-conditional requests if both
	an entity-tag and a Last-Modified value have been provided by the		an entity-tag and a Last-Modified value have been provided by the
	origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to		origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
	respond appropriately.		respond appropriately.
	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
	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
	validators, MUST NOT return a response status code of 304 (Not
	Modified) unless doing so is consistent with all of the conditional
	header fields in the request.
	An HTTP/1.1 caching proxy, upon receiving a conditional request that
	includes both a Last-Modified date and one or more entity-tags as
	cache validators, MUST NOT return a locally cached response to the
	client unless that cached response is consistent with all of the
	conditional header fields in the request.
	Note: The general principle behind these rules is that HTTP/1.1
	servers and clients ought to transmit as much non-redundant
	information as is available in their responses and requests.
	HTTP/1.1 systems receiving this information will make the most
	conservative assumptions about the validators they receive.
	HTTP/1.0 clients and caches might ignore entity-tags. Generally,
	last-modified values received or used by these systems will
	support transparent and efficient caching, and so HTTP/1.1 origin
	servers still ought to provide Last-Modified values.
	3. Precondition Header Fields		3. Precondition Header Fields
	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 for applying preconditions on requests. Section 5 defines the		fields for applying preconditions on requests. Section 5 defines
	order of evaluation when more than one precondition is present in a		when the preconditions are applied and the order of evaluation when
	request.		more than one precondition is present.
	3.1. If-Match		3.1. If-Match
	The "If-Match" header field can be used to make a request method		The "If-Match" header field can be used to make a request method
	conditional on the current existence or value of an entity-tag for		conditional on the current existence or value of an entity-tag for
	one or more representations of the target resource.		one or more representations of the target resource.
	If-Match is generally useful for resource update requests, such as		If-Match is generally useful for resource update requests, such as
	PUT requests, as a means for protecting against accidental overwrites		PUT requests, as a means for protecting against accidental overwrites
	when multiple clients are acting in parallel on the same resource		when multiple clients are acting in parallel on the same resource
	(i.e., the "lost update" problem). An If-Match field-value of "*"		(i.e., the "lost update" problem). An If-Match field-value of "*"
	places the precondition on the existence of any current		places the precondition on the existence of any current
	representation for the target resource.		representation for the target resource.
	If-Match = "*" / 1#entity-tag		If-Match = "*" / 1#entity-tag
	The If-Match condition is met if and only if any of the entity-tags		The If-Match condition is met if and only if any of the entity-tags
	listed in the If-Match field value match the entity-tag of the		listed in the If-Match field value match the entity-tag of the
	selected representation for the target resource (as per		selected representation using the weak comparison function (as per
	Section 2.3.2), or if "*" is given and any current representation		Section 2.3.2), or if "*" is given and any current representation
	exists for the target resource.		exists for the target resource.
	If the condition is met, the server MAY perform the request method as		If the condition is met, the server MAY perform the request method.
	if the If-Match header field was not present.
	Origin servers MUST NOT perform the requested method if the condition		Origin servers MUST NOT perform the requested method if the condition
	is not met; instead they MUST respond with the 412 (Precondition		is not met; instead they MUST respond with the 412 (Precondition
	Failed) status code.		Failed) status code.
	Proxy servers using a cached response as the selected representation		Proxy servers using a cached response as the selected representation
	MUST NOT perform the requested method if the condition is not met;		MUST NOT perform the requested method if the condition is not met;
	instead, they MUST forward the request towards the origin server.		instead, they MUST forward the request towards the origin server.
	If the request would, without the If-Match header field, result in
	anything other than a 2xx (Successful) or 412 (Precondition Failed)
	status code, then the If-Match header field MUST be ignored.
	Examples:		Examples:
	If-Match: "xyzzy"		If-Match: "xyzzy"
	If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"		If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
	If-Match: *		If-Match: *
	3.2. If-None-Match		3.2. If-None-Match
	The "If-None-Match" header field can be used to make a request method		The "If-None-Match" header field can be used to make a request method
	conditional on not matching any of the current entity-tag values for		conditional on not matching any of the current entity-tag values for
	skipping to change at page 15, line 18		skipping to change at page 14, line 31
	existing representation of the target resource when the client		existing representation of the target resource when the client
	believes that the resource does not have a current representation.		believes that the resource does not have a current representation.
	This is a variation on the "lost update" problem that might arise if		This is a variation on the "lost update" problem that might arise if
	more than one client attempts to create an initial representation for		more than one client attempts to create an initial representation for
	the target resource.		the target resource.
	If-None-Match = "*" / 1#entity-tag		If-None-Match = "*" / 1#entity-tag
	The If-None-Match condition is met if and only if none of the entity-		The If-None-Match condition is met if and only if none of the entity-
	tags listed in the If-None-Match field value match the entity-tag of		tags listed in the If-None-Match field value match the entity-tag of
	the selected representation for the target resource (as per		the selected representation using the weak comparison function (as
	Section 2.3.2), or if "*" is given and no current representation		per Section 2.3.2), or if "*" is given and no current representation
	exists for that resource.		exists for that resource.
	If the condition is not met, the server MUST NOT perform the		If the condition is not met, the server MUST NOT perform the
	requested method. Instead, if the request method was GET or HEAD,		requested method. Instead, if the request method was GET or HEAD,
	the server SHOULD respond with a 304 (Not Modified) status code,		the server SHOULD respond with a 304 (Not Modified) status code,
	including the cache-related header fields (particularly ETag) of the		including the cache-related header fields (particularly ETag) of the
	selected representation that has a matching entity-tag. For all		selected representation that has a matching entity-tag. For all
	other request methods, the server MUST respond with a 412		other request methods, the server MUST respond with a 412
	(Precondition Failed) status code.		(Precondition Failed) status code when the condition is not met.
	If the condition is met, the server MAY perform the requested method		If the condition is met, the server MAY perform the requested method
	as if the If-None-Match header field did not exist, but MUST also		and MUST ignore any If-Modified-Since header field(s) in the request.
	ignore any If-Modified-Since header field(s) in the request. That		That is, if no entity-tags match, then the server MUST NOT send a 304
	is, if no entity-tags match, then the server MUST NOT return a 304
	(Not Modified) response.		(Not Modified) response.
	If the request would, without the If-None-Match header field, result
	in anything other than a 2xx (Successful) or 304 (Not Modified)
	status code, then the If-None-Match header field MUST be ignored.
	(See Section 2.4 for a discussion of server behavior when both If-
	Modified-Since and If-None-Match appear in the same request.)
	Examples:		Examples:
	If-None-Match: "xyzzy"		If-None-Match: "xyzzy"
	If-None-Match: W/"xyzzy"		If-None-Match: W/"xyzzy"
	If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"		If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
	If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"		If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
	If-None-Match: *		If-None-Match: *
	3.3. If-Modified-Since		3.3. If-Modified-Since
	skipping to change at page 16, line 28		skipping to change at page 15, line 34
	A GET method with an If-Modified-Since header field and no Range		A GET method with an If-Modified-Since header field and no Range
	header field requests that the selected representation be transferred		header field requests that the selected representation be transferred
	only if it has been modified since the date given by the If-Modified-		only if it has been modified since the date given by the If-Modified-
	Since header field. The algorithm for determining this includes the		Since header field. The algorithm for determining this includes the
	following cases:		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 that is later than the server's current time is invalid.
	2. If the selected representation has been modified since the If-		2. If the selected representation has been modified since the If-
	Modified-Since date, the response is exactly the same as for a		Modified-Since date, the response is exactly the same as for a
	normal GET.		normal GET.
	3. If the selected representation has not been modified since a		3. If the selected representation has not been modified since a
	valid If-Modified-Since date, the server SHOULD return a 304 (Not		valid If-Modified-Since date, the server SHOULD send a 304 (Not
	Modified) response.		Modified) response.
	The purpose of this feature is to allow efficient updates of cached		The two purposes of this feature are to allow efficient updates of
	information with a minimum amount of transaction overhead.		cached information, with a minimum amount of transaction overhead,
			and to limit the scope of a web traversal to resources that have
	Note: The Range header field modifies the meaning of If-Modified-		recently changed.
	Since; see Section 5.4 of [Part5] for full details.
	Note: If-Modified-Since times are interpreted by the server, whose		When used for cache updates, a cache will typically use the value of
	clock might not be synchronized with the client.		the cached message's Last-Modified field to generate the field value
			of If-Modified-Since. This behavior is most interoperable for cases
			where clocks are poorly synchronized or when the server has chosen to
			only honor exact timestamp matches (due to a problem with Last-
			Modified dates that appear to go "back in time" when the origin
			server's clock is corrected or a representation is restored from an
			archived backup). However, caches occasionally generate the field
			value based on other data, such as the Date header field of the
			cached message or the local clock time that the message was received,
			particularly when the cached message does not contain a Last-Modified
			field.
	Note: When handling an If-Modified-Since header field, some		When used for limiting the scope of retrieval to a recent time
	servers will use an exact date comparison function, rather than a		window, a user agent will generate an If-Modified-Since field value
	less-than function, for deciding whether to send a 304 (Not		based on either its own local clock or a Date header field received
	Modified) response. To get best results when sending an If-		from the server during a past run. Origin servers that choose an
	Modified-Since header field for cache validation, clients are		exact timestamp match based on the selected representation's Last-
	advised to use the exact date string received in a previous Last-		Modified field will not be able to help the user agent limit its data
	Modified header field whenever possible.		transfers to only those changed during the specified window.
	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 field instead of a date taken from the Last-Modified header		header field instead of a date taken from a Last-Modified or Date
	field for the same request, the client needs to be aware that this		header field from the origin server, the client ought to be aware
	date is interpreted in the server's understanding of time.		that its date will be interpreted according to the server's
	Unsynchronized clocks and rounding problems, due to the different		understanding of time.
	encodings of time between the client and server, are concerns.
	This includes the possibility of race conditions if the document
	has changed between the time it was first requested and the If-
	Modified-Since date of a subsequent request, and the possibility
	of clock-skew-related problems if the If-Modified-Since date is
	derived from the client's clock without correction to the server's
	clock. Corrections for different time bases between client and
	server are at best approximate due to network latency.
	3.4. If-Unmodified-Since		3.4. If-Unmodified-Since
	The "If-Unmodified-Since" header field can be used to make a request		The "If-Unmodified-Since" header field can be used to make a request
	method conditional by modification date: if the selected		method conditional by modification date: if the selected
	representation has been modified since the time specified in this		representation has been modified since the time specified in this
	field, then the server MUST NOT perform the requested operation and		field, then the server MUST NOT perform the requested operation and
	MUST instead respond with the 412 (Precondition Failed) status code.		MUST instead respond with the 412 (Precondition Failed) status code.
	If the selected representation has not been modified since the time		If the selected representation has not been modified since the time
	specified in this field, the server SHOULD perform the request method		specified in this field, the server MAY perform the request.
	as if the If-Unmodified-Since header field were not present.
	If-Unmodified-Since = HTTP-date		If-Unmodified-Since = 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 a request normally (i.e., in absence of the If-Unmodified-Since		A server MUST ignore the If-Unmodified-Since header field if the
	header field) would result in anything other than a 2xx (Successful)		received value is not a valid HTTP-date.
	or 412 (Precondition Failed) status code, the If-Unmodified-Since
	header field SHOULD be ignored.
	If the specified date is invalid, the header field MUST be ignored.
	3.5. If-Range		3.5. If-Range
	The "If-Range" header field provides a special conditional request		The "If-Range" header field provides a special conditional request
	mechanism that is similar to If-Match and If-Unmodified-Since but		mechanism that is similar to If-Match and If-Unmodified-Since but
	specific to HTTP range requests. If-Range is defined in Section 5.3		specific to range requests. If-Range is defined in Section 3.2 of
	of [Part5].		[Part5].
	4. Status Code Definitions		4. Status Code Definitions
	4.1. 304 Not Modified		4.1. 304 Not Modified
	The 304 status code indicates that a conditional GET request has been		The 304 (Not Modified) status code indicates that a conditional GET
	received and would have resulted in a 200 (OK) response if it were		request has been received and would have resulted in a 200 (OK)
	not for the fact that the condition has evaluated to false. In other		response if it were not for the fact that the condition has evaluated
	words, there is no need for the server to transfer a representation		to false. In other words, there is no need for the server to
	of the target resource because the client's request indicates that it		transfer a representation of the target resource because the request
	already has a valid representation, as indicated by the 304 response		indicates that the client, which made the request conditional,
	header fields, and is therefore redirecting the client to make use of		already has a valid representation; the server is therefore
	that stored representation as if it were the payload of a 200		redirecting the client to make use of that stored representation as
	response. The 304 response MUST NOT contain a message-body, and thus		if it were the payload of a 200 (OK) response.
	is always terminated by the first empty line after the header fields.
	A 304 response MUST include a Date header field (Section 8.1.1.2 of		The server generating a 304 response MUST generate any of the
	[Part2]) unless the origin server does not have a clock that can		following header fields that would have been sent in a 200 (OK)
	provide a reasonable approximation of the current time. If a 200		response to the same request: Cache-Control, Content-Location, ETag,
	(OK) response to the same request would have included any of the		Expires, and Vary.
	header fields Cache-Control, Content-Location, ETag, Expires, or
	Vary, then those same header fields MUST be sent in a 304 response.
	Since the goal of a 304 response is to minimize information transfer		Since the goal of a 304 response is to minimize information transfer
	when the recipient already has one or more cached representations,		when the recipient already has one or more cached representations, a
	the response SHOULD NOT include representation metadata other than		sender SHOULD NOT generate representation metadata other than the
	the above listed fields unless said metadata exists for the purpose		above listed fields unless said metadata exists for the purpose of
	of guiding cache updates (e.g., future HTTP extensions).		guiding cache updates (e.g., Last-Modified might be useful if the
			response does not have an ETag field).
	If the recipient of a 304 response does not have a cached		Requirements on a cache that receives a 304 response are defined in
	representation corresponding to the entity-tag indicated by the 304		Section 4.2.1 of [Part6]. If the conditional request originated with
	response, then the recipient MUST NOT use the 304 to update its own		an outbound client, such as a user agent with its own cache sending a
	cache. If this conditional request originated with an outbound		conditional GET to a shared proxy, then the proxy SHOULD forward the
	client, such as a user agent with its own cache sending a conditional		304 response to that client.
	GET to a shared proxy, then the 304 response MAY be forwarded to that
	client. Otherwise, the recipient MUST disregard the 304 response and
	repeat the request without any preconditions.
	If a cache uses a received 304 response to update a cache entry, the		A 304 response cannot contain a message-body; it is always terminated
	cache MUST update the entry to reflect any new field values given in		by the first empty line after the header fields.
	the response.
	4.2. 412 Precondition Failed		4.2. 412 Precondition Failed
	The 412 status code indicates that one or more preconditions given in		The 412 (Precondition Failed) status code indicates that one or more
	the request header fields evaluated to false when tested on the		preconditions given in the request header fields evaluated to false
	server. This response code allows the client to place preconditions		when tested on the server. This response code allows the client to
	on the current resource state (its current representations and		place preconditions on the current resource state (its current
	metadata) and thus prevent the request method from being applied if		representations and metadata) and thus prevent the request method
	the target resource is in an unexpected state.		from being applied if the target resource is in an unexpected state.
	5. Precedence		5. Evaluation and Precedence
			For each conditional request, a server MUST evaluate the request
			preconditions after it has successfully performed its normal request
			checks (i.e., just before it would perform the action associated with
			the request method). Preconditions are ignored if the server
			determines that an error or redirect response applies before they are
			evaluated. Otherwise, the evaluation depends on both the method
			semantics and the choice of conditional.
			A conditional request header field that is designed specifically for
			cache validation, which includes If-None-Match and If-Modified-Since
			when used in a GET or HEAD request, allows cached representations to
			be refreshed without repeatedly transferring data already held by the
			client. Evaluating to false is thus an indication that the client
			can continue to use its local copy of the selected representation, as
			indicated by the server generating a 304 (Not Modified) response that
			includes only those header fields useful for refreshing the cached
			representation.
			All other conditionals are intended to signal failure when the
			precondition evaluates to false. For example, an If-Match
			conditional sent with a state-changing method (e.g., POST, PUT,
			DELETE) is intended to prevent the request from taking effect on the
			target resource if the resource state does not match the expected
			state. In other words, evaluating the condition to false means that
			the resource has been changed by some other client, perhaps by
			another user attempting to edit the same resource, and thus
			preventing the request from being applied saves the client from
			overwriting some other client's work. This result is indicated by
			the server generating a 412 (Precondition Failed) response.
			The conditional request header fields defined by this specification
			are ignored for request methods that never involve the selection or
			modification of a selected representation (e.g., CONNECT, OPTIONS,
			and TRACE). Other conditional request header fields, defined by
			extensions to HTTP, might place conditions on the state of the target
			resource in general, or on a group of resources. For instance, the
			If header field in WebDAV can make a request conditional on various
			aspects (such as locks) of multiple resources ([RFC4918], Section
			10.4).
	When more than one conditional request header field is present in a		When more than one conditional request header field is present in a
	request, the order in which the fields are evaluated becomes		request, the order in which the fields are evaluated becomes
	important. In practice, the fields defined in this document are		important. In practice, the fields defined in this document are
	consistently implemented in a single, logical order, due to the fact		consistently implemented in a single, logical order, due to the fact
	that entity tags are presumed to be more accurate than date		that entity tags are presumed to be more accurate than date
	validators. For example, the only reason to send both If-Modified-		validators. For example, the only reason to send both If-Modified-
	Since and If-None-Match in the same GET request is to support		Since and If-None-Match in the same GET request is to support
	intermediary caches that might not have implemented If-None-Match, so		intermediary caches that might not have implemented If-None-Match, so
	it makes sense to ignore the If-Modified-Since when entity tags are		it makes sense to ignore the If-Modified-Since when entity tags are
	skipping to change at page 19, line 41		skipping to change at page 19, line 27
	* if false, respond 412 (Precondition Failed)		* if false, respond 412 (Precondition Failed)
	2. When If-Match is not present and If-Unmodified-Since is present,		2. When If-Match is not present and If-Unmodified-Since is present,
	evaluate it:		evaluate it:
	* if true, continue to step 3		* if true, continue to step 3
	* if false, respond 412 (Precondition Failed)		* if false, respond 412 (Precondition Failed)
	3. When the method is GET and both Range and If-Range are present,		3. When If-None-Match is present, evaluate it:
	evaluate it:
	* if the validator matches, respond 206 (Partial Content)
	* if the validator does not match, respond 200 (OK)
	4. When If-None-Match is present, evaluate it:		* if true, continue to step 5
	* if true, all conditions are met
	* if false for GET/HEAD, respond 304 (Not Modified)		* if false for GET/HEAD, respond 304 (Not Modified)
	* if false for other methods, respond 412 (Precondition Failed)		* if false for other methods, respond 412 (Precondition Failed)
	5. When the method is GET or HEAD, If-None-Match is not present, and		4. When the method is GET or HEAD, If-None-Match is not present, and
	If-Modified-Since is present, evaluate it:		If-Modified-Since is present, evaluate it:
	* if true, all conditions are met		* if true, continue to step 5
	* if false, respond 304 (Not Modified)		* if false, respond 304 (Not Modified)
			5. When the method is GET and both Range and If-Range are present,
			evaluate If-Range:
			* if the validator matches and the Range specification is
			applicable to the selected representation, respond 206
			(Partial Content) [Part5]
			6. Otherwise,
			* all conditions are met, so perform the requested action and
			respond according to its success or failure.
	Any extension to HTTP/1.1 that defines additional conditional request		Any extension to HTTP/1.1 that defines additional conditional request
	header fields ought to define its own expectations regarding the		header fields ought to define its own expectations regarding the
	order for evaluating such fields in relation to those defined in this		order for evaluating such fields in relation to those defined in this
	document and other conditionals that might be found in practice.		document and other conditionals that might be found in practice.
	6. IANA Considerations		6. IANA Considerations
	6.1. Status Code Registration		6.1. Status Code Registration
	The HTTP Status Code Registry located at		The HTTP Status Code Registry located at
	skipping to change at page 20, line 39		skipping to change at page 20, line 29
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+---------------------+-------------+		+-------+---------------------+-------------+
	| 304 | Not Modified | Section 4.1 |		| 304 | Not Modified | Section 4.1 |
	| 412 | Precondition Failed | Section 4.2 |		| 412 | Precondition Failed | Section 4.2 |
	+-------+---------------------+-------------+		+-------+---------------------+-------------+
	6.2. Header Field Registration		6.2. Header Field Registration
	The Message Header Field Registry located at <http://www.iana.org/		The Message Header Field Registry located at <http://www.iana.org/
	assignments/message-headers/message-header-index.html> shall be		assignments/message-headers/message-header-index.html> shall be
	updated with the permanent registrations below (see [RFC3864]):		updated with the permanent registrations below (see [BCP90]):
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	| ETag | http | standard | Section 2.3 |		| ETag | http | standard | Section 2.3 |
	| If-Match | http | standard | Section 3.1 |		| If-Match | http | standard | Section 3.1 |
	| If-Modified-Since | http | standard | Section 3.3 |		| If-Modified-Since | http | standard | Section 3.3 |
	| If-None-Match | http | standard | Section 3.2 |		| If-None-Match | http | standard | Section 3.2 |
	| If-Unmodified-Since | http | standard | Section 3.4 |		| If-Unmodified-Since | http | standard | Section 3.4 |
	| Last-Modified | http | standard | Section 2.2 |		| Last-Modified | http | standard | Section 2.2 |
	skipping to change at page 21, line 4		skipping to change at page 20, line 41
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	| ETag | http | standard | Section 2.3 |		| ETag | http | standard | Section 2.3 |
	| If-Match | http | standard | Section 3.1 |		| If-Match | http | standard | Section 3.1 |
	| If-Modified-Since | http | standard | Section 3.3 |		| If-Modified-Since | http | standard | Section 3.3 |
	| If-None-Match | http | standard | Section 3.2 |		| If-None-Match | http | standard | Section 3.2 |
	| If-Unmodified-Since | http | standard | Section 3.4 |		| If-Unmodified-Since | http | standard | Section 3.4 |
	| Last-Modified | http | standard | Section 2.2 |		| Last-Modified | http | standard | Section 2.2 |
	+---------------------+----------+----------+-------------+		+---------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	7. Security Considerations		7. Security Considerations
	No additional security considerations have been identified beyond		This section is meant to inform developers, information providers,
	those applicable to HTTP in general [Part1].		and users of known security concerns specific to the HTTP/1.1
			conditional request mechanisms. More general security considerations
			are addressed in HTTP messaging [Part1] and semantics [Part2].
	The validators defined by this specification are not intended to		The validators defined by this specification are not intended to
	ensure the validity of a representation, guard against malicious		ensure the validity of a representation, guard against malicious
	changes, or detect man-in-the-middle attacks. At best, they enable		changes, or detect man-in-the-middle attacks. At best, they enable
	more efficient cache updates and optimistic concurrent writes when		more efficient cache updates and optimistic concurrent writes when
	all participants are behaving nicely. At worst, the conditions will		all participants are behaving nicely. At worst, the conditions will
	fail and the client will receive a response that is no more harmful		fail and the client will receive a response that is no more harmful
	than an HTTP exchange without conditional requests.		than an HTTP exchange without conditional requests.
			An entity-tag can be abused in ways that create privacy risks. For
			example, a site might deliberately construct a semantically invalid
			entity-tag that is unique to the user or user agent, send it in a
			cacheable response with a long freshness time, and then read that
			entity-tag in later conditional requests as a means of re-identifying
			that user or user agent. Such an identifying tag would become a
			persistent identifier for as long as the user agent retained the
			original cache entry. User agents that cache representations ought
			to ensure that the cache is cleared or replaced whenever the user
			performs privacy-maintaining actions, such as clearing stored cookies
			or changing to a private browsing mode.
	8. Acknowledgments		8. Acknowledgments
	See Section 9 of [Part1].		See Section 9 of [Part1].
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-21 (work in progress),		draft-ietf-httpbis-p1-messaging-22 (work in progress),
	October 2012.		February 2013.
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-21 (work in progress),		draft-ietf-httpbis-p2-semantics-22 (work in progress),
	October 2012.		February 2013.
	[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",		"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
	draft-ietf-httpbis-p5-range-21 (work in progress),		draft-ietf-httpbis-p5-range-22 (work in progress),
	October 2012.		February 2013.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-21 (work in progress),		draft-ietf-httpbis-p6-cache-22 (work in progress),
	October 2012.		February 2013.
	[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.
	9.2. Informative References		9.2. Informative References
			[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
			Procedures for Message Header Fields", BCP 90, RFC 3864,
			September 2004.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.
	[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed		[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
	Authoring and Versioning (WebDAV)", RFC 4918, June 2007.		Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
	Appendix A. Changes from RFC 2616		Appendix A. Changes from RFC 2616
	Allow weak entity-tags in all requests except range requests		The definition of validator weakness has been expanded and clarified.
	(Sections 2.1 and 3.2).		(Section 2.1)
	Change "ETag" header field ABNF not to use quoted-string, thus		Weak entity-tags are now allowed in all requests except range
	avoiding escaping issues. (Section 2.3)		requests (Sections 2.1 and 3.2).
			The ETag header field ABNF has been changed to not use quoted-string,
			thus avoiding escaping issues. (Section 2.3)
			ETag is defined to provide an entity tag for the selected
			representation, thereby clarifying what it applies to in various
			situations (such as a PUT response). (Section 2.3)
			The precedence for evaluation of conditional requests has been
			defined. (Section 5)
	Appendix B. Imported ABNF		Appendix B. Imported ABNF
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),		Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
	CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double		CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
	quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any		quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
	8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII		8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
	character).		character).
	The rules below are defined in [Part1]:		The rules below are defined in [Part1]:
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	obs-text = <obs-text, defined in [Part1], Section 3.2.4>		obs-text = <obs-text, defined in [Part1], Section 3.2.6>
	The rules below are defined in other parts:		The rules below are defined in other parts:
	HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1>
	Appendix C. Collected ABNF		Appendix C. Collected ABNF
	ETag = entity-tag		ETag = entity-tag
	HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1>
	If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS		If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
	entity-tag ] ) )		entity-tag ] ) )
	If-Modified-Since = HTTP-date		If-Modified-Since = HTTP-date
	If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS		If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
	entity-tag ] ) )		entity-tag ] ) )
	If-Unmodified-Since = HTTP-date		If-Unmodified-Since = HTTP-date
	Last-Modified = HTTP-date		Last-Modified = HTTP-date
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.3>
	entity-tag = [ weak ] opaque-tag		entity-tag = [ weak ] opaque-tag
	etagc = "!" / %x23-7E ; '#'-'~'		etagc = "!" / %x23-7E ; '#'-'~'
	/ obs-text		/ obs-text
	obs-text = <obs-text, defined in [Part1], Section 3.2.4>		obs-text = <obs-text, defined in [Part1], Section 3.2.6>
	opaque-tag = DQUOTE *etagc DQUOTE		opaque-tag = DQUOTE *etagc DQUOTE
	weak = %x57.2F ; W/		weak = %x57.2F ; W/
	Appendix D. Change Log (to be removed by RFC Editor before publication)		Appendix D. Change Log (to be removed by RFC Editor before publication)
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the first Working Group Last Call draft are summarized
	in <http://tools.ietf.org/html/		in <http://tools.ietf.org/html/
	draft-ietf-httpbis-p4-conditional-19#appendix-C>.		draft-ietf-httpbis-p4-conditional-19#appendix-C>.
	skipping to change at page 24, line 24		skipping to change at page 24, line 30
	Since lacks definition for method != GET"		Since lacks definition for method != GET"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor		o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor
	conditional header field descriptions"		conditional header field descriptions"
	D.2. Since draft-ietf-httpbis-p4-conditional-20		D.2. Since draft-ietf-httpbis-p4-conditional-20
	o Conformance criteria and considerations regarding error handling		o Conformance criteria and considerations regarding error handling
	are now defined in Part 1.		are now defined in Part 1.
			D.3. Since draft-ietf-httpbis-p4-conditional-21
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/96>: "Conditional
			GET text"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality
			of Conditional Request Support"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/384>: "unclear prose
			in definition of 304"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/401>: "ETags and
			Conneg"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/402>: "Comparison
			function for If-Match and If-None-Match"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/406>: "304 without
			validator"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/427>: "If-Match and
			428"
	Index		Index
	3		3
	304 Not Modified (status code) 18		304 Not Modified (status code) 17
	4		4
	412 Precondition Failed (status code) 18		412 Precondition Failed (status code) 17
	E		E
	ETag header field 9		ETag header field 9
	G		G
	Grammar		Grammar
	entity-tag 9		entity-tag 9
	ETag 9		ETag 9
	etagc 9		etagc 9
	If-Match 14		If-Match 13
	If-Modified-Since 16		If-Modified-Since 15
	If-None-Match 15		If-None-Match 14
	If-Unmodified-Since 17		If-Unmodified-Since 16
	Last-Modified 7		Last-Modified 7
	opaque-tag 9		opaque-tag 9
	weak 9		weak 9
	I		I
	If-Match header field 13		If-Match header field 13
	If-Modified-Since header field 16		If-Modified-Since header field 15
	If-None-Match header field 14		If-None-Match header field 14
	If-Unmodified-Since header field 17		If-Unmodified-Since header field 16
	L		L
	Last-Modified header field 7		Last-Modified header field 7
	M		M
	metadata 5		metadata 5
	S		S
	selected representation 4		selected representation 4
End of changes. 86 change blocks.
	255 lines changed or deleted		308 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/