draft-ietf-httpbis-p4-conditional-00.txt		draft-ietf-httpbis-p4-conditional-01.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2068, 2616 J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	(if approved) One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Intended status: Standards Track J. Mogul		Expires: July 15, 2008 J. Mogul
	Expires: June 22, 2008 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
	December 20, 2007		Y. Lafon, Ed.
			W3C
			J. Reschke, Ed.
			greenbytes
			January 12, 2008
	HTTP/1.1, part 4: Conditional Requests		HTTP/1.1, part 4: Conditional Requests
	draft-ietf-httpbis-p4-conditional-00		draft-ietf-httpbis-p4-conditional-01
	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 45		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 June 22, 2008.		This Internet-Draft will expire on July 15, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	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)
	This version of the HTTP specification contains only minimal
	editorial changes from [RFC2616] (abstract, introductory paragraph,
	and authors' addresses). All other changes are due to partitioning
	the original into seven mostly independent parts. The intent is for
	readers of future drafts to able to use draft 00 as the basis for
	comparison when the WG makes later changes to the specification text.
	This draft will shortly be followed by draft 01 (containing the first
	round of changes that have already been agreed to on the mailing
	list). There is no point in reviewing this draft other than to
	verify that the partitioning has been done correctly. Roy T.
	Fielding, Yves Lafon, and Julian Reschke will be the editors after
	draft 00 is submitted.
	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://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://www.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://www3.tools.ietf.org/wg/httpbis/>.		<http://www.tools.ietf.org/wg/httpbis/>.
			This draft incorporates those issue resolutions that were either
			collected in the original RFC2616 errata list
			(<http://purl.org/NET/http-errata>), or which were agreed upon on the
			mailing list between October 2006 and November 2007 (as published in
			"draft-lafon-rfc2616bis-03").
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
			1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 4		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5
	3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 4		3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 5
	3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 5		3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6
	4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 5		4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 6
	5. Rules for When to Use Entity Tags and Last-Modified Dates . . 8		5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9
	6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10		6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 10
	6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 11		6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 12
	6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 13		6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14
	6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 14		6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 15
	6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 15		6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 20		Appendix A. Compatibility with Previous Versions . . . . . . . . 17
			A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 17
			Appendix B. Change Log (to be removed by RFC Editor before
			publication) . . . . . . . . . . . . . . . . . . . . 17
			B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 17
			B.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 18
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
			Intellectual Property and Copyright Statements . . . . . . . . . . 22
	1. Introduction		1. Introduction
	This document will define aspects of HTTP related to conditional		This document defines HTTP/1.1 response metadata for indicating
	request messages based on time stamps and entity-tags. Right now it		potential changes to payload content, including modification time
	only includes the extracted relevant sections of RFC 2616 [RFC2616]		stamps and opaque entity-tags, and the HTTP conditional request
	without edit.		mechanisms that allow preconditions to be placed on a request method.
			Conditional GET requests allow for efficient cache updates. Other
			conditional request methods are used to protect against overwriting
			or misunderstanding the state of a resource that has been changed
			unbeknownst to the requesting client.
			This document is currently disorganized in order to minimize the
			changes between drafts and enable reviewers to see the smaller errata
			changes. The next draft will reorganize the sections to better
			reflect the content. In particular, the sections on resource
			metadata will be discussed first and then followed by each
			conditional request-header, concluding with a definition of
			precedence and the expectation of ordering strong validator checks
			before weak validator checks. It is likely that more content from
			[Part6] will migrate to this part, where appropriate. The current
			mess reflects how widely dispersed these topics and associated
			requirements had become in [RFC2616].
			1.1. Requirements
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			An implementation is not compliant if it fails to satisfy one or more
			of the MUST or REQUIRED level requirements for the protocols it
			implements. An implementation that satisfies all the MUST or
			REQUIRED level and all the SHOULD level requirements for its
			protocols is said to be "unconditionally compliant"; one that
			satisfies all the MUST level requirements but not all the SHOULD
			level requirements for its protocols is said to be "conditionally
			compliant."
	2. Entity Tags		2. 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 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4),		(Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4),
	and If-Range (Section 5.3 of [Part5]) header fields. The definition		and If-Range (Section 5.3 of [Part5]) header fields. The definition
	of how they are used and compared as cache validators is in		of how they are used and compared as cache validators is in
	Section 4. An entity tag consists of an opaque quoted string,		Section 4. An entity tag consists of an opaque quoted string,
	possibly prefixed by a weakness indicator.		possibly prefixed by a weakness indicator.
	skipping to change at page 5, line 11		skipping to change at page 5, line 40
	respond with this status code. The 304 response MUST NOT contain a		respond with this status code. The 304 response MUST NOT contain a
	message-body, and thus is always terminated by the first empty line		message-body, and thus is always terminated by the first empty line
	after the header fields.		after the header fields.
	The response MUST include the following header fields:		The response MUST include the following header fields:
	o Date, unless its omission is required by Section 8.3.1 of [Part1]		o Date, unless its omission is required by Section 8.3.1 of [Part1]
	If a clockless origin server obeys these rules, and proxies and		If a clockless origin server obeys these rules, and proxies and
	clients add their own Date to any response received without one (as		clients add their own Date to any response received without one (as
	already specified by [RFC2068], section 14.19), caches will operate		already specified by [RFC2068], Section 14.19), caches will operate
	correctly.		correctly.
	o ETag and/or Content-Location, if the header would have been sent		o ETag and/or Content-Location, if the header would have been sent
	in a 200 response to the same request		in a 200 response to the same request
	o Expires, Cache-Control, and/or Vary, if the field-value might		o Expires, Cache-Control, and/or Vary, if the field-value might
	differ from that sent in any previous response for the same		differ from that sent in any previous response for the same
	variant		variant
	If the conditional GET used a strong cache validator (see [Part6]),		If the conditional GET used a strong cache validator (see Section 4),
	the response SHOULD NOT include other entity-headers. Otherwise		the response SHOULD NOT include other entity-headers. Otherwise
	(i.e., the conditional GET used a weak validator), the response MUST		(i.e., the conditional GET used a weak validator), the response MUST
	NOT include other entity-headers; this prevents inconsistencies		NOT include other entity-headers; this prevents inconsistencies
	between cached entity-bodies and updated headers.		between cached entity-bodies and updated headers.
	If a 304 response indicates an entity not currently cached, then the		If a 304 response indicates an entity not currently cached, then the
	cache MUST disregard the response and repeat the request without the		cache MUST disregard the response and repeat the request without the
	conditional.		conditional.
	If a cache uses a received 304 response to update a cache entry, the		If a cache uses a received 304 response to update a cache entry, the
	skipping to change at page 10, line 15		skipping to change at page 10, line 46
	HTTP/1.0 clients and caches will ignore entity tags. Generally,		HTTP/1.0 clients and caches will ignore entity tags. Generally,
	last-modified values received or used by these systems will		last-modified values received or used by these systems will
	support transparent and efficient caching, and so HTTP/1.1 origin		support transparent and efficient caching, and so HTTP/1.1 origin
	servers should provide Last-Modified values. In those rare cases		servers should provide Last-Modified values. In those rare cases
	where the use of a Last-Modified value as a validator by an		where the use of a Last-Modified value as a validator by an
	HTTP/1.0 system could result in a serious problem, then HTTP/1.1		HTTP/1.0 system could result in a serious problem, then HTTP/1.1
	origin servers should not provide one.		origin servers should not provide one.
	6. Header Field Definitions		6. Header Field Definitions
	This section defines the syntax and semantics of all standard		This section defines the syntax and semantics of HTTP/1.1 header
	HTTP/1.1 header fields. For entity-header fields, both sender and		fields related to conditional requests.
	recipient refer to either the client or the server, depending on who
	sends and who receives the entity.		For entity-header fields, both sender and recipient refer to either
			the client or the server, depending on who sends and who receives the
			entity.
	6.1. ETag		6.1. ETag
	The ETag response-header field provides the current value of the		The ETag response-header field provides the current value of the
	entity tag for the requested variant. The headers used with entity		entity tag for the requested variant. The headers used with entity
	tags are described in sections 6.2, 6.4 and Section 5.3 of [Part5].		tags are described in Sections 6.2 and 6.4 of this document, and in
	The entity tag MAY be used for comparison with other entities from		Section 5.3 of [Part5]. The entity tag MAY be used for comparison
	the same resource (see Section 4).		with other entities from the same resource (see Section 4).
	ETag = "ETag" ":" entity-tag		ETag = "ETag" ":" entity-tag
	Examples:		Examples:
	ETag: "xyzzy"		ETag: "xyzzy"
	ETag: W/"xyzzy"		ETag: W/"xyzzy"
	ETag: ""		ETag: ""
	6.2. If-Match		6.2. If-Match
	skipping to change at page 11, line 26		skipping to change at page 12, line 12
	most useful when the client wants to prevent an updating method, such		most useful when the client wants to prevent an updating method, such
	as PUT, from modifying a resource that has changed since the client		as PUT, from modifying a resource that has changed since the client
	last retrieved it.		last retrieved it.
	If the request would, without the If-Match header field, result in		If the request would, without the If-Match header field, result in
	anything other than a 2xx or 412 status, then the If-Match header		anything other than a 2xx or 412 status, then the If-Match header
	MUST be ignored.		MUST be ignored.
	The meaning of "If-Match: *" is that the method SHOULD be performed		The meaning of "If-Match: *" is that the method SHOULD be performed
	if the representation selected by the origin server (or by a cache,		if the representation selected by the origin server (or by a cache,
	possibly using the Vary mechanism, see Section 3.5 of [Part6])		possibly using the Vary mechanism, see Section 15.5 of [Part6])
	exists, and MUST NOT be performed if the representation does not		exists, and MUST NOT be performed if the representation does not
	exist.		exist.
	A request intended to update a resource (e.g., a PUT) MAY include an		A request intended to update a resource (e.g., a PUT) MAY include an
	If-Match header field to signal that the request method MUST NOT be		If-Match header field to signal that the request method MUST NOT be
	applied if the entity corresponding to the If-Match value (a single		applied if the entity corresponding to the If-Match value (a single
	entity tag) is no longer a representation of that resource. This		entity tag) is no longer a representation of that resource. This
	allows the user to indicate that they do not wish the request to be		allows the user to indicate that they do not wish the request to be
	successful if the resource has been changed without their knowledge.		successful if the resource has been changed without their knowledge.
	Examples:		Examples:
	skipping to change at page 11, line 51		skipping to change at page 12, line 37
	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.
	6.3. If-Modified-Since		6.3. If-Modified-Since
	The If-Modified-Since request-header field is used with a method to		The If-Modified-Since request-header field 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" ":" 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
	skipping to change at page 14, line 17		skipping to change at page 15, line 4
	return a 304 (Not Modified) response.		return a 304 (Not Modified) response.
	If the request would, without the If-None-Match header field, result		If the request would, without the If-None-Match header field, result
	in anything other than a 2xx or 304 status, then the If-None-Match		in anything other than a 2xx or 304 status, then the If-None-Match
	header MUST be ignored. (See Section 5 for a discussion of server		header MUST be ignored. (See Section 5 for a discussion of server
	behavior when both If-Modified-Since and If-None-Match appear in the		behavior when both If-Modified-Since and If-None-Match appear in the
	same request.)		same request.)
	The meaning of "If-None-Match: *" is that the method MUST NOT be		The meaning of "If-None-Match: *" is that the method MUST NOT be
	performed if the representation selected by the origin server (or by		performed if the representation selected by the origin server (or by
	a cache, possibly using the Vary mechanism, see Section 3.5 of		a cache, possibly using the Vary mechanism, see Section 15.5 of
	[Part6]) exists, and SHOULD be performed if the representation does		[Part6]) exists, and SHOULD be performed if the representation does
	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"
	skipping to change at page 16, line 12		skipping to change at page 17, line 5
	TBD.		TBD.
	8. Security Considerations		8. 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].
	9. Acknowledgments		9. Acknowledgments
	Based on an XML translation of RFC 2616 by Julian Reschke.
	10. References		10. References
			10.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., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 1: URIs, Connections, and Message Parsing",		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	draft-ietf-httpbis-p1-messaging-00 (work in progress),		and Message Parsing", draft-ietf-httpbis-p1-messaging-01
	December 2007.		(work in progress), January 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., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 5: Range Requests and Partial Responses",		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	draft-ietf-httpbis-p5-range-00 (work in progress),		Partial Responses", draft-ietf-httpbis-p5-range-01 (work
	December 2007.		in progress), January 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., and T. Berners-Lee, "HTTP/1.1,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	progress), December 2007.		draft-ietf-httpbis-p6-cache-01 (work in progress),
			January 2008.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, March 1997.
			10.2. Informative References
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",		Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	RFC 2068, January 1997.		RFC 2068, January 1997.
	[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.
			Appendix A. Compatibility with Previous Versions
			A.1. Changes from RFC 2616
			Appendix B. Change Log (to be removed by RFC Editor before publication)
			B.1. Since RFC2616
			Extracted relevant partitions from [RFC2616].
			B.2. Since draft-ietf-httpbis-p4-conditional-00
			Closed issues:
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
			and Informative references"
			Other changes:
			o Move definitions of 304 and 412 condition codes from Part2.
	Index		Index
	3		3
	304 Not Modified (status code) 4		304 Not Modified (status code) 5
	4		4
	412 Precondition Failed (status code) 5		412 Precondition Failed (status code) 6
	E		E
	ETag header 10		ETag header 11
	G		G
	Grammar		Grammar
	entity-tag 4		entity-tag 5
	ETag 10		ETag 11
	If-Match 10		If-Match 11
	If-Modified-Since 12		If-Modified-Since 12
	If-None-Match 13		If-None-Match 14
	If-Unmodified-Since 14		If-Unmodified-Since 15
	Last-Modified 15		Last-Modified 16
	opaque-tag 4		opaque-tag 5
	weak 4		weak 5
	H		H
	Headers		Headers
	ETag 10		ETag 11
	If-Match 10		If-Match 11
	If-Modified-Since 11		If-Modified-Since 12
	If-None-Match 13		If-None-Match 14
	If-Unmodified-Since 14		If-Unmodified-Since 15
	Last-Modified 15		Last-Modified 16
	I		I
	If-Match header 10		If-Match header 11
	If-Modified-Since header 11		If-Modified-Since header 12
	If-None-Match header 13		If-None-Match header 14
	If-Unmodified-Since header 14		If-Unmodified-Since header 15
	L		L
	Last-Modified header 15		Last-Modified header 16
	S		S
	Status Codes		Status Codes
	304 Not Modified 4		304 Not Modified 5
	412 Precondition Failed 5		412 Precondition Failed 6
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
	skipping to change at page 20, line 4		skipping to change at page 21, line 4
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory		MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32		The Stata Center, Building 32
	32 Vassar Street		32 Vassar Street
	Cambridge, MA 02139		Cambridge, MA 02139
	USA		USA
	Email: timbl@w3.org		Email: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/		URI: http://www.w3.org/People/Berners-Lee/
			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)
			greenbytes GmbH
			Hafenweg 16
			Muenster, NW 48155
			Germany
			Phone: +49 251 2807760
			Fax: +49 251 2807761
			Email: julian.reschke@greenbytes.de
			URI: http://greenbytes.de/tech/webdav/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 37 change blocks.
	93 lines changed or deleted		179 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/