draft-ietf-httpbis-p4-conditional-18.txt		draft-ietf-httpbis-p4-conditional-latest.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: July 7, 2012 J. Mogul		Expires: August 6, 2012 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	January 4, 2012		February 3, 2012
	HTTP/1.1, part 4: Conditional Requests		HTTP/1.1, part 4: Conditional Requests
	draft-ietf-httpbis-p4-conditional-18		draft-ietf-httpbis-p4-conditional-latest
	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. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 4 of the		information initiative since 1990. This document is Part 4 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616.		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org), which is archived at		group 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 C.19.		The changes in this draft are summarized in Appendix C.20.
	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 July 7, 2012.		This Internet-Draft will expire on August 6, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 4, line 9		skipping to change at page 4, line 9
	C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 25		C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 25
	C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 25		C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 25
	C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25		C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25
	C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 26		C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 26
	C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 26		C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 26
	C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 26		C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 26
	C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 26		C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 26
	C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 26		C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 26
	C.18. Since draft-ietf-httpbis-p4-conditional-16 . . . . . . . . 26		C.18. Since draft-ietf-httpbis-p4-conditional-16 . . . . . . . . 26
	C.19. Since draft-ietf-httpbis-p4-conditional-17 . . . . . . . . 27		C.19. Since draft-ietf-httpbis-p4-conditional-17 . . . . . . . . 27
			C.20. Since draft-ietf-httpbis-p4-conditional-18 . . . . . . . . 27
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	This document defines the HTTP/1.1 conditional request mechanisms,		This document defines the HTTP/1.1 conditional request mechanisms,
	including both metadata for indicating/observing changes in resource		including both metadata for indicating/observing changes in resource
	representations and request header fields that specify preconditions		representations and request header fields that specify preconditions
	on that metadata be checked before performing the request method.		on that metadata be checked before performing the request method.
	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-
	skipping to change at page 6, line 19		skipping to change at page 6, line 19
	define specific error handling mechanisms, except in cases where it		define specific error handling mechanisms, except in cases where it
	has direct impact on security. This is because different uses of the		has direct impact on security. This is because different uses of the
	protocol require different error handling strategies; for example, a		protocol require different error handling strategies; for example, a
	Web browser may wish to transparently recover from a response where		Web browser may wish to transparently recover from a response where
	the Location header field doesn't parse according to the ABNF,		the Location header field doesn't parse according to the ABNF,
	whereby in a systems control protocol using HTTP, this type of error		whereby in a systems control protocol using HTTP, this type of error
	recovery could lead to dangerous consequences.		recovery could lead to dangerous consequences.
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the Augmented Backus-Naur Form (ABNF)
	[Part1] (which extends the syntax defined in [RFC5234] with a list		notation of [RFC5234] with the list rule extension defined in Section
	rule). Appendix B shows the collected ABNF, with the list rule		1.2 of [Part1]. Appendix B shows the collected ABNF with the list
	expanded.		rule expanded.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		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		sequence of data), SP (space), and VCHAR (any visible US-ASCII
	character).		character).
	The ABNF rules below are defined in [Part1] and [Part2]:		The ABNF rules below are defined in [Part1] and [Part2]:
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	obs-text = <obs-text, defined in [Part1], Section 3.2.3>		obs-text = <obs-text, defined in [Part1], Section 3.2.4>
	HTTP-date = <HTTP-date, defined in [Part2], Section 8>		HTTP-date = <HTTP-date, defined in [Part2], Section 8>
	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 and opaque entity tags. Additional metadata that		modification dates and opaque entity tags. Additional metadata that
	reflects resource state has been defined by various extensions of		reflects resource state has been defined by various extensions of
	HTTP, such as WebDAV [RFC4918], that are beyond the scope of this		HTTP, such as WebDAV [RFC4918], that are beyond the scope of this
	specification. A resource metadata value is referred to as a		specification. A resource metadata value is referred to as a
	skipping to change at page 16, line 6		skipping to change at page 16, line 6
	anything other than a 2xx or 412 status code, then the If-Match		anything other than a 2xx or 412 status code, then the If-Match
	header field MUST be ignored.		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: *
	The result of a request having both an If-Match header field and		The result of a request having both an If-Match header field and
	either an If-None-Match or an If-Modified-Since header fields is		either an If-None-Match or an If-Modified-Since header field is
	undefined by this specification.		undefined by this specification.
	3.2. If-None-Match		3.2. If-None-Match
	The "If-None-Match" header field MAY be used to make a request method		The "If-None-Match" header field MAY 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
	representations of the target resource. If-None-Match is primarily		representations of the target resource. If-None-Match is primarily
	used in conditional GET requests to enable efficient updates of		used in conditional GET requests to enable efficient updates of
	cached information with a minimum amount of transaction overhead. A		cached information with a minimum amount of transaction overhead. A
	client that has one or more representations previously obtained from		client that has one or more representations previously obtained from
	skipping to change at page 17, line 15		skipping to change at page 17, line 15
	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: *
	The result of a request having both an If-None-Match header field and		The result of a request having both an If-None-Match header field and
	either an If-Match or an If-Unmodified-Since header fields is		either an If-Match or an If-Unmodified-Since header field is
	undefined by this specification.		undefined by this specification.
	3.3. If-Modified-Since		3.3. If-Modified-Since
	The "If-Modified-Since" header field MAY be used to make a request		The "If-Modified-Since" header field MAY be used to make a request
	method conditional by modification date: if the selected		method conditional by modification date: if the selected
	representation has not been modified since the time specified in this		representation has not been modified since the time specified in this
	field, then do not perform the request method; instead, respond as		field, then do not perform the request method; instead, respond as
	detailed below.		detailed below.
	skipping to change at page 18, line 35		skipping to change at page 18, line 35
	encodings of time between the client and server, are concerns.		encodings of time between the client and server, are concerns.
	This includes the possibility of race conditions if the document		This includes the possibility of race conditions if the document
	has changed between the time it was first requested and the If-		has changed between the time it was first requested and the If-
	Modified-Since date of a subsequent request, and the possibility		Modified-Since date of a subsequent request, and the possibility
	of clock-skew-related problems if the If-Modified-Since date is		of clock-skew-related problems if the If-Modified-Since date is
	derived from the client's clock without correction to the server's		derived from the client's clock without correction to the server's
	clock. Corrections for different time bases between client and		clock. Corrections for different time bases between client and
	server are at best approximate due to network latency.		server are at best approximate due to network latency.
	The result of a request having both an If-Modified-Since header field		The result of a request having both an If-Modified-Since header field
	and either an If-Match or an If-Unmodified-Since header fields is		and either an If-Match or an If-Unmodified-Since header field is
	undefined by this specification.		undefined by this specification.
	3.4. If-Unmodified-Since		3.4. If-Unmodified-Since
	The "If-Unmodified-Since" header field MAY be used to make a request		The "If-Unmodified-Since" header field MAY 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
	skipping to change at page 19, line 15		skipping to change at page 19, line 15
	If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT		If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
	If the request normally (i.e., without the If-Unmodified-Since header		If the request normally (i.e., without the If-Unmodified-Since header
	field) would result in anything other than a 2xx or 412 status code,		field) would result in anything other than a 2xx or 412 status code,
	the If-Unmodified-Since header field SHOULD be ignored.		the If-Unmodified-Since header field SHOULD be ignored.
	If the specified date is invalid, the header field MUST be ignored.		If the specified date is invalid, the header field MUST be ignored.
	The result of a request having both an If-Unmodified-Since header		The result of a request having both an If-Unmodified-Since header
	field and either an If-None-Match or an If-Modified-Since header		field and either an If-None-Match or an If-Modified-Since header
	fields is undefined by this specification.		field is undefined by this specification.
	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 HTTP range requests. If-Range is defined in Section 5.3
	of [Part5].		of [Part5].
	4. Status Code Definitions		4. Status Code Definitions
	skipping to change at page 21, line 35		skipping to change at page 21, line 35
	See Section 11 of [Part1].		See Section 11 of [Part1].
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-18		and Message Parsing",
	(work in progress), January 2012.		draft-ietf-httpbis-p1-messaging-latest (work in progress),
			February 2012.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 2: Message		and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-18 (work in		Semantics", draft-ietf-httpbis-p2-semantics-latest (work
	progress), January 2012.		in progress), February 2012.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-18		and Content Negotiation",
	(work in progress), January 2012.		draft-ietf-httpbis-p3-payload-latest (work in progress),
			February 2012.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-18 (work		Partial Responses", draft-ietf-httpbis-p5-range-latest
	in progress), January 2012.		(work in progress), February 2012.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-18 (work in		6: Caching", draft-ietf-httpbis-p6-cache-latest (work in
	progress), January 2012.		progress), February 2012.
	[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.
	8.2. Informative References		8.2. Informative References
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	skipping to change at page 23, line 20		skipping to change at page 23, line 20
	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 1.2.2>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	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.3>		obs-text = <obs-text, defined in [Part1], Section 3.2.4>
	opaque-tag = DQUOTE *etagc DQUOTE		opaque-tag = DQUOTE *etagc DQUOTE
	weak = %x57.2F ; W/		weak = %x57.2F ; W/
	ABNF diagnostics:		ABNF diagnostics:
	; ETag defined but not used		; ETag defined but not used
	; If-Match defined but not used		; If-Match defined but not used
	; If-Modified-Since defined but not used		; If-Modified-Since defined but not used
	; If-None-Match defined but not used		; If-None-Match defined but not used
	skipping to change at page 27, line 12		skipping to change at page 27, line 12
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document		o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
	HTTP's error-handling philosophy"		HTTP's error-handling philosophy"
	C.19. Since draft-ietf-httpbis-p4-conditional-17		C.19. Since draft-ietf-httpbis-p4-conditional-17
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/306>: "does etag		o <http://tools.ietf.org/wg/httpbis/trac/ticket/306>: "does etag
	value really use quoted-string"		value really use quoted-string"
			C.20. Since draft-ietf-httpbis-p4-conditional-18
			None yet.
	Index		Index
	3		3
	304 Not Modified (status code) 19		304 Not Modified (status code) 19
	4		4
	412 Precondition Failed (status code) 20		412 Precondition Failed (status code) 20
	E		E
	ETag header field 10		ETag header field 10
End of changes. 20 change blocks.
	27 lines changed or deleted		34 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/