draft-ietf-httpbis-p4-conditional-04.txt		draft-ietf-httpbis-p4-conditional-05.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Expires: March 2, 2009 J. Mogul		Expires: May 20, 2009 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	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 29, 2008		November 16, 2008
	HTTP/1.1, part 4: Conditional Requests		HTTP/1.1, part 4: Conditional Requests
	draft-ietf-httpbis-p4-conditional-04		draft-ietf-httpbis-p4-conditional-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 2, 2009.		This Internet-Draft will expire on May 20, 2009.
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia 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. Part 4 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
	request header fields for indicating conditional requests and the		request header fields for indicating conditional requests and the
	rules for constructing responses to those requests.		rules for constructing responses to those requests.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	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). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://www.tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix B.4.		The changes in this draft are summarized in Appendix B.6.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Notational Conventions and Generic Grammar . . . . . . . . . . 4		2. Notational Conventions and Generic Grammar . . . . . . . . . . 4
	3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5		4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5
	4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5		4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5
	4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6		4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6
	skipping to change at page 3, line 25		skipping to change at page 3, line 25
	6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9		6. Rules for When to Use Entity Tags and Last-Modified Dates . . 9
	7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11		7. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11
	7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12		7.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13		7.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13
	7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14		7.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14
	7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16		7.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16
	7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16		7.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Message Header Registration . . . . . . . . . . . . . . . 17		8.1. Message Header Registration . . . . . . . . . . . . . . . 17
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 17		9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Appendix A. Compatibility with Previous Versions . . . . . . . . 18		Appendix A. Compatibility with Previous Versions . . . . . . . . 18
	A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 18		A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19
	Appendix B. Change Log (to be removed by RFC Editor before		Appendix B. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 19		publication) . . . . . . . . . . . . . . . . . . . . 19
	B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19		B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 19
	B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19		B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 19
	B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19		B.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 19
	B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19		B.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 19
	B.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 19		B.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 20
			B.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 20
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . . . 24
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 response metadata for indicating		This document defines HTTP/1.1 response metadata for indicating
	potential changes to payload content, including modification time		potential changes to payload content, including modification time
	stamps and opaque entity-tags, and the HTTP conditional request		stamps and opaque entity-tags, and the HTTP conditional request
	mechanisms that allow preconditions to be placed on a request method.		mechanisms that allow preconditions to be placed on a request method.
	skipping to change at page 4, line 47		skipping to change at page 4, line 47
	REQUIRED level and all the SHOULD level requirements for its		REQUIRED level and all the SHOULD level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the MUST level requirements but not all the SHOULD
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant."
	2. Notational Conventions and Generic Grammar		2. Notational Conventions and Generic Grammar
	This specification uses the ABNF syntax defined in Section 2.1 of		This specification uses the ABNF syntax defined in Section 2.1 of
	[Part1] and the core rules defined in Section 2.2 of [Part1]:		[Part1] and the core rules defined in Section 2.2 of [Part1]:
	[[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
	5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
	quoted-string = <quoted-string, defined in [Part1], Section 2.2>		quoted-string = <quoted-string, defined in [Part1], Section 2.2>
			OWS = <OWS, defined in [Part1], Section 2.2>
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
	3. Entity Tags		3. Entity Tags
	Entity tags are used for comparing two or more entities from the same		Entity tags are used for comparing two or more entities from the same
	requested resource. HTTP/1.1 uses entity tags in the ETag		requested resource. HTTP/1.1 uses entity tags in the ETag
	(Section 7.1), If-Match (Section 7.2), If-None-Match (Section 7.4),		(Section 7.1), If-Match (Section 7.2), If-None-Match (Section 7.4),
	and If-Range (Section 6.3 of [Part5]) header fields. The definition		and If-Range (Section 6.3 of [Part5]) header fields. The definition
	skipping to change at page 11, line 30		skipping to change at page 11, line 27
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to conditional requests.		fields related to conditional requests.
	For entity-header fields, both sender and recipient refer to either		For entity-header fields, both sender and recipient refer to either
	the client or the server, depending on who sends and who receives the		the client or the server, depending on who sends and who receives the
	entity.		entity.
	7.1. ETag		7.1. ETag
	The ETag response-header field provides the current value of the		The response-header field "ETag" provides the current value of the
	entity tag for the requested variant. The headers used with entity		entity tag (see Section 3) for the requested variant. The headers
	tags are described in Sections 7.2 and 7.4 of this document, and in		used with entity tags are described in Sections 7.2 and 7.4 of this
	Section 6.3 of [Part5]. The entity tag MAY be used for comparison		document, and in Section 6.3 of [Part5]. The entity tag MAY be used
	with other entities from the same resource (see Section 5).		for comparison with other entities from the same resource (see
			Section 5).
	ETag = "ETag" ":" entity-tag		ETag = "ETag" ":" OWS ETag-v
			ETag-v = entity-tag
	Examples:		Examples:
	ETag: "xyzzy"		ETag: "xyzzy"
	ETag: W/"xyzzy"		ETag: W/"xyzzy"
	ETag: ""		ETag: ""
	The ETag response-header field value, an entity tag, provides for an		The ETag response-header field value, an entity tag, provides for an
	"opaque" cache validator. This might allow more reliable validation		"opaque" cache validator. This might allow more reliable validation
	in situations where it is inconvenient to store modification dates,		in situations where it is inconvenient to store modification dates,
	skipping to change at page 12, line 13		skipping to change at page 12, line 12
	The principle behind entity tags is that only the service author		The principle behind entity tags is that only the service author
	knows the semantics of a resource well enough to select an		knows the semantics of a resource well enough to select an
	appropriate cache validation mechanism, and the specification of any		appropriate cache validation mechanism, and the specification of any
	validator comparison function more complex than byte-equality would		validator comparison function more complex than byte-equality would
	open up a can of worms. Thus, comparisons of any other headers		open up a can of worms. Thus, comparisons of any other headers
	(except Last-Modified, for compatibility with HTTP/1.0) are never		(except Last-Modified, for compatibility with HTTP/1.0) are never
	used for purposes of validating a cache entry.		used for purposes of validating a cache entry.
	7.2. If-Match		7.2. If-Match
	The If-Match request-header field is used with a method to make it		The request-header field "If-Match" is used with a method to make it
	conditional. A client that has one or more entities previously		conditional. A client that has one or more entities previously
	obtained from the resource can verify that one of those entities is		obtained from the resource can verify that one of those entities is
	current by including a list of their associated entity tags in the		current by including a list of their associated entity tags in the
	If-Match header field. Entity tags are defined in Section 3. The		If-Match header field. Entity tags are defined in Section 3. The
	purpose of this feature is to allow efficient updates of cached		purpose of this feature is to allow efficient updates of cached
	information with a minimum amount of transaction overhead. It is		information with a minimum amount of transaction overhead. It is
	also used, on updating requests, to prevent inadvertent modification		also used, on updating requests, to prevent inadvertent modification
	of the wrong version of a resource. As a special case, the value "*"		of the wrong version of a resource. As a special case, the value "*"
	matches any current entity of the resource.		matches any current entity of the resource.
	If-Match = "If-Match" ":" ( "*" | 1#entity-tag )		If-Match = "If-Match" ":" OWS If-Match-v
			If-Match-v = "*" / 1#entity-tag
	If any of the entity tags match the entity tag of the entity that		If any of the entity tags match the entity tag of the entity that
	would have been returned in the response to a similar GET request		would have been returned in the response to a similar GET request
	(without the If-Match header) on that resource, or if "*" is given		(without the If-Match header) on that resource, or if "*" is given
	and any current entity exists for that resource, then the server MAY		and any current entity exists for that resource, then the server MAY
	perform the requested method as if the If-Match header field did not		perform the requested method as if the If-Match header field did not
	exist.		exist.
	A server MUST use the strong comparison function (see Section 5) to		A server MUST use the strong comparison function (see Section 5) to
	compare the entity tags in If-Match.		compare the entity tags in If-Match.
	skipping to change at page 13, line 23		skipping to change at page 13, line 23
	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 fields is
	undefined by this specification.		undefined by this specification.
	7.3. If-Modified-Since		7.3. If-Modified-Since
	The If-Modified-Since request-header field is used with a method to		The request-header field "If-Modified-Since" is used with a method to
	make it conditional: if the requested variant has not been modified		make it conditional: if the requested variant has not been modified
	since the time specified in this field, an entity will not be		since the time specified in this field, an entity will not be
	returned from the server; instead, a 304 (Not Modified) response will		returned from the server; instead, a 304 (Not Modified) response will
	be returned without any message-body.		be returned without any message-body.
	If-Modified-Since = "If-Modified-Since" ":" HTTP-date		If-Modified-Since = "If-Modified-Since" ":" OWS
			If-Modified-Since-v
			If-Modified-Since-v = HTTP-date
	An example of the field is:		An example of the field is:
	If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT		If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
	A GET method with an If-Modified-Since header and no Range header		A GET method with an If-Modified-Since header and no Range header
	requests that the identified entity be transferred only if it has		requests that the identified entity be transferred only if it has
	been modified since the date given by the If-Modified-Since header.		been modified since the date given by the If-Modified-Since header.
	The algorithm for determining this includes the following cases:		The algorithm for determining this includes the following cases:
	skipping to change at page 14, line 41		skipping to change at page 14, line 43
	to the server's clock. Corrections for different time bases		to the server's clock. Corrections for different time bases
	between client and server are at best approximate due to network		between client and server are at best approximate due to network
	latency.		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 fields is
	undefined by this specification.		undefined by this specification.
	7.4. If-None-Match		7.4. If-None-Match
	The If-None-Match request-header field is used with a method to make		The request-header field "If-None-Match" is used with a method to
	it conditional. A client that has one or more entities previously		make it conditional. A client that has one or more entities
	obtained from the resource can verify that none of those entities is		previously obtained from the resource can verify that none of those
	current by including a list of their associated entity tags in the		entities is current by including a list of their associated entity
	If-None-Match header field. The purpose of this feature is to allow		tags in the If-None-Match header field. The purpose of this feature
	efficient updates of cached information with a minimum amount of		is to allow efficient updates of cached information with a minimum
	transaction overhead. It is also used to prevent a method (e.g.		amount of transaction overhead. It is also used to prevent a method
	PUT) from inadvertently modifying an existing resource when the		(e.g. PUT) from inadvertently modifying an existing resource when
	client believes that the resource does not exist.		the client believes that the resource does not exist.
	As a special case, the value "*" matches any current entity of the		As a special case, the value "*" matches any current entity of the
	resource.		resource.
	If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )		If-None-Match = "If-None-Match" ":" OWS If-None-Match-v
			If-None-Match-v = "*" / 1#entity-tag
	If any of the entity tags match the entity tag of the entity that		If any of the entity tags match the entity tag of the entity that
	would have been returned in the response to a similar GET request		would have been returned in the response to a similar GET request
	(without the If-None-Match header) on that resource, or if "*" is		(without the If-None-Match header) on that resource, or if "*" is
	given and any current entity exists for that resource, then the		given and any current entity exists for that resource, then the
	server MUST NOT perform the requested method, unless required to do		server MUST NOT perform the requested method, unless required to do
	so because the resource's modification date fails to match that		so because the resource's modification date fails to match that
	supplied in an If-Modified-Since header field in the request.		supplied in an If-Modified-Since header field in the request.
	Instead, if the request method was GET or HEAD, the server SHOULD		Instead, if the request method was GET or HEAD, the server SHOULD
	respond with a 304 (Not Modified) response, including the cache-		respond with a 304 (Not Modified) response, including the cache-
	skipping to change at page 15, line 49		skipping to change at page 16, line 4
	not exist. This feature is intended to be useful in preventing races		not exist. This feature is intended to be useful in preventing races
	between PUT operations.		between PUT operations.
	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 fields is
	undefined by this specification.		undefined by this specification.
	7.5. If-Unmodified-Since		7.5. If-Unmodified-Since
	The If-Unmodified-Since request-header field is used with a method to		The request-header field "If-Unmodified-Since" is used with a method
	make it conditional. If the requested resource has not been modified		to make it conditional. If the requested resource has not been
	since the time specified in this field, the server SHOULD perform the		modified since the time specified in this field, the server SHOULD
	requested operation as if the If-Unmodified-Since header were not		perform the requested operation as if the If-Unmodified-Since header
	present.		were not present.
	If the requested variant has been modified since the specified time,		If the requested variant has been modified since the specified time,
	the server MUST NOT perform the requested operation, and MUST return		the server MUST NOT perform the requested operation, and MUST return
	a 412 (Precondition Failed).		a 412 (Precondition Failed).
	If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date		If-Unmodified-Since = "If-Unmodified-Since" ":" OWS
			If-Unmodified-Since-v
			If-Unmodified-Since-v = HTTP-date
	An example of the field is:		An example of the field is:
	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		If the request normally (i.e., without the If-Unmodified-Since
	header) would result in anything other than a 2xx or 412 status, the		header) would result in anything other than a 2xx or 412 status, the
	If-Unmodified-Since header SHOULD be ignored.		If-Unmodified-Since header SHOULD be ignored.
	If the specified date is invalid, the header is ignored.		If the specified date is invalid, the header is 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.		fields is undefined by this specification.
	7.6. Last-Modified		7.6. Last-Modified
	The Last-Modified entity-header field indicates the date and time at		The entity-header field "Last-Modified" indicates the date and time
	which the origin server believes the variant was last modified.		at which the origin server believes the variant was last modified.
	Last-Modified = "Last-Modified" ":" HTTP-date		Last-Modified = "Last-Modified" ":" OWS Last-Modified-v
			Last-Modified-v = HTTP-date
	An example of its use is		An example of its use is
	Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT		Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
	The exact meaning of this header field depends on the implementation		The exact meaning of this header field depends on the implementation
	of the origin server and the nature of the original resource. For		of the origin server and the nature of the original resource. For
	files, it may be just the file system last-modified time. For		files, it may be just the file system last-modified time. For
	entities with dynamically included parts, it may be the most recent		entities with dynamically included parts, it may be the most recent
	of the set of last-modify times for its component parts. For		of the set of last-modify times for its component parts. For
	skipping to change at page 18, line 14		skipping to change at page 18, line 19
	10. Acknowledgments		10. Acknowledgments
	11. References		11. References
	11.1. Normative References		11.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-04		and Message Parsing", draft-ietf-httpbis-p1-messaging-05
	(work in progress), August 2008.		(work in progress), November 2008.
	[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-04 (work		Partial Responses", draft-ietf-httpbis-p5-range-05 (work
	in progress), August 2008.		in progress), November 2008.
	[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.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-04 (work in progress),		draft-ietf-httpbis-p6-cache-05 (work in progress),
	August 2008.		November 2008.
	[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.
	11.2. Informative References		11.2. Informative References
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	skipping to change at page 19, line 15		skipping to change at page 19, line 20
	Appendix B. Change Log (to be removed by RFC Editor before publication)		Appendix B. Change Log (to be removed by RFC Editor before publication)
	B.1. Since RFC2616		B.1. Since RFC2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	B.2. Since draft-ietf-httpbis-p4-conditional-00		B.2. Since draft-ietf-httpbis-p4-conditional-00
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative		o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
	and Informative references"		Informative references"
	Other changes:		Other changes:
	o Move definitions of 304 and 412 condition codes from Part2.		o Move definitions of 304 and 412 condition codes from Part2.
	B.3. Since draft-ietf-httpbis-p4-conditional-01		B.3. Since draft-ietf-httpbis-p4-conditional-01
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Add explicit references to BNF syntax and rules imported from		o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.		other parts of the specification.
	B.4. Since draft-ietf-httpbis-p4-conditional-02		B.4. Since draft-ietf-httpbis-p4-conditional-02
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak		o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
	ETags on non-GET requests"		non-GET requests"
	Ongoing work on IANA Message Header Registration		Ongoing work on IANA Message Header Registration
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	o Reference RFC 3984, and update header registrations for headers		o Reference RFC 3984, and update header registrations for headers
	defined in this document.		defined in this document.
	B.5. Since draft-ietf-httpbis-p4-conditional-03		B.5. Since draft-ietf-httpbis-p4-conditional-03
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples		o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for
	for ETag matching"		ETag matching"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity		o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity
	value' undefined"		value' undefined"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus
	2068 Date header reference"		o <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068
			Date header reference"
			B.6. Since draft-ietf-httpbis-p4-conditional-04
			Ongoing work on ABNF conversion
			(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
			o Use "/" instead of "|" for alternatives.
			o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
			whitespace ("OWS") and required whitespace ("RWS").
			o Rewrite ABNFs to spell out whitespace rules, factor out header
			value format definitions.
	Index		Index
	3		3
	304 Not Modified (status code) 5		304 Not Modified (status code) 5
	4		4
	412 Precondition Failed (status code) 6		412 Precondition Failed (status code) 6
	E		E
	ETag header 11		ETag header 11
	G		G
	Grammar		Grammar
	entity-tag 5		entity-tag 5
	ETag 11		ETag 11
			ETag-v 11
	If-Match 12		If-Match 12
			If-Match-v 12
	If-Modified-Since 13		If-Modified-Since 13
			If-Modified-Since-v 13
	If-None-Match 15		If-None-Match 15
			If-None-Match-v 15
	If-Unmodified-Since 16		If-Unmodified-Since 16
			If-Unmodified-Since-v 16
	Last-Modified 16		Last-Modified 16
			Last-Modified-v 16
	opaque-tag 5		opaque-tag 5
	weak 5		weak 5
	H		H
	Headers		Headers
	ETag 11		ETag 11
	If-Match 12		If-Match 12
	If-Modified-Since 13		If-Modified-Since 13
	If-None-Match 14		If-None-Match 14
	If-Unmodified-Since 16		If-Unmodified-Since 16
End of changes. 41 change blocks.
	59 lines changed or deleted		88 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/