draft-ietf-httpbis-p4-conditional-25.txt		draft-ietf-httpbis-p4-conditional-26.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: May 21, 2014 November 17, 2013		Expires: August 10, 2014 February 6, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests		Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
	draft-ietf-httpbis-p4-conditional-25		draft-ietf-httpbis-p4-conditional-26
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	protocol for distributed, collaborative, hypertext information		level 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.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	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.1.		The changes in this draft are summarized in Appendix D.2.
	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 May 21, 2014.		This Internet-Draft will expire on August 10, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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 16		skipping to change at page 3, line 16
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		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 . . . . . . . . . . . . . . . . . . . . . . 9		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. When to Use Entity-tags and Last-Modified Dates . . . . . 12		2.4. When to Use Entity-tags and Last-Modified 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 . . . . . . . . . . . . . . . . . . . . 15		3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15
	3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16		3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16
	3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18		3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18
	skipping to change at page 3, line 46		skipping to change at page 3, line 46
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 23		10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	10.2. Informative References . . . . . . . . . . . . . . . . . . 23		10.2. Informative References . . . . . . . . . . . . . . . . . . 23
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 23		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 23
	Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 24		Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 24
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 24		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 24
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 25		publication) . . . . . . . . . . . . . . . . . . . . 25
	D.1. Since draft-ietf-httpbis-p4-conditional-24 . . . . . . . . 25		D.1. Since draft-ietf-httpbis-p4-conditional-24 . . . . . . . . 25
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		D.2. Since draft-ietf-httpbis-p4-conditional-25 . . . . . . . . 25
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	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. This document		applying the method semantics to the target resource. This document
	defines the HTTP/1.1 conditional request mechanisms in terms of the		defines the HTTP/1.1 conditional request mechanisms in terms of the
	architecture, syntax notation, and conformance criteria defined in		architecture, syntax notation, and conformance criteria defined in
	[Part1].		[Part1].
	skipping to change at page 4, line 48		skipping to change at page 4, line 48
	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].
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] with the list rule extension defined in Section		notation of [RFC5234] with a list extension, defined in Section 7 of
	7 of [Part1]. Appendix B describes rules imported from other		[Part1], that allows for compact definition of comma-separated lists
	documents. Appendix C shows the collected ABNF with the list rule		using a '#' operator (similar to how the '*' operator indicates
	expanded.		repetition). Appendix B describes rules imported from other
			documents. Appendix C shows the collected grammar with all list
			operators expanded to standard ABNF notation.
	2. Validators		2. Validators
	This specification defines two forms of metadata that are commonly		This specification defines two forms of metadata that are commonly
	used to observe resource state and test for preconditions:		used to observe resource state and test for preconditions:
	modification dates (Section 2.2) and opaque entity tags		modification dates (Section 2.2) and opaque entity tags
	(Section 2.3). Additional metadata that reflects resource state has		(Section 2.3). Additional metadata that reflects resource state has
	been defined by various extensions of HTTP, such as WebDAV [RFC4918],		been defined by various extensions of HTTP, such as WebDAV [RFC4918],
	that are beyond the scope of this specification. A resource metadata		that are beyond the scope of this specification. A resource metadata
	value is referred to as a "validator" when it is used within a		value is referred to as a "validator" when it is used within a
	skipping to change at page 10, line 14		skipping to change at page 10, line 19
	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.
	For example, a resource that has implementation-specific versioning		For example, a resource that has implementation-specific versioning
	applied to all changes might use an internal revision number, perhaps		applied to all changes might use an internal revision number, perhaps
	combined with a variance identifier for content negotiation, to		combined with a variance identifier for content negotiation, to
	accurately differentiate between representations. Other		accurately differentiate between representations. Other
	implementations might use a collision-resistant hash of		implementations might use a collision-resistant hash of
	representation content, a combination of various filesystem		representation content, a combination of various file attributes, or
	attributes, or a modification timestamp that has sub-second		a modification timestamp that has sub-second resolution.
	resolution.
	An origin server SHOULD send ETag for any selected representation for		An origin server SHOULD send ETag for any selected representation for
	which detection of changes can be reasonably and consistently		which detection of changes can be reasonably and consistently
	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
	skipping to change at page 12, line 15		skipping to change at page 12, line 15
	Note: Content codings are a property of the representation data,		Note: Content codings are a property of the representation data,
	so a strong entity-tag for a content-encoded representation has to		so a strong entity-tag for a content-encoded representation has to
	be distinct from the entity tag of an unencoded representation to		be distinct from the entity tag of an unencoded representation to
	prevent potential conflicts during cache updates and range		prevent potential conflicts during cache updates and range
	requests. In contrast, transfer codings (Section 4 of [Part1])		requests. In contrast, transfer codings (Section 4 of [Part1])
	apply only during message transfer and do not result in distinct		apply only during message transfer and do not result in distinct
	entity-tags.		entity-tags.
	2.4. 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,
	clients, and caches regarding when various validator types ought to
	be used, and for what purposes.
	In 200 (OK) responses to GET or HEAD, an origin server:		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.
	skipping to change at page 22, line 22		skipping to change at page 22, line 22
	| 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".
	8. Security Considerations		8. Security Considerations
	This section is meant to inform developers, information providers,		This section is meant to inform developers, information providers,
	and users of known security concerns specific to the HTTP/1.1		and users of known security concerns specific to the HTTP conditional
	conditional request mechanisms. More general security considerations		request mechanisms. More general security considerations are
	are addressed in HTTP messaging [Part1] and semantics [Part2].		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		An entity-tag can be abused in ways that create privacy risks. For
	skipping to change at page 23, line 8		skipping to change at page 23, line 8
	9. Acknowledgments		9. Acknowledgments
	See Section 10 of [Part1].		See Section 10 of [Part1].
	10. References		10. References
	10.1. Normative References		10.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-25 (work in progress),		draft-ietf-httpbis-p1-messaging-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p2-semantics-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p5-range-26 (work in progress),
	November 2013.		February 2014.
	[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-25 (work in progress),		draft-ietf-httpbis-p6-cache-26 (work in progress),
	November 2013.		February 2014.
	[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
	[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	skipping to change at page 25, line 41		skipping to change at page 25, line 41
	Changes up to the IETF Last Call draft are summarized in <http://		Changes up to the IETF Last Call draft are summarized in <http://
	tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-24#appendix-D>.		tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-24#appendix-D>.
	D.1. Since draft-ietf-httpbis-p4-conditional-24		D.1. Since draft-ietf-httpbis-p4-conditional-24
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/518>: "APPSDIR		o <http://tools.ietf.org/wg/httpbis/trac/ticket/518>: "APPSDIR
	review of draft-ietf-httpbis-p4-conditional-24"		review of draft-ietf-httpbis-p4-conditional-24"
			D.2. Since draft-ietf-httpbis-p4-conditional-25
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
			'stateless' to Abstract"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
			introduction of list rule"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
			security considerations with pointers to current research"
	Index		Index
	3		3
	304 Not Modified (status code) 18		304 Not Modified (status code) 18
	4		4
	412 Precondition Failed (status code) 18		412 Precondition Failed (status code) 18
	E		E
	ETag header field 9		ETag header field 9
End of changes. 17 change blocks.
	31 lines changed or deleted		42 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/