draft-ietf-httpbis-p4-conditional-24.txt		draft-ietf-httpbis-p4-conditional-25.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: March 29, 2014 September 25, 2013		Expires: May 21, 2014 November 17, 2013
	Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests		Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
	draft-ietf-httpbis-p4-conditional-24		draft-ietf-httpbis-p4-conditional-25
	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.5.		The changes in this draft are summarized in Appendix D.1.
	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 March 29, 2014.		This Internet-Draft will expire on May 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	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 . . . . . . . . . . . . . . . . . . . . . . 10		2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 9
	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 45		skipping to change at page 3, line 45
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 22		8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	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-19 . . . . . . . . 25		D.1. Since draft-ietf-httpbis-p4-conditional-24 . . . . . . . . 25
	D.2. Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 26		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	D.3. Since draft-ietf-httpbis-p4-conditional-21 . . . . . . . . 26
	D.4. Since draft-ietf-httpbis-p4-conditional-22 . . . . . . . . 26
	D.5. Since draft-ietf-httpbis-p4-conditional-23 . . . . . . . . 27
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	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 5, line 30		skipping to change at page 5, line 30
	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 representation metadata that changes value		A "strong validator" is representation metadata that changes value
	whenever a change occurs to the representation data that would be		whenever a change occurs to the representation data that would be
	observable in the payload body of a 200 (OK) response to GET.		observable in the payload body of a 200 (OK) response to GET.
	A strong validator might change for other reasons, such as when a		A strong validator might change for reasons other than a change to
	semantically significant part of the representation metadata is		the representation data, such as when a semantically significant part
	changed (e.g., Content-Type), but it is in the best interests of the		of the representation metadata is changed (e.g., Content-Type), but
	origin server to only change the value when it is necessary to		it is in the best interests of the origin server to only change the
	invalidate the stored responses held by remote caches and authoring		value when it is necessary to invalidate the stored responses held by
	tools. A strong validator is unique across all representations of a		remote caches and authoring tools.
	given resource, such that no two representations of that resource can
	share the same validator unless their representation data is
	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 is unique across all versions of all representations		strong validator is unique across all versions of all representations
	associated with a particular resource over time. However, there is		associated with a particular resource over time. However, there is
	no implication of uniqueness across representations of different		no implication of uniqueness across representations of different
	resources (i.e., the same strong validator might be in use for		resources (i.e., the same strong validator might be in use for
	representations of multiple resources at the same time and does not		representations of multiple resources at the same time and does not
	imply that those representations are equivalent).		imply that those representations are equivalent).
	skipping to change at page 12, line 5		skipping to change at page 12, line 5
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Date: Fri, 26 Mar 2010 00:05:00 GMT		Date: Fri, 26 Mar 2010 00:05:00 GMT
	ETag: "123-b"		ETag: "123-b"
	Content-Length: 43		Content-Length: 43
	Vary: Accept-Encoding		Vary: Accept-Encoding
	Content-Type: text/plain		Content-Type: text/plain
	Content-Encoding: gzip		Content-Encoding: gzip
	...binary data...		...binary data...
	Note: Content codings are a property of the representation, so		Note: Content codings are a property of the representation data,
	therefore an entity-tag of an encoded representation has to be		so a strong entity-tag for a content-encoded representation has to
	distinct from an unencoded representation to prevent conflicts		be distinct from the entity tag of an unencoded representation to
	during cache updates and range requests. In contrast, transfer		prevent potential conflicts during cache updates and range
	codings (Section 4 of [Part1]) apply only during message transfer		requests. In contrast, transfer codings (Section 4 of [Part1])
	and do not require distinct entity-tags.		apply only during message transfer and do not result in distinct
			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,		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.
	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
	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-24 (work in progress),		draft-ietf-httpbis-p1-messaging-25 (work in progress),
	September 2013.		November 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-24 (work in progress),		draft-ietf-httpbis-p2-semantics-25 (work in progress),
	September 2013.		November 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-24 (work in progress),		draft-ietf-httpbis-p5-range-25 (work in progress),
	September 2013.		November 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-24 (work in progress),		draft-ietf-httpbis-p6-cache-25 (work in progress),
	September 2013.		November 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.
	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 31		skipping to change at page 25, line 31
	etagc = "!" / %x23-7E ; '#'-'~'		etagc = "!" / %x23-7E ; '#'-'~'
	/ obs-text		/ obs-text
	obs-text = <obs-text, defined in [Part1], Section 3.2.6>		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 IETF Last Call draft are summarized in <http://
	in <http://tools.ietf.org/html/		tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-24#appendix-D>.
	draft-ietf-httpbis-p4-conditional-19#appendix-C>.
	D.1. Since draft-ietf-httpbis-p4-conditional-19
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to
	clarify eval order/interaction of conditional headers"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/345>: "Required
	headers on 304 and 206"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality
	of Conditional Request Support"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and
	Conditional Requests"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
	requirements for recipients"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional
	Request Security Considerations"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified-
	Since lacks definition for method != GET"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor
	conditional header field descriptions"
	D.2. Since draft-ietf-httpbis-p4-conditional-20
	o Conformance criteria and considerations regarding error handling
	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"
	D.4. Since draft-ietf-httpbis-p4-conditional-22
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
	expansion in ABNF appendices"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/437>: "incorrect
	example dates"
	Partly resolved issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/461>: "Editorial
	suggestions"
	D.5. Since draft-ietf-httpbis-p4-conditional-23		D.1. Since draft-ietf-httpbis-p4-conditional-24
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/455>: "PUT + If-		o <http://tools.ietf.org/wg/httpbis/trac/ticket/518>: "APPSDIR
	Match over-constrained?"		review of draft-ietf-httpbis-p4-conditional-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/479>: "MUSTs and
	other feedback"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/495>: "p4 editorial
	nits"
	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
End of changes. 15 change blocks.
	121 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/