draft-ietf-httpbis-p4-conditional-20.txt		draft-ietf-httpbis-p4-conditional-21.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) Y. Lafon, Ed.		Obsoletes: 2616 (if approved) J. Reschke, Ed.
	Intended status: Standards Track W3C		Intended status: Standards Track greenbytes
	Expires: January 17, 2013 J. Reschke, Ed.		Expires: April 7, 2013 October 4, 2012
	greenbytes
	July 16, 2012
	HTTP/1.1, part 4: Conditional Requests		Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
	draft-ietf-httpbis-p4-conditional-20		draft-ietf-httpbis-p4-conditional-21
	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 35		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.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 April 7, 2013.
	This Internet-Draft will expire on January 17, 2013.
	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 3, line 11		skipping to change at page 3, line 11
	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 . . . . . . . . . . . . . . . . . . . . . 5
	2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6		2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5
	2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7		2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . . . . . . . 11		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. Rules for When to Use Entity-tags and Last-Modified
	Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12		Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14		3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
	3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14		3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15		3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14
	3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16		3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16
	3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17		3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17
	3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18		3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 17
	4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18		4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18
	4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18		4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18
	4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19		4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 18
	5. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19		5. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	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 . . . . . . . . . . . . . . . . 21		6.2. Header Field Registration . . . . . . . . . . . . . . . . 20
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 21		7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 22		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 . . . . . . . . . . . . . . . . . . . . 23		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) . . . . . . . . . . . . . . . . . . . . 24		publication) . . . . . . . . . . . . . . . . . . . . 23
	D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 24		D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 23
			D.2. Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 24
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	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. Each
	precondition is based on metadata that is expected to change if the		precondition is based on metadata that is expected to change if the
	selected representation of the target resource is changed. This		selected representation of the target resource is changed. This
	document defines the HTTP/1.1 conditional request mechanisms in terms		document defines the HTTP/1.1 conditional request mechanisms in terms
	skipping to change at page 4, line 47		skipping to change at page 4, line 47
	conditional request preconditions are evaluated by comparing the		conditional request preconditions are evaluated by comparing the
	values provided in the request header fields to the current metadata		values provided in the request header fields to the current metadata
	for the selected representation.		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].
	This specification targets conformance criteria according to the role		Conformance criteria and considerations regarding error handling are
	of a participant in HTTP communication. Hence, HTTP requirements are		defined in Section 2.5 of [Part1].
	placed on senders, recipients, clients, servers, user agents,
	intermediaries, origin servers, proxies, gateways, or caches,
	depending on what behavior is being constrained by the requirement.
	See Section 2 of [Part1] for definitions of these terms.
	The verb "generate" is used instead of "send" where a requirement
	differentiates between creating a protocol element and merely
	forwarding a received element downstream.
	An implementation is considered conformant if it complies with all of
	the requirements associated with the roles it partakes in HTTP. Note
	that SHOULD-level requirements are relevant here, unless one of the
	documented exceptions is applicable.
	This document also uses ABNF to define valid protocol elements
	(Section 1.2). In addition to the prose requirements placed upon
	them, senders MUST NOT generate protocol elements that do not match
	the grammar defined by the ABNF rules for those protocol elements
	that are applicable to the sender's role. If a received protocol
	element is processed, the recipient MUST be able to parse any value
	that would match the ABNF rules for that protocol element, excluding
	only those rules not applicable to the recipient's role.
	Unless noted otherwise, a recipient MAY attempt to recover a usable
	protocol element from an invalid construct. HTTP does not define
	specific error handling mechanisms except when they have a direct
	impact on security, since different applications of the protocol
	require different error handling strategies. For example, a Web
	browser might wish to transparently recover from a response where the
	Location header field doesn't parse according to the ABNF, whereas a
	systems control client might consider any form of error recovery to
	be dangerous.
	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 the list rule extension defined in Section
	1.2 of [Part1]. Appendix B describes rules imported from other		1.2 of [Part1]. Appendix B describes rules imported from other
	documents. Appendix C shows the collected ABNF with the list rule		documents. Appendix C shows the collected ABNF with the list rule
	expanded.		expanded.
	2. Validators		2. Validators
	skipping to change at page 11, line 41		skipping to change at page 11, line 16
	| 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 8		Consider a resource that is subject to content negotiation (Section
	of [Part2]), and where the representations returned upon a GET		3.4 of [Part2]), and where the representations returned upon a GET
	request vary based on the Accept-Encoding request header field		request vary based on the Accept-Encoding request header field
	(Section 9.3 of [Part2]):		(Section 6.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 18, line 38		skipping to change at page 18, line 20
	received and would have resulted in a 200 (OK) response if it were		received and would have resulted in a 200 (OK) response if it were
	not for the fact that the condition has evaluated to false. In other		not for the fact that the condition has evaluated to false. In other
	words, there is no need for the server to transfer a representation		words, there is no need for the server to transfer a representation
	of the target resource because the client's request indicates that it		of the target resource because the client's request indicates that it
	already has a valid representation, as indicated by the 304 response		already has a valid representation, as indicated by the 304 response
	header fields, and is therefore redirecting the client to make use of		header fields, and is therefore redirecting the client to make use of
	that stored representation as if it were the payload of a 200		that stored representation as if it were the payload of a 200
	response. The 304 response MUST NOT contain a message-body, and thus		response. The 304 response MUST NOT contain a message-body, and thus
	is always terminated by the first empty line after the header fields.		is always terminated by the first empty line after the header fields.
	A 304 response MUST include a Date header field (Section 9.10 of		A 304 response MUST include a Date header field (Section 8.1.1.2 of
	[Part2]) unless the origin server does not have a clock that can		[Part2]) unless the origin server does not have a clock that can
	provide a reasonable approximation of the current time. If a 200		provide a reasonable approximation of the current time. If a 200
	(OK) response to the same request would have included any of the		(OK) response to the same request would have included any of the
	header fields Cache-Control, Content-Location, ETag, Expires, or		header fields Cache-Control, Content-Location, ETag, Expires, or
	Vary, then those same header fields MUST be sent in a 304 response.		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,
	the response SHOULD NOT include representation metadata other than		the response SHOULD NOT include representation metadata other than
	the above listed fields unless said metadata exists for the purpose		the above listed fields unless said metadata exists for the purpose
	skipping to change at page 22, line 4		skipping to change at page 21, line 25
	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.
	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., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	"HTTP/1.1, part 1: Message Routing and Syntax"",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-20 (work in progress),		draft-ietf-httpbis-p1-messaging-21 (work in progress),
	July 2012.		October 2012.
	[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	"HTTP/1.1, part 2: Semantics and Payloads",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-20 (work in progress),		draft-ietf-httpbis-p2-semantics-21 (work in progress),
	July 2012.		October 2012.
	[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"HTTP/1.1, part 5: Range Requests",		"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
	draft-ietf-httpbis-p5-range-20 (work in progress),		draft-ietf-httpbis-p5-range-21 (work in progress),
	July 2012.		October 2012.
	[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-20 (work in progress),		draft-ietf-httpbis-p6-cache-21 (work in progress),
	July 2012.		October 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.
	9.2. Informative References		9.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 22, line 50		skipping to change at page 22, line 24
	September 2004.		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		Allow weak entity-tags in all requests except range requests
	(Sections 2.1 and 3.2).		(Sections 2.1 and 3.2).
	Change ETag header field ABNF not to use quoted-string, thus avoiding		Change "ETag" header field ABNF not to use quoted-string, thus
	escaping issues. (Section 2.3)		avoiding escaping issues. (Section 2.3)
	Change ABNF productions for header fields to only define the field
	value. (Section 3)
	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.1>
	obs-text = <obs-text, defined in [Part1], Section 3.2.4>		obs-text = <obs-text, defined in [Part1], Section 3.2.4>
	The rules below are defined in other parts:		The rules below are defined in other parts:
	HTTP-date = <HTTP-date, defined in [Part2], Section 5.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8.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 5.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8.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
	skipping to change at page 24, line 18		skipping to change at page 23, line 44
	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>.
	D.1. Since draft-ietf-httpbis-p4-conditional-19		D.1. Since draft-ietf-httpbis-p4-conditional-19
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to		o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to
	clarify eval order/interaction of conditional headers"		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		o <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and
	Conditional Requests"		Conditional Requests"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF		o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
	requirements for recipients"		requirements for recipients"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases"		o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional		o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional
	Request Security Considerations"		Request Security Considerations"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified-		o <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified-
	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
			o Conformance criteria and considerations regarding error handling
			are now defined in Part 1.
	Index		Index
	3		3
	304 Not Modified (status code) 18		304 Not Modified (status code) 18
	4		4
	412 Precondition Failed (status code) 19		412 Precondition Failed (status code) 18
	E		E
	ETag header field 9		ETag header field 9
	G		G
	Grammar		Grammar
	entity-tag 10		entity-tag 9
	ETag 10
	etagc 10
	If-Match 14
	If-Modified-Since 16
	If-None-Match 15
	If-Unmodified-Since 17
	Last-Modified 7
	opaque-tag 10
	weak 10
	H
	Header Fields
	ETag 9		ETag 9
			etagc 9
	If-Match 14		If-Match 14
	If-Modified-Since 16		If-Modified-Since 16
	If-None-Match 15		If-None-Match 15
	If-Unmodified-Since 17		If-Unmodified-Since 17
	Last-Modified 7		Last-Modified 7
			opaque-tag 9
			weak 9
	I		I
	If-Match header field 14		If-Match header field 13
	If-Modified-Since header field 16		If-Modified-Since header field 16
	If-None-Match header field 15		If-None-Match header field 14
	If-Unmodified-Since header field 17		If-Unmodified-Since header field 17
	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
	Status Codes
	304 Not Modified 18
	412 Precondition Failed 19
	V		V
	validator 5		validator 5
	strong 6		strong 5
	weak 6		weak 5
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Yves Lafon (editor)
	World Wide Web Consortium
	W3C / ERCIM
	2004, rte des Lucioles
	Sophia-Antipolis, AM 06902
	France
	EMail: ylafon@w3.org
	URI: http://www.raubacapeu.net/people/yves/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
	EMail: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
End of changes. 37 change blocks.
	114 lines changed or deleted		68 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/