draft-ietf-httpbis-p4-conditional-16.txt		draft-ietf-httpbis-p4-conditional-17.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: February 25, 2012 J. Mogul		Expires: May 3, 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
	August 24, 2011		October 31, 2011
	HTTP/1.1, part 4: Conditional Requests		HTTP/1.1, part 4: Conditional Requests
	draft-ietf-httpbis-p4-conditional-16		draft-ietf-httpbis-p4-conditional-17
	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.17.		The changes in this draft are summarized in Appendix C.18.
	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 February 25, 2012.		This Internet-Draft will expire on May 3, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 2, line 52		skipping to change at page 2, line 52
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
	2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6		2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6
	2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 8		2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 8
	2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8		2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8
	2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 9		2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 9
	2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 11		2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 11
	2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11		2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11
	2.3.3. Example: Entity-tags varying on Content-Negotiated		2.3.3. Example: Entity-tags varying on Content-Negotiated
	Resources . . . . . . . . . . . . . . . . . . . . . . 12		Resources . . . . . . . . . . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13		Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14		3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14
	3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14		3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 15
	3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15		3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15
	3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 17		3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 17
	3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18		3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18
	3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 19		3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 19
	4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19		4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19
	4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 19		4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 19
	4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 20		4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 20
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	5.1. Status Code Registration . . . . . . . . . . . . . . . . . 20		5.1. Status Code Registration . . . . . . . . . . . . . . . . . 20
	5.2. Header Field Registration . . . . . . . . . . . . . . . . 20		5.2. Header Field Registration . . . . . . . . . . . . . . . . 20
	skipping to change at page 3, line 42		skipping to change at page 3, line 42
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . . 21		8.2. Informative References . . . . . . . . . . . . . . . . . . 21
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 23		publication) . . . . . . . . . . . . . . . . . . . . 23
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23
	C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23		C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23
	C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23		C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23
	C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23		C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23
	C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23		C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 24
	C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24		C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24
	C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24		C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24
	C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24		C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24
	C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24		C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24
	C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24		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 . . . . . . . . 25		C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25
	C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25		C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25
	C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25		C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25
	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
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	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 5, line 36		skipping to change at page 5, line 36
	harm will result when the precondition evaluates to false.		harm will result when the precondition evaluates to false.
	We use the term "selected representation" to refer to the current		We use the term "selected representation" to refer to the current
	representation of the target resource that would have been selected		representation of the target resource that would have been selected
	in a successful response if the same request had used the method GET		in a successful response if the same request had used the method GET
	and had excluded all of the conditional request header fields. The		and had excluded all of the conditional request header fields. The
	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. Requirements		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].
	An implementation is not compliant if it fails to satisfy one or more		This document defines conformance criteria for several roles in HTTP
	of the "MUST" or "REQUIRED" level requirements for the protocols it		communication, including Senders, Recipients, Clients, Servers, User-
	implements. An implementation that satisfies all the "MUST" or		Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
	"REQUIRED" level and all the "SHOULD" level requirements for its		Section 2 of [Part1] for definitions of these terms.
	protocols is said to be "unconditionally compliant"; one that
	satisfies all the "MUST" level requirements but not all the "SHOULD"		An implementation is considered conformant if it complies with all of
	level requirements for its protocols is said to be "conditionally		the requirements associated with its role(s). Note that SHOULD-level
	compliant".		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 are invalid.
			Unless noted otherwise, Recipients MAY take steps to recover a usable
			protocol element from an invalid construct. However, HTTP does not
			define specific error handling mechanisms, except in cases where it
			has direct impact on security. This is because different uses of the
			protocol require different error handling strategies; for example, a
			Web browser may wish to transparently recover from a response where
			the Location header field doesn't parse according to the ABNF,
			whereby in a systems control protocol using HTTP, this type of error
			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 ABNF syntax defined in Section 1.2 of
	[Part1] (which extends the syntax defined in [RFC5234] with a list		[Part1] (which extends the syntax defined in [RFC5234] with a list
	rule). Appendix B shows the collected ABNF, with the list rule		rule). Appendix B shows the collected ABNF, with the list rule
	expanded.		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), VCHAR (any visible USASCII character),		sequence of data), SP (space), and VCHAR (any visible US-ASCII
	and WSP (whitespace).		character).
	The ABNF rules below are defined in [Part1]:		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 1.2.2>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		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
	"validator" when it is used within a precondition.		"validator" when it is used within a precondition.
	skipping to change at page 9, line 15		skipping to change at page 9, line 29
	response is generated.		response is generated.
	An origin server with a clock MUST NOT send a Last-Modified date that		An origin server with a clock MUST NOT send a Last-Modified date that
	is later than the server's time of message origination (Date). If		is later than the server's time of message origination (Date). If
	the last modification time is derived from implementation-specific		the last modification time is derived from implementation-specific
	metadata that evaluates to some time in the future, according to the		metadata that evaluates to some time in the future, according to the
	origin server's clock, then the origin server MUST replace that value		origin server's clock, then the origin server MUST replace that value
	with the message origination date. This prevents a future		with the message origination date. This prevents a future
	modification date from having an adverse impact on cache validation.		modification date from having an adverse impact on cache validation.
			An origin server without a clock MUST NOT assign Last-Modified values
			to a response unless these values were associated with the resource
			by some other system or user with a reliable clock.
	2.2.2. Comparison		2.2.2. Comparison
	A Last-Modified time, when used as a validator in a request, is		A Last-Modified time, when used as a validator in a request, is
	implicitly weak unless it is possible to deduce that it is strong,		implicitly weak unless it is possible to deduce that it is strong,
	using the following rules:		using the following rules:
	o The validator is being compared by an origin server to the actual		o The validator is being compared by an origin server to the actual
	current validator for the representation and,		current validator for the representation and,
	o That origin server reliably knows that the associated		o That origin server reliably knows that the associated
	skipping to change at page 13, line 21		skipping to change at page 13, line 24
	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, so
	therefore an entity-tag of an encoded representation must be		therefore an entity-tag of an encoded representation must be
	distinct from an unencoded representation to prevent conflicts		distinct from an unencoded representation to prevent conflicts
	during cache updates and range requests. In contrast, transfer		during cache updates and range requests. In contrast, transfer
	codings (Section 6.2 of [Part1]) apply only during message		codings (Section 5.1 of [Part1]) apply only during message
	transfer and do not require distinct entity-tags.		transfer and do not require distinct entity-tags.
	2.4. Rules for When to Use Entity-tags and Last-Modified Dates		2.4. Rules for When to Use Entity-tags and Last-Modified Dates
	We adopt a set of rules and recommendations for origin servers,		We adopt a set of rules and recommendations for origin servers,
	clients, and caches regarding when various validator types ought to		clients, and caches regarding when various validator types ought to
	be used, and for what purposes.		be used, and for what purposes.
	HTTP/1.1 origin servers:		HTTP/1.1 origin servers:
	skipping to change at page 19, line 27		skipping to change at page 19, line 27
	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.3 of		A 304 response MUST include a Date header field (Section 9.2 of
	[Part1]) unless its omission is required by Section 9.3.1 of [Part1].		[Part2]) unless the origin server does not have a clock that can
	If a 200 response to the same request would have included any of the		provide a reasonable approximation of the current time. If a 200
	header fields Cache-Control, Content-Location, ETag, Expires, Last-		response to the same request would have included any of the header
	Modified, or Vary, then those same header fields MUST be sent in a		fields Cache-Control, Content-Location, ETag, Expires, Last-Modified,
	304 response.		or Vary, then those same header fields MUST be sent in a 304
			response.
	Since the goal of a 304 response is to minimize information transfer		Since the goal of a 304 response is to minimize information transfer
	when the recipient already has one or more cached representations,		when the recipient already has one or more cached representations,
	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
	of guiding cache updates (e.g., future HTTP extensions).		of guiding cache updates (e.g., future HTTP extensions).
	If the recipient of a 304 response does not have a cached		If the recipient of a 304 response does not have a cached
	representation corresponding to the entity-tag indicated by the 304		representation corresponding to the entity-tag indicated by the 304
	response, then the recipient MUST NOT use the 304 to update its own		response, then the recipient MUST NOT use the 304 to update its own
	skipping to change at page 21, line 7		skipping to change at page 21, line 7
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	6. Security Considerations		6. Security Considerations
	No additional security considerations have been identified beyond		No additional security considerations have been identified beyond
	those applicable to HTTP in general [Part1].		those applicable to HTTP in general [Part1].
	7. Acknowledgments		7. Acknowledgments
	See Section 12 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-16		and Message Parsing", draft-ietf-httpbis-p1-messaging-17
	(work in progress), August 2011.		(work in progress), October 2011.
			[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
			Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
			and J. Reschke, Ed., "HTTP/1.1, part 2: Message
			Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
			progress), October 2011.
	[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-16		and Content Negotiation", draft-ietf-httpbis-p3-payload-17
	(work in progress), August 2011.		(work in progress), October 2011.
	[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-16 (work		Partial Responses", draft-ietf-httpbis-p5-range-17 (work
	in progress), August 2011.		in progress), October 2011.
	[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-16 (work in		6: Caching", draft-ietf-httpbis-p6-cache-17 (work in
	progress), August 2011.		progress), October 2011.
	[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 22, line 20		skipping to change at page 22, line 25
	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 ABNF productions for header fields to only define the field		Change ABNF productions for header fields to only define the field
	value. (Section 3)		value. (Section 3)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	ETag = entity-tag		ETag = entity-tag
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8>
	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 26, line 17		skipping to change at page 26, line 20
	None.		None.
	C.17. Since draft-ietf-httpbis-p4-conditional-15		C.17. Since draft-ietf-httpbis-p4-conditional-15
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/304>: "If-Range		o <http://tools.ietf.org/wg/httpbis/trac/ticket/304>: "If-Range
	should be listed when dicussing contexts where L-M can be		should be listed when dicussing contexts where L-M can be
	considered strong"		considered strong"
			C.18. Since draft-ietf-httpbis-p4-conditional-16
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
			HTTP's error-handling philosophy"
	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
	skipping to change at page 26, line 43		skipping to change at page 27, line 4
	If-Modified-Since 17		If-Modified-Since 17
	If-None-Match 16		If-None-Match 16
	If-Unmodified-Since 18		If-Unmodified-Since 18
	Last-Modified 8		Last-Modified 8
	opaque-tag 10		opaque-tag 10
	weak 10		weak 10
	H		H
	Header Fields		Header Fields
	ETag 10		ETag 10
	If-Match 14		If-Match 15
	If-Modified-Since 17		If-Modified-Since 17
	If-None-Match 15		If-None-Match 15
	If-Unmodified-Since 18		If-Unmodified-Since 18
	Last-Modified 8		Last-Modified 8
	I		I
	If-Match header field 14		If-Match header field 15
	If-Modified-Since header field 17		If-Modified-Since header field 17
	If-None-Match header field 15		If-None-Match header field 15
	If-Unmodified-Since header field 18		If-Unmodified-Since header field 18
	L		L
	Last-Modified header field 8		Last-Modified header field 8
	M		M
	metadata 6		metadata 6
End of changes. 27 change blocks.
	41 lines changed or deleted		75 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/