draft-ietf-httpbis-p2-semantics-08.txt		draft-ietf-httpbis-p2-semantics-09.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis 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
	Updates: 2817 (if approved) One Laptop per Child		Updates: 2817 (if approved) One Laptop per Child
	Intended status: Standards Track J. Mogul		Intended status: Standards Track J. Mogul
	Expires: April 29, 2010 HP		Expires: September 9, 2010 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
	October 26, 2009		March 8, 2010
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-08		draft-ietf-httpbis-p2-semantics-09
	Status of this Memo		Abstract
			The Hypertext Transfer Protocol (HTTP) is an application-level
			protocol for distributed, collaborative, hypermedia information
			systems. HTTP has been in use by the World Wide Web global
			information initiative since 1990. This document is Part 2 of the
			seven-part specification that defines the protocol referred to as
			"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
			the semantics of HTTP messages as expressed by request methods,
			request-header fields, response status codes, and response-header
			fields.
			Editorial Note (To be removed by RFC Editor)
			Discussion of this draft should take place on the HTTPBIS working
			group mailing list (ietf-http-wg@w3.org). The current issues list is
			at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
			documents (including fancy diffs) can be found at
			<http://tools.ietf.org/wg/httpbis/>.
			The changes in this draft are summarized in Appendix C.10.
			Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79.
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	skipping to change at page 2, line 4		skipping to change at page 2, line 16
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	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 April 29, 2010.		This Internet-Draft will expire on September 9, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	The Hypertext Transfer Protocol (HTTP) is an application-level		described in the BSD License.
	protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 2 of the
	seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
	the semantics of HTTP messages as expressed by request methods,
	request-header fields, response status codes, and response-header
	fields.
	Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.9.		This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7		1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
	1.2.2. ABNF Rules defined in other Parts of the		1.2.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 7		Specification . . . . . . . . . . . . . . . . . . . . 7
	2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	publication) . . . . . . . . . . . . . . . . . . . . 48		publication) . . . . . . . . . . . . . . . . . . . . 48
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 48
	C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48		C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 48
	C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49		C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 49
	C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49		C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 49
	C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50		C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 50
	C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50		C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 50
	C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51		C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 51
	C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51		C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 51
	C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51		C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 51
			C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 52
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 request and response semantics. Each		This document defines HTTP/1.1 request and response semantics. Each
	HTTP message, as defined in [Part1], is in the form of either a		HTTP message, as defined in [Part1], is in the form of either a
	request or a response. An HTTP server listens on a connection for		request or a response. An HTTP server listens on a connection for
	HTTP requests and responds to each request, in the order received on		HTTP requests and responds to each request, in the order received on
	that connection, with one or more HTTP response messages. This		that connection, with one or more HTTP response messages. This
	skipping to change at page 10, line 16		skipping to change at page 10, line 16
	The Status-Code element is a 3-digit integer result code of the		The Status-Code element is a 3-digit integer result code of the
	attempt to understand and satisfy the request. The status codes		attempt to understand and satisfy the request. The status codes
	listed below are defined in Section 8. The Reason-Phrase is intended		listed below are defined in Section 8. The Reason-Phrase is intended
	to give a short textual description of the Status-Code. The Status-		to give a short textual description of the Status-Code. The Status-
	Code is intended for use by automata and the Reason-Phrase is		Code is intended for use by automata and the Reason-Phrase is
	intended for the human user. The client is not required to examine		intended for the human user. The client is not required to examine
	or display the Reason-Phrase.		or display the Reason-Phrase.
	The individual values of the numeric status codes defined for		The individual values of the numeric status codes defined for
	HTTP/1.1, and an example set of corresponding Reason-Phrase's, are		HTTP/1.1, and an example set of corresponding Reason-Phrase values,
	presented below. The reason phrases listed here are only		are presented below. The reason phrases listed here are only
	recommendations -- they MAY be replaced by local equivalents without		recommendations -- they MAY be replaced by local equivalents without
	affecting the protocol.		affecting the protocol.
	Status-Code =		Status-Code =
	"100" ; Section 8.1.1: Continue		"100" ; Section 8.1.1: Continue
	/ "101" ; Section 8.1.2: Switching Protocols		/ "101" ; Section 8.1.2: Switching Protocols
	/ "200" ; Section 8.2.1: OK		/ "200" ; Section 8.2.1: OK
	/ "201" ; Section 8.2.2: Created		/ "201" ; Section 8.2.2: Created
	/ "202" ; Section 8.2.3: Accepted		/ "202" ; Section 8.2.3: Accepted
	/ "203" ; Section 8.2.4: Non-Authoritative Information		/ "203" ; Section 8.2.4: Non-Authoritative Information
	skipping to change at page 13, line 31		skipping to change at page 13, line 31
	It is sometimes necessary to determine the identity of the resource		It is sometimes necessary to determine the identity of the resource
	associated with a representation.		associated with a representation.
	An HTTP request representation, when present, is always associated		An HTTP request representation, when present, is always associated
	with an anonymous (i.e., unidentified) resource.		with an anonymous (i.e., unidentified) resource.
	In the common case, an HTTP response is a representation of the		In the common case, an HTTP response is a representation of the
	resource located at the request-URI. However, this is not always the		resource located at the request-URI. However, this is not always the
	case. To determine the URI of the resource a response is associated		case. To determine the URI of the resource a response is associated
	with, the following rules are used (first match winning):		with, the following rules are used (with the first applicable one
			being selected):
	1. If the response status code is 200 or 203 and the request method		1. If the response status code is 200 or 203 and the request method
	was GET, the response is a representation of the resource at the		was GET, the response is a representation of the resource at the
	request-URI.		request-URI.
	2. If the response status is 204, 206, or 304 and the request method		2. If the response status is 204, 206, or 304 and the request method
	was GET or HEAD, the response is a partial representation of the		was GET or HEAD, the response is a partial representation of the
	resource at the request-URI (see Section 2.7 of [Part6]).		resource at the request-URI (see Section 2.7 of [Part6]).
	3. If the response has a Content-Location header, and that URI is		3. If the response has a Content-Location header, and that URI is
	the same as the request-URI [[anchor1: (see [ref])]], the		the same as the request-URI [[TODO-missref-requri: (see [ref])]],
	response is a representation of the resource at the request-URI.		the response is a representation of the resource at the request-
			URI.
	4. If the response has a Content-Location header, and that URI is		4. If the response has a Content-Location header, and that URI is
	not the same as the request-URI, the response asserts that it is		not the same as the request-URI, the response asserts that it is
	a representation of the resource at the Content-Location URI (but		a representation of the resource at the Content-Location URI (but
	it may not be).		it may not be).
	5. Otherwise, the response is a representation of an anonymous		5. Otherwise, the response is a representation of an anonymous
	(i.e., unidentified) resource.		(i.e., unidentified) resource.
	[[TODO-req-uri: Note that 'request-URI' is used here; however, we		[[TODO-req-uri: Note that "request-URI" is used here; however, we
	need to come up with a term to denote "the URI that can be inferred		need to come up with a term to denote "the URI that can be inferred
	from examining the request-target and the Host header." (see		from examining the request-target and the Host header." (see
	<http://tools.ietf.org/wg/httpbis/trac/ticket/196>). Also, the		<http://tools.ietf.org/wg/httpbis/trac/ticket/196>). Also, the
	comparison function is going to have to be defined somewhere, because		comparison function is going to have to be defined somewhere, because
	we already need to compare URIs for things like cache invalidation.]]		we already need to compare URIs for things like cache invalidation.]]
	7. Method Definitions		7. Method Definitions
	The set of common methods for HTTP/1.1 is defined below. Although		The set of common methods for HTTP/1.1 is defined below. Although
	this set can be expanded, additional methods cannot be assumed to		this set can be expanded, additional methods cannot be assumed to
	skipping to change at page 16, line 14		skipping to change at page 16, line 14
	the message; instead, the proxy SHOULD respond with its own		the message; instead, the proxy SHOULD respond with its own
	communication options. If the Max-Forwards field-value is an integer		communication options. If the Max-Forwards field-value is an integer
	greater than zero, the proxy MUST decrement the field-value when it		greater than zero, the proxy MUST decrement the field-value when it
	forwards the request. If no Max-Forwards field is present in the		forwards the request. If no Max-Forwards field is present in the
	request, then the forwarded request MUST NOT include a Max-Forwards		request, then the forwarded request MUST NOT include a Max-Forwards
	field.		field.
	7.3. GET		7.3. GET
	The GET method means retrieve whatever information (in the form of an		The GET method means retrieve whatever information (in the form of an
	entity) is identified by the request-target. If the request-target		entity) currently corresponds to the resource identified by the
	refers to a data-producing process, it is the produced data which		request-target.
	shall be returned as the entity in the response and not the source
	text of the process, unless that text happens to be the output of the		If the request-target identifies a data-producing process, it is the
	process.		produced data which shall be returned as the entity in the response
			and not the source text of the process, unless that text happens to
			be the output of the process.
	The semantics of the GET method change to a "conditional GET" if the		The semantics of the GET method change to a "conditional GET" if the
	request message includes an If-Modified-Since, If-Unmodified-Since,		request message includes an If-Modified-Since, If-Unmodified-Since,
	If-Match, If-None-Match, or If-Range header field. A conditional GET		If-Match, If-None-Match, or If-Range header field. A conditional GET
	method requests that the entity be transferred only under the		method requests that the entity be transferred only under the
	circumstances described by the conditional header field(s). The		circumstances described by the conditional header field(s). The
	conditional GET method is intended to reduce unnecessary network		conditional GET method is intended to reduce unnecessary network
	usage by allowing cached entities to be refreshed without requiring		usage by allowing cached entities to be refreshed without requiring
	multiple requests or transferring data already held by the client.		multiple requests or transferring data already held by the client.
	skipping to change at page 18, line 22		skipping to change at page 18, line 22
	is capable of being defined as a new resource by the requesting user		is capable of being defined as a new resource by the requesting user
	agent, the origin server can create the resource with that URI. If a		agent, the origin server can create the resource with that URI. If a
	new resource is created at the request-target, the origin server MUST		new resource is created at the request-target, the origin server MUST
	inform the user agent via the 201 (Created) response. If an existing		inform the user agent via the 201 (Created) response. If an existing
	resource is modified, either the 200 (OK) or 204 (No Content)		resource is modified, either the 200 (OK) or 204 (No Content)
	response codes SHOULD be sent to indicate successful completion of		response codes SHOULD be sent to indicate successful completion of
	the request. If the resource could not be created or modified with		the request. If the resource could not be created or modified with
	the request-target, an appropriate error response SHOULD be given		the request-target, an appropriate error response SHOULD be given
	that reflects the nature of the problem. The recipient of the entity		that reflects the nature of the problem. The recipient of the entity
	MUST NOT ignore any Content-* headers (headers starting with the		MUST NOT ignore any Content-* headers (headers starting with the
	prefix 'Content-') that it does not understand or implement and MUST		prefix "Content-") that it does not understand or implement and MUST
	return a 501 (Not Implemented) response in such cases.		return a 501 (Not Implemented) response in such cases.
	If the request passes through a cache and the request-target		If the request passes through a cache and the request-target
	identifies one or more currently cached entities, those entries		identifies one or more currently cached entities, those entries
	SHOULD be treated as stale. Responses to this method are not		SHOULD be treated as stale. Responses to this method are not
	cacheable.		cacheable.
	The fundamental difference between the POST and PUT requests is		The fundamental difference between the POST and PUT requests is
	reflected in the different meaning of the request-target. The URI in		reflected in the different meaning of the request-target. The URI in
	a POST request identifies the resource that will handle the enclosed		a POST request identifies the resource that will handle the enclosed
	skipping to change at page 20, line 8		skipping to change at page 20, line 8
	testing a chain of proxies forwarding messages in an infinite loop.		testing a chain of proxies forwarding messages in an infinite loop.
	If the request is valid, the response SHOULD contain the entire		If the request is valid, the response SHOULD contain the entire
	request message in the entity-body, with a Content-Type of "message/		request message in the entity-body, with a Content-Type of "message/
	http" (see Section 10.3.1 of [Part1]). Responses to this method MUST		http" (see Section 10.3.1 of [Part1]). Responses to this method MUST
	NOT be cached.		NOT be cached.
	7.9. CONNECT		7.9. CONNECT
	This specification reserves the method name CONNECT for use with a		This specification reserves the method name CONNECT for use with a
	proxy that can dynamically switch to being a tunnel (e.g. SSL		proxy that can dynamically switch to being a tunnel (e.g., SSL
	tunneling [RFC2817]).		tunneling [RFC2817]).
	8. Status Code Definitions		8. Status Code Definitions
	Each Status-Code is described below, including any metainformation		Each Status-Code is described below, including any metainformation
	required in the response.		required in the response.
	8.1. Informational 1xx		8.1. Informational 1xx
	This class of status code indicates a provisional response,		This class of status code indicates a provisional response,
	skipping to change at page 21, line 39		skipping to change at page 21, line 39
	HEAD the entity-header fields corresponding to the requested		HEAD the entity-header fields corresponding to the requested
	resource are sent in the response without any message-body;		resource are sent in the response without any message-body;
	POST an entity describing or containing the result of the action;		POST an entity describing or containing the result of the action;
	TRACE an entity containing the request message as received by the		TRACE an entity containing the request message as received by the
	end server.		end server.
	8.2.2. 201 Created		8.2.2. 201 Created
	The request has been fulfilled and resulted in a new resource being		The request has been fulfilled and has resulted in a new resource
	created. The newly created resource can be referenced by the URI(s)		being created. The newly created resource can be referenced by the
	returned in the entity of the response, with the most specific URI		URI(s) returned in the entity of the response, with the most specific
	for the resource given by a Location header field. The response		URI for the resource given by a Location header field. The response
	SHOULD include an entity containing a list of resource		SHOULD include an entity containing a list of resource
	characteristics and location(s) from which the user or user agent can		characteristics and location(s) from which the user or user agent can
	choose the one most appropriate. The entity format is specified by		choose the one most appropriate. The entity format is specified by
	the media type given in the Content-Type header field. The origin		the media type given in the Content-Type header field. The origin
	server MUST create the resource before returning the 201 status code.		server MUST create the resource before returning the 201 status code.
	If the action cannot be carried out immediately, the server SHOULD		If the action cannot be carried out immediately, the server SHOULD
	respond with 202 (Accepted) response instead.		respond with 202 (Accepted) response instead.
	A 201 response MAY contain an ETag response header field indicating		A 201 response MAY contain an ETag response header field indicating
	the current value of the entity tag for the requested variant just		the current value of the entity tag for the requested variant just
	skipping to change at page 23, line 26		skipping to change at page 23, line 26
	The server has fulfilled the partial GET request for the resource and		The server has fulfilled the partial GET request for the resource and
	the enclosed entity is a partial representation as defined in Section		the enclosed entity is a partial representation as defined in Section
	3.1 of [Part5].		3.1 of [Part5].
	8.3. Redirection 3xx		8.3. Redirection 3xx
	This class of status code indicates that further action needs to be		This class of status code indicates that further action needs to be
	taken by the user agent in order to fulfill the request. The action		taken by the user agent in order to fulfill the request. The action
	required MAY be carried out by the user agent without interaction		required MAY be carried out by the user agent without interaction
	with the user if and only if the method used in the second request is		with the user if and only if the method used in the second request is
	GET or HEAD. A client SHOULD detect infinite redirection loops,		known to be "safe", as defined in Section 7.1.1. A client SHOULD
	since such loops generate network traffic for each redirection.		detect infinite redirection loops, since such loops generate network
			traffic for each redirection.
	Note: an earlier version of this specification recommended a		Note: An earlier version of this specification recommended a
	maximum of five redirections ([RFC2068], Section 10.3). Content		maximum of five redirections ([RFC2068], Section 10.3). Content
	developers should be aware that there might be clients that		developers should be aware that there might be clients that
	implement such a fixed limitation.		implement such a fixed limitation.
	8.3.1. 300 Multiple Choices		8.3.1. 300 Multiple Choices
	The requested resource corresponds to any one of a set of		The requested resource corresponds to any one of a set of
	representations, each with its own specific location, and agent-		representations, each with its own specific location, and agent-
	driven negotiation information (Section 4 of [Part3]) is being		driven negotiation information (Section 4 of [Part3]) is being
	provided so that the user (or user agent) can select a preferred		provided so that the user (or user agent) can select a preferred
	skipping to change at page 31, line 39		skipping to change at page 31, line 39
	Retry-After header. If no Retry-After is given, the client SHOULD		Retry-After header. If no Retry-After is given, the client SHOULD
	handle the response as it would for a 500 response.		handle the response as it would for a 500 response.
	Note: The existence of the 503 status code does not imply that a		Note: The existence of the 503 status code does not imply that a
	server must use it when becoming overloaded. Some servers may		server must use it when becoming overloaded. Some servers may
	wish to simply refuse the connection.		wish to simply refuse the connection.
	8.5.5. 504 Gateway Timeout		8.5.5. 504 Gateway Timeout
	The server, while acting as a gateway or proxy, did not receive a		The server, while acting as a gateway or proxy, did not receive a
	timely response from the upstream server specified by the URI (e.g.		timely response from the upstream server specified by the URI (e.g.,
	HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed		HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
	to access in attempting to complete the request.		to access in attempting to complete the request.
	Note: Note to implementors: some deployed proxies are known to		Note to implementors: some deployed proxies are known to return
	return 400 or 500 when DNS lookups time out.		400 or 500 when DNS lookups time out.
	8.5.6. 505 HTTP Version Not Supported		8.5.6. 505 HTTP Version Not Supported
	The server does not support, or refuses to support, the protocol		The server does not support, or refuses to support, the protocol
	version that was used in the request message. The server is		version that was used in the request message. The server is
	indicating that it is unable or unwilling to complete the request		indicating that it is unable or unwilling to complete the request
	using the same major version as the client, as described in Section		using the same major version as the client, as described in Section
	2.5 of [Part1], other than with this error message. The response		2.5 of [Part1], other than with this error message. The response
	SHOULD contain an entity describing why that version is not supported		SHOULD contain an entity describing why that version is not supported
	and what other protocols are supported by that server.		and what other protocols are supported by that server.
	skipping to change at page 42, line 22		skipping to change at page 42, line 22
	12. Acknowledgments		12. Acknowledgments
	13. References		13. References
	13.1. Normative References		13.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-08		and Message Parsing", draft-ietf-httpbis-p1-messaging-09
	(work in progress), October 2009.		(work in progress), March 2010.
	[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-08		and Content Negotiation", draft-ietf-httpbis-p3-payload-09
	(work in progress), October 2009.		(work in progress), March 2010.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] 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 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-08 (work in		Requests", draft-ietf-httpbis-p4-conditional-09 (work in
	progress), October 2009.		progress), March 2010.
	[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-08 (work		Partial Responses", draft-ietf-httpbis-p5-range-09 (work
	in progress), October 2009.		in progress), March 2010.
	[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-08 (work in		6: Caching", draft-ietf-httpbis-p6-cache-09 (work in
	progress), October 2009.		progress), March 2010.
	[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part7] 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 7: Authentication",		and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
	draft-ietf-httpbis-p7-auth-08 (work in progress),		draft-ietf-httpbis-p7-auth-09 (work in progress),
	October 2009.		March 2010.
	[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.
	13.2. Informative References		13.2. Informative References
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
	skipping to change at page 43, line 46		skipping to change at page 43, line 46
	May 2008.		May 2008.
	[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
	October 2008.		October 2008.
	Appendix A. Compatibility with Previous Versions		Appendix A. Compatibility with Previous Versions
	A.1. Changes from RFC 2068		A.1. Changes from RFC 2068
	Clarified which error code should be used for inbound server failures		Clarified which error code should be used for inbound server failures
	(e.g. DNS failures). (Section 8.5.5).		(e.g., DNS failures). (Section 8.5.5).
	201 (Created) had a race that required an Etag be sent when a		201 (Created) had a race that required an Etag be sent when a
	resource is first created. (Section 8.2.2).		resource is first created. (Section 8.2.2).
	303 (See Also) and 307 (Temporary Redirect) added to address user		303 (See Also) and 307 (Temporary Redirect) added to address user
	agent failure to implement status code 302 properly. (Section 8.3.4		agent failure to implement status code 302 properly. (Section 8.3.4
	and 8.3.8)		and 8.3.8)
	Rewrite of message transmission requirements to make it much harder		Rewrite of message transmission requirements to make it much harder
	for implementors to get it wrong, as the consequences of errors here		for implementors to get it wrong, as the consequences of errors here
	skipping to change at page 52, line 19		skipping to change at page 52, line 19
	Location vs status 303"		Location vs status 303"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
	registrations for optional status codes"		registrations for optional status codes"
	Partly resolved issues:		Partly resolved issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS		o <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS
	and TRACE safe?"		and TRACE safe?"
			C.10. Since draft-ietf-httpbis-p2-semantics-08
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
			vs Redirection" (we missed the introduction to the 3xx status
			codes when fixing this previously)
	Index		Index
	1		1
	100 Continue (status code) 20		100 Continue (status code) 20
	101 Switching Protocols (status code) 20		101 Switching Protocols (status code) 20
	2		2
	200 OK (status code) 21		200 OK (status code) 21
	201 Created (status code) 21		201 Created (status code) 21
	202 Accepted (status code) 22		202 Accepted (status code) 22
End of changes. 32 change blocks.
	79 lines changed or deleted		99 lines changed or added
This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/