draft-ietf-httpbis-p2-semantics-04.txt		draft-ietf-httpbis-p2-semantics-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
	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: March 2, 2009 HP		Expires: May 20, 2009 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 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-04		draft-ietf-httpbis-p2-semantics-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 2 of the		information initiative since 1990. This document is Part 2 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 2 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
	the semantics of HTTP messages as expressed by request methods,		the semantics of HTTP messages as expressed by request methods,
	request-header fields, response status codes, and response-header		request-header fields, response status codes, and response-header
	fields.		fields.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Notational Conventions and Generic Grammar . . . . . . . . . . 6		2. Notational Conventions and Generic Grammar . . . . . . . . . . 6
	3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8		3.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
	4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9		4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 9
	5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9		5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 10
	5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12		5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 12
	6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12		6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 12
	7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13		8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13		8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 13
	8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13		8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 13
	8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14		8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 14
	8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14		8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	skipping to change at page 5, line 11		skipping to change at page 5, line 11
	Appendix A. Compatibility with Previous Versions . . . . . . . . 42		Appendix A. Compatibility with Previous Versions . . . . . . . . 42
	A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42		A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43
	Appendix B. Change Log (to be removed by RFC Editor before		Appendix B. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 44		publication) . . . . . . . . . . . . . . . . . . . . 44
	B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 44		B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 44
	B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 44		B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 44
	B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 45		B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 45
	B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 45		B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 45
	B.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 46		B.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 46
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46		B.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
	Intellectual Property and Copyright Statements . . . . . . . . . . 54		Intellectual Property and Copyright Statements . . . . . . . . . . 54
	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
	document defines the commonly agreed upon semantics of the HTTP		document defines the commonly agreed upon semantics of the HTTP
	skipping to change at page 6, line 46		skipping to change at page 6, line 46
	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>.]]
	DIGIT = <DIGIT, defined in [Part1], Section 2.2>		DIGIT = <DIGIT, defined in [Part1], Section 2.2>
	comment = <comment, defined in [Part1], Section 2.2>		comment = <comment, defined in [Part1], Section 2.2>
	quoted-string = <quoted-string, defined in [Part1], Section 2.2>		quoted-string = <quoted-string, defined in [Part1], Section 2.2>
	token = <token, defined in [Part1], Section 2.2>		token = <token, defined in [Part1], Section 2.2>
			OWS = <OWS, defined in [Part1], Section 2.2>
			RWS = <RWS, defined in [Part1], Section 2.2>
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	absoluteURI = <absoluteURI, defined in [Part1], Section 3.2.1>		absolute-URI = <absolute-URI, defined in [Part1], Section 3.2>
	fragment = <fragment, defined in [Part1], Section 3.2.1>		fragment = <fragment, defined in [Part1], Section 3.2>
	Host = <Host, defined in [Part1], Section 8.4>		Host = <Host, defined in [Part1], Section 3.2>
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
	product = <product, defined in [Part1], Section 3.5>		product = <product, defined in [Part1], Section 3.5>
	relativeURI = <relativeURI, defined in [Part1], Section 3.2.1>		relativeURI = <relativeURI, defined in [Part1], Section 3.2>
	TE = <TE, defined in [Part1], Section 8.8>		TE = <TE, defined in [Part1], Section 8.8>
	Accept = <Accept, defined in [Part3], Section 6.1>		Accept = <Accept, defined in [Part3], Section 6.1>
	Accept-Charset =		Accept-Charset =
	<Accept-Charset, defined in [Part3], Section 6.2>		<Accept-Charset, defined in [Part3], Section 6.2>
	Accept-Encoding =		Accept-Encoding =
	<Accept-Encoding, defined in [Part3], Section 6.3>		<Accept-Encoding, defined in [Part3], Section 6.3>
	Accept-Language =		Accept-Language =
	<Accept-Language, defined in [Part3], Section 6.4>		<Accept-Language, defined in [Part3], Section 6.4>
	skipping to change at page 8, line 12		skipping to change at page 8, line 18
	<Proxy-Authorization, defined in [Part7], Section 4.3>		<Proxy-Authorization, defined in [Part7], Section 4.3>
	WWW-Authenticate =		WWW-Authenticate =
	<WWW-Authenticate, defined in [Part7], Section 4.4>		<WWW-Authenticate, defined in [Part7], Section 4.4>
	3. Method		3. Method
	The Method token indicates the method to be performed on the resource		The Method token indicates the method to be performed on the resource
	identified by the Request-URI. The method is case-sensitive.		identified by the Request-URI. The method is case-sensitive.
	Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2		Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2
	| %x47.45.54 ; "GET", Section 8.3		/ %x47.45.54 ; "GET", Section 8.3
	| %x48.45.41.44 ; "HEAD", Section 8.4		/ %x48.45.41.44 ; "HEAD", Section 8.4
	| %x50.4F.53.54 ; "POST", Section 8.5		/ %x50.4F.53.54 ; "POST", Section 8.5
	| %x50.55.54 ; "PUT", Section 8.6		/ %x50.55.54 ; "PUT", Section 8.6
	| %x44.45.4C.45.54.45 ; "DELETE", Section 8.7		/ %x44.45.4C.45.54.45 ; "DELETE", Section 8.7
	| %x54.52.41.43.45 ; "TRACE", Section 8.8		/ %x54.52.41.43.45 ; "TRACE", Section 8.8
	| %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9		/ %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9
	| extension-method		/ extension-method
	extension-method = token		extension-method = token
	The list of methods allowed by a resource can be specified in an		The list of methods allowed by a resource can be specified in an
	Allow header field (Section 10.1). The return code of the response		Allow header field (Section 10.1). The return code of the response
	always notifies the client whether a method is currently allowed on a		always notifies the client whether a method is currently allowed on a
	resource, since the set of allowed methods can change dynamically.		resource, since the set of allowed methods can change dynamically.
	An origin server SHOULD return the status code 405 (Method Not		An origin server SHOULD return the status code 405 (Method Not
	Allowed) if the method is known by the origin server but not allowed		Allowed) if the method is known by the origin server but not allowed
	for the requested resource, and 501 (Not Implemented) if the method		for the requested resource, and 501 (Not Implemented) if the method
	is unrecognized or not implemented by the origin server. The methods		is unrecognized or not implemented by the origin server. The methods
	skipping to change at page 9, line 18		skipping to change at page 9, line 25
	4. Request Header Fields		4. Request Header Fields
	The request-header fields allow the client to pass additional		The request-header fields allow the client to pass additional
	information about the request, and about the client itself, to the		information about the request, and about the client itself, to the
	server. These fields act as request modifiers, with semantics		server. These fields act as request modifiers, with semantics
	equivalent to the parameters on a programming language method		equivalent to the parameters on a programming language method
	invocation.		invocation.
	request-header = Accept ; [Part3], Section 6.1		request-header = Accept ; [Part3], Section 6.1
	| Accept-Charset ; [Part3], Section 6.2		/ Accept-Charset ; [Part3], Section 6.2
	| Accept-Encoding ; [Part3], Section 6.3		/ Accept-Encoding ; [Part3], Section 6.3
	| Accept-Language ; [Part3], Section 6.4		/ Accept-Language ; [Part3], Section 6.4
	| Authorization ; [Part7], Section 4.1		/ Authorization ; [Part7], Section 4.1
	| Expect ; Section 10.2		/ Expect ; Section 10.2
	| From ; Section 10.3		/ From ; Section 10.3
	| Host ; [Part1], Section 8.4		/ Host ; [Part1], Section 8.4
	| If-Match ; [Part4], Section 7.2		/ If-Match ; [Part4], Section 7.2
	| If-Modified-Since ; [Part4], Section 7.3		/ If-Modified-Since ; [Part4], Section 7.3
	| If-None-Match ; [Part4], Section 7.4		/ If-None-Match ; [Part4], Section 7.4
	| If-Range ; [Part5], Section 6.3		/ If-Range ; [Part5], Section 6.3
	| If-Unmodified-Since ; [Part4], Section 7.5		/ If-Unmodified-Since ; [Part4], Section 7.5
	| Max-Forwards ; Section 10.5		/ Max-Forwards ; Section 10.5
	| Proxy-Authorization ; [Part7], Section 4.3		/ Proxy-Authorization ; [Part7], Section 4.3
	| Range ; [Part5], Section 6.4		/ Range ; [Part5], Section 6.4
	| Referer ; Section 10.6		/ Referer ; Section 10.6
	| TE ; [Part1], Section 8.8		/ TE ; [Part1], Section 8.8
	| User-Agent ; Section 10.9		/ User-Agent ; Section 10.9
	Request-header field names can be extended reliably only in		Request-header field names can be extended reliably only in
	combination with a change in the protocol version. However, new or		combination with a change in the protocol version. However, new or
	experimental header fields MAY be given the semantics of request-		experimental header fields MAY be given the semantics of request-
	header fields if all parties in the communication recognize them to		header fields if all parties in the communication recognize them to
	be request-header fields. Unrecognized header fields are treated as		be request-header fields. Unrecognized header fields are treated as
	entity-header fields.		entity-header fields.
	5. Status Code and Reason Phrase		5. Status Code and Reason Phrase
	skipping to change at page 11, line 7		skipping to change at page 11, line 7
	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's, are
	presented below. The reason phrases listed here are only		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 9.1.1: Continue		"100" ; Section 9.1.1: Continue
	| "101" ; Section 9.1.2: Switching Protocols		/ "101" ; Section 9.1.2: Switching Protocols
	| "200" ; Section 9.2.1: OK		/ "200" ; Section 9.2.1: OK
	| "201" ; Section 9.2.2: Created		/ "201" ; Section 9.2.2: Created
	| "202" ; Section 9.2.3: Accepted		/ "202" ; Section 9.2.3: Accepted
	| "203" ; Section 9.2.4: Non-Authoritative Information		/ "203" ; Section 9.2.4: Non-Authoritative Information
	| "204" ; Section 9.2.5: No Content		/ "204" ; Section 9.2.5: No Content
	| "205" ; Section 9.2.6: Reset Content		/ "205" ; Section 9.2.6: Reset Content
	| "206" ; Section 9.2.7: Partial Content		/ "206" ; Section 9.2.7: Partial Content
	| "300" ; Section 9.3.1: Multiple Choices		/ "300" ; Section 9.3.1: Multiple Choices
	| "301" ; Section 9.3.2: Moved Permanently		/ "301" ; Section 9.3.2: Moved Permanently
	| "302" ; Section 9.3.3: Found		/ "302" ; Section 9.3.3: Found
	| "303" ; Section 9.3.4: See Other		/ "303" ; Section 9.3.4: See Other
	| "304" ; Section 9.3.5: Not Modified		/ "304" ; Section 9.3.5: Not Modified
	| "305" ; Section 9.3.6: Use Proxy		/ "305" ; Section 9.3.6: Use Proxy
	| "307" ; Section 9.3.8: Temporary Redirect		/ "307" ; Section 9.3.8: Temporary Redirect
	| "400" ; Section 9.4.1: Bad Request		/ "400" ; Section 9.4.1: Bad Request
	| "401" ; Section 9.4.2: Unauthorized		/ "401" ; Section 9.4.2: Unauthorized
	| "402" ; Section 9.4.3: Payment Required		/ "402" ; Section 9.4.3: Payment Required
	| "403" ; Section 9.4.4: Forbidden		/ "403" ; Section 9.4.4: Forbidden
	| "404" ; Section 9.4.5: Not Found		/ "404" ; Section 9.4.5: Not Found
	| "405" ; Section 9.4.6: Method Not Allowed		/ "405" ; Section 9.4.6: Method Not Allowed
	| "406" ; Section 9.4.7: Not Acceptable		/ "406" ; Section 9.4.7: Not Acceptable
	| "407" ; Section 9.4.8: Proxy Authentication Required		/ "407" ; Section 9.4.8: Proxy Authentication Required
	| "408" ; Section 9.4.9: Request Time-out		/ "408" ; Section 9.4.9: Request Time-out
	| "409" ; Section 9.4.10: Conflict		/ "409" ; Section 9.4.10: Conflict
	| "410" ; Section 9.4.11: Gone		/ "410" ; Section 9.4.11: Gone
	| "411" ; Section 9.4.12: Length Required		/ "411" ; Section 9.4.12: Length Required
	| "412" ; Section 9.4.13: Precondition Failed		/ "412" ; Section 9.4.13: Precondition Failed
	| "413" ; Section 9.4.14: Request Entity Too Large		/ "413" ; Section 9.4.14: Request Entity Too Large
	| "414" ; Section 9.4.15: Request-URI Too Large		/ "414" ; Section 9.4.15: Request-URI Too Large
	| "415" ; Section 9.4.16: Unsupported Media Type		/ "415" ; Section 9.4.16: Unsupported Media Type
	| "416" ; Section 9.4.17: Requested range not satisfiable		/ "416" ; Section 9.4.17: Requested range not satisfiable
	| "417" ; Section 9.4.18: Expectation Failed		/ "417" ; Section 9.4.18: Expectation Failed
	| "500" ; Section 9.5.1: Internal Server Error		/ "500" ; Section 9.5.1: Internal Server Error
	| "501" ; Section 9.5.2: Not Implemented		/ "501" ; Section 9.5.2: Not Implemented
	| "502" ; Section 9.5.3: Bad Gateway		/ "502" ; Section 9.5.3: Bad Gateway
	| "503" ; Section 9.5.4: Service Unavailable		/ "503" ; Section 9.5.4: Service Unavailable
	| "504" ; Section 9.5.5: Gateway Time-out		/ "504" ; Section 9.5.5: Gateway Time-out
	| "505" ; Section 9.5.6: HTTP Version not supported		/ "505" ; Section 9.5.6: HTTP Version not supported
	| extension-code		/ extension-code
	extension-code = 3DIGIT		extension-code = 3DIGIT
	Reason-Phrase = *<TEXT, excluding CR, LF>		Reason-Phrase = *<TEXT, excluding CR, LF>
	HTTP status codes are extensible. HTTP applications are not required		HTTP status codes are extensible. HTTP applications are not required
	to understand the meaning of all registered status codes, though such		to understand the meaning of all registered status codes, though such
	understanding is obviously desirable. However, applications MUST		understanding is obviously desirable. However, applications MUST
	understand the class of any status code, as indicated by the first		understand the class of any status code, as indicated by the first
	digit, and treat any unrecognized response as being equivalent to the		digit, and treat any unrecognized response as being equivalent to the
	x00 status code of that class, with the exception that an		x00 status code of that class, with the exception that an
	skipping to change at page 12, line 37		skipping to change at page 12, line 37
	<http://www.iana.org/assignments/http-status-codes>.		<http://www.iana.org/assignments/http-status-codes>.
	6. Response Header Fields		6. Response Header Fields
	The response-header fields allow the server to pass additional		The response-header fields allow the server to pass additional
	information about the response which cannot be placed in the Status-		information about the response which cannot be placed in the Status-
	Line. These header fields give information about the server and		Line. These header fields give information about the server and
	about further access to the resource identified by the Request-URI.		about further access to the resource identified by the Request-URI.
	response-header = Accept-Ranges ; [Part5], Section 6.1		response-header = Accept-Ranges ; [Part5], Section 6.1
	| Age ; [Part6], Section 16.1		/ Age ; [Part6], Section 16.1
	| Allow ; Section 10.1		/ Allow ; Section 10.1
	| ETag ; [Part4], Section 7.1		/ ETag ; [Part4], Section 7.1
	| Location ; Section 10.4		/ Location ; Section 10.4
	| Proxy-Authenticate ; [Part7], Section 4.2		/ Proxy-Authenticate ; [Part7], Section 4.2
	| Retry-After ; Section 10.7		/ Retry-After ; Section 10.7
	| Server ; Section 10.8		/ Server ; Section 10.8
	| Vary ; [Part6], Section 16.5		/ Vary ; [Part6], Section 16.5
	| WWW-Authenticate ; [Part7], Section 4.4		/ WWW-Authenticate ; [Part7], Section 4.4
	Response-header field names can be extended reliably only in		Response-header field names can be extended reliably only in
	combination with a change in the protocol version. However, new or		combination with a change in the protocol version. However, new or
	experimental header fields MAY be given the semantics of response-		experimental header fields MAY be given the semantics of response-
	header fields if all parties in the communication recognize them to		header fields if all parties in the communication recognize them to
	be response-header fields. Unrecognized header fields are treated as		be response-header fields. Unrecognized header fields are treated as
	entity-header fields.		entity-header fields.
	7. Entity		7. Entity
	skipping to change at page 15, line 19		skipping to change at page 15, line 19
	this specification. The response body, if any, SHOULD also include		this specification. The response body, if any, SHOULD also include
	information about the communication options. The format for such a		information about the communication options. The format for such a
	body is not defined by this specification, but might be defined by		body is not defined by this specification, but might be defined by
	future extensions to HTTP. Content negotiation MAY be used to select		future extensions to HTTP. Content negotiation MAY be used to select
	the appropriate response format. If no response body is included,		the appropriate response format. If no response body is included,
	the response MUST include a Content-Length field with a field-value		the response MUST include a Content-Length field with a field-value
	of "0".		of "0".
	The Max-Forwards request-header field MAY be used to target a		The Max-Forwards request-header field MAY be used to target a
	specific proxy in the request chain. When a proxy receives an		specific proxy in the request chain. When a proxy receives an
	OPTIONS request on an absoluteURI for which request forwarding is		OPTIONS request on an absolute-URI for which request forwarding is
	permitted, the proxy MUST check for a Max-Forwards field. If the		permitted, the proxy MUST check for a Max-Forwards field. If the
	Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward		Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward
	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.
	8.3. GET		8.3. GET
	skipping to change at page 17, line 32		skipping to change at page 17, line 32
	Request-URI does not point to an existing resource, and that URI is		Request-URI does not point to an existing resource, and that URI is
	capable of being defined as a new resource by the requesting user		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-URI, the origin server MUST		new resource is created at the Request-URI, 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-URI, an appropriate error response SHOULD be given that		the Request-URI, an appropriate error response SHOULD be given that
	reflects the nature of the problem. The recipient of the entity MUST		reflects the nature of the problem. The recipient of the entity MUST
	NOT ignore any Content-* (e.g. Content-Range) headers that it does		NOT ignore any Content-* headers (headers starting with the prefix
	not understand or implement and MUST return a 501 (Not Implemented)		'Content-') that it does not understand or implement and MUST return
	response in such cases.		a 501 (Not Implemented) response in such cases.
	If the request passes through a cache and the Request-URI identifies		If the request passes through a cache and the Request-URI identifies
	one or more currently cached entities, those entries SHOULD be		one or more currently cached entities, those entries SHOULD be
	treated as stale. Responses to this method are not cacheable.		treated as stale. Responses to this method are not 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-URI. The URI in a		reflected in the different meaning of the Request-URI. The URI in a
	POST request identifies the resource that will handle the enclosed		POST request identifies the resource that will handle the enclosed
	entity. That resource might be a data-accepting process, a gateway		entity. That resource might be a data-accepting process, a gateway
	to some other protocol, or a separate entity that accepts		to some other protocol, or a separate entity that accepts
	skipping to change at page 31, line 26		skipping to change at page 31, line 26
	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 request and response semantics.		fields related to request and response semantics.
	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.
	10.1. Allow		10.1. Allow
	The Allow response-header field lists the set of methods advertised		The response-header field "Allow" lists the set of methods advertised
	as supported by the resource identified by the Request-URI. The		as supported by the resource identified by the Request-URI. The
	purpose of this field is strictly to inform the recipient of valid		purpose of this field is strictly to inform the recipient of valid
	methods associated with the resource. An Allow header field MUST be		methods associated with the resource. An Allow header field MUST be
	present in a 405 (Method Not Allowed) response.		present in a 405 (Method Not Allowed) response.
	Allow = "Allow" ":" #Method		Allow = "Allow" ":" OWS Allow-v
			Allow-v = #Method
	Example of use:		Example of use:
	Allow: GET, HEAD, PUT		Allow: GET, HEAD, PUT
	The actual set of allowed methods is defined by the origin server at		The actual set of allowed methods is defined by the origin server at
	the time of each request.		the time of each request.
	A proxy MUST NOT modify the Allow header field even if it does not		A proxy MUST NOT modify the Allow header field even if it does not
	understand all the methods specified, since the user agent might have		understand all the methods specified, since the user agent might have
	other means of communicating with the origin server.		other means of communicating with the origin server.
	10.2. Expect		10.2. Expect
	The Expect request-header field is used to indicate that particular		The request-header field "Expect" is used to indicate that particular
	server behaviors are required by the client.		server behaviors are required by the client.
	Expect = "Expect" ":" 1#expectation		Expect = "Expect" ":" OWS Expect-v
			Expect-v = 1#expectation
	expectation = "100-continue" | expectation-extension		expectation = "100-continue" / expectation-extension
	expectation-extension = token [ "=" ( token | quoted-string )		expectation-extension = token [ "=" ( token / quoted-string )
	*expect-params ]		*expect-params ]
	expect-params = ";" token [ "=" ( token | quoted-string ) ]		expect-params = ";" token [ "=" ( token / quoted-string ) ]
	A server that does not understand or is unable to comply with any of		A server that does not understand or is unable to comply with any of
	the expectation values in the Expect field of a request MUST respond		the expectation values in the Expect field of a request MUST respond
	with appropriate error status. The server MUST respond with a 417		with appropriate error status. The server MUST respond with a 417
	(Expectation Failed) status if any of the expectations cannot be met		(Expectation Failed) status if any of the expectations cannot be met
	or, if there are other problems with the request, some other 4xx		or, if there are other problems with the request, some other 4xx
	status.		status.
	This header field is defined with extensible syntax to allow for		This header field is defined with extensible syntax to allow for
	future extensions. If a server receives a request containing an		future extensions. If a server receives a request containing an
	skipping to change at page 32, line 42		skipping to change at page 32, line 43
	request is forwarded.		request is forwarded.
	Many older HTTP/1.0 and HTTP/1.1 applications do not understand the		Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
	Expect header.		Expect header.
	See Section 7.2.3 of [Part1] for the use of the 100 (Continue)		See Section 7.2.3 of [Part1] for the use of the 100 (Continue)
	status.		status.
	10.3. From		10.3. From
	The From request-header field, if given, SHOULD contain an Internet		The request-header field "From", if given, SHOULD contain an Internet
	e-mail address for the human user who controls the requesting user		e-mail address for the human user who controls the requesting user
	agent. The address SHOULD be machine-usable, as defined by "mailbox"		agent. The address SHOULD be machine-usable, as defined by "mailbox"
	in Section 3.4 of [RFC2822]:		in Section 3.4 of [RFC5322]:
	From = "From" ":" mailbox
	mailbox = <mailbox, defined in [RFC2822], Section 3.4>		From = "From" ":" OWS From-v
			From-v = mailbox
			mailbox = <mailbox, defined in [RFC5322], Section 3.4>
	An example is:		An example is:
	From: webmaster@example.org		From: webmaster@example.org
	This header field MAY be used for logging purposes and as a means for		This header field MAY be used for logging purposes and as a means for
	identifying the source of invalid or unwanted requests. It SHOULD		identifying the source of invalid or unwanted requests. It SHOULD
	NOT be used as an insecure form of access protection. The		NOT be used as an insecure form of access protection. The
	interpretation of this field is that the request is being performed		interpretation of this field is that the request is being performed
	on behalf of the person given, who accepts responsibility for the		on behalf of the person given, who accepts responsibility for the
	method performed. In particular, robot agents SHOULD include this		method performed. In particular, robot agents SHOULD include this
	skipping to change at page 33, line 29		skipping to change at page 33, line 30
	used.		used.
	The client SHOULD NOT send the From header field without the user's		The client SHOULD NOT send the From header field without the user's
	approval, as it might conflict with the user's privacy interests or		approval, as it might conflict with the user's privacy interests or
	their site's security policy. It is strongly recommended that the		their site's security policy. It is strongly recommended that the
	user be able to disable, enable, and modify the value of this field		user be able to disable, enable, and modify the value of this field
	at any time prior to a request.		at any time prior to a request.
	10.4. Location		10.4. Location
	The Location response-header field is used for the identification of		The response-header field "Location" is used for the identification
	a new resource or to redirect the recipient to a location other than		of a new resource or to redirect the recipient to a location other
	the Request-URI for completion of the request. For 201 (Created)		than the Request-URI for completion of the request. For 201
	responses, the Location is that of the new resource which was created		(Created) responses, the Location is that of the new resource which
	by the request. For 3xx responses, the location SHOULD indicate the		was created by the request. For 3xx responses, the location SHOULD
	server's preferred URI for automatic redirection to the resource.		indicate the server's preferred URI for automatic redirection to the
	The field value consists of a single absolute URI.		resource. The field value consists of a single absolute URI.
	Location = "Location" ":" absoluteURI [ "#" fragment ]		Location = "Location" ":" OWS Location-v
			Location-v = absolute-URI [ "#" fragment ]
	An example is:		An example is:
	Location: http://www.example.org/pub/WWW/People.html		Location: http://www.example.org/pub/WWW/People.html
	Note: The Content-Location header field (Section 6.7 of [Part3])		Note: The Content-Location header field (Section 6.7 of [Part3])
	differs from Location in that the Content-Location identifies the		differs from Location in that the Content-Location identifies the
	original location of the entity enclosed in the response. It is		original location of the entity enclosed in the response. It is
	therefore possible for a response to contain header fields for		therefore possible for a response to contain header fields for
	both Location and Content-Location.		both Location and Content-Location.
	skipping to change at page 34, line 16		skipping to change at page 34, line 17
	header specifies the URL for the entire created resource.		header specifies the URL for the entire created resource.
	o With a 300 Multiple Choices, since the choice decision is intended		o With a 300 Multiple Choices, since the choice decision is intended
	to be made on resource characteristics and not fragment		to be made on resource characteristics and not fragment
	characteristics.		characteristics.
	o With 305 Use Proxy.		o With 305 Use Proxy.
	10.5. Max-Forwards		10.5. Max-Forwards
	The Max-Forwards request-header field provides a mechanism with the		The request-header "Max-Forwards" field provides a mechanism with the
	TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the		TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the
	number of proxies or gateways that can forward the request to the		number of proxies or gateways that can forward the request to the
	next inbound server. This can be useful when the client is		next inbound server. This can be useful when the client is
	attempting to trace a request chain which appears to be failing or		attempting to trace a request chain which appears to be failing or
	looping in mid-chain.		looping in mid-chain.
	Max-Forwards = "Max-Forwards" ":" 1*DIGIT		Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v
			Max-Forwards-v = 1*DIGIT
	The Max-Forwards value is a decimal integer indicating the remaining		The Max-Forwards value is a decimal integer indicating the remaining
	number of times this request message may be forwarded.		number of times this request message may be forwarded.
	Each proxy or gateway recipient of a TRACE or OPTIONS request		Each proxy or gateway recipient of a TRACE or OPTIONS request
	containing a Max-Forwards header field MUST check and update its		containing a Max-Forwards header field MUST check and update its
	value prior to forwarding the request. If the received value is zero		value prior to forwarding the request. If the received value is zero
	(0), the recipient MUST NOT forward the request; instead, it MUST		(0), the recipient MUST NOT forward the request; instead, it MUST
	respond as the final recipient. If the received Max-Forwards value		respond as the final recipient. If the received Max-Forwards value
	is greater than zero, then the forwarded message MUST contain an		is greater than zero, then the forwarded message MUST contain an
	updated Max-Forwards field with a value decremented by one (1).		updated Max-Forwards field with a value decremented by one (1).
	The Max-Forwards header field MAY be ignored for all other methods		The Max-Forwards header field MAY be ignored for all other methods
	defined by this specification and for any extension methods for which		defined by this specification and for any extension methods for which
	it is not explicitly referred to as part of that method definition.		it is not explicitly referred to as part of that method definition.
	10.6. Referer		10.6. Referer
	The Referer[sic] request-header field allows the client to specify,		The request-header field "Referer" [sic] allows the client to
	for the server's benefit, the address (URI) of the resource from		specify, for the server's benefit, the address (URI) of the resource
	which the Request-URI was obtained (the "referrer", although the		from which the Request-URI was obtained (the "referrer", although the
	header field is misspelled.) The Referer request-header allows a		header field is misspelled.) The Referer request-header allows a
	server to generate lists of back-links to resources for interest,		server to generate lists of back-links to resources for interest,
	logging, optimized caching, etc. It also allows obsolete or mistyped		logging, optimized caching, etc. It also allows obsolete or mistyped
	links to be traced for maintenance. The Referer field MUST NOT be		links to be traced for maintenance. The Referer field MUST NOT be
	sent if the Request-URI was obtained from a source that does not have		sent if the Request-URI was obtained from a source that does not have
	its own URI, such as input from the user keyboard.		its own URI, such as input from the user keyboard.
	Referer = "Referer" ":" ( absoluteURI | relativeURI )		Referer = "Referer" ":" OWS Referer-v
			Referer-v = absolute-URI / relativeURI
	Example:		Example:
	Referer: http://www.example.org/hypertext/Overview.html		Referer: http://www.example.org/hypertext/Overview.html
	If the field value is a relative URI, it SHOULD be interpreted		If the field value is a relative URI, it SHOULD be interpreted
	relative to the Request-URI. The URI MUST NOT include a fragment.		relative to the Request-URI. The URI MUST NOT include a fragment.
	See Section 12.2 for security considerations.		See Section 12.2 for security considerations.
	10.7. Retry-After		10.7. Retry-After
	The Retry-After response-header field can be used with a 503 (Service		The response-header "Retry-After" field can be used with a 503
	Unavailable) response to indicate how long the service is expected to		(Service Unavailable) response to indicate how long the service is
	be unavailable to the requesting client. This field MAY also be used		expected to be unavailable to the requesting client. This field MAY
	with any 3xx (Redirection) response to indicate the minimum time the		also be used with any 3xx (Redirection) response to indicate the
	user-agent is asked wait before issuing the redirected request. The		minimum time the user-agent is asked wait before issuing the
	value of this field can be either an HTTP-date or an integer number		redirected request. The value of this field can be either an HTTP-
	of seconds (in decimal) after the time of the response.		date or an integer number of seconds (in decimal) after the time of
			the response.
	Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )		Retry-After = "Retry-After" ":" OWS Retry-After-v
			Retry-After-v = HTTP-date / delta-seconds
	Time spans are non-negative decimal integers, representing time in		Time spans are non-negative decimal integers, representing time in
	seconds.		seconds.
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	Two examples of its use are		Two examples of its use are
	Retry-After: Fri, 31 Dec 1999 23:59:59 GMT		Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
	Retry-After: 120		Retry-After: 120
	In the latter example, the delay is 2 minutes.		In the latter example, the delay is 2 minutes.
	10.8. Server		10.8. Server
	The Server response-header field contains information about the		The response-header field "Server" contains information about the
	software used by the origin server to handle the request. The field		software used by the origin server to handle the request. The field
	can contain multiple product tokens (Section 3.5 of [Part1]) and		can contain multiple product tokens (Section 3.5 of [Part1]) and
	comments identifying the server and any significant subproducts. The		comments identifying the server and any significant subproducts. The
	product tokens are listed in order of their significance for		product tokens are listed in order of their significance for
	identifying the application.		identifying the application.
	Server = "Server" ":" 1*( product | comment )		Server = "Server" ":" OWS Server-v
			Server-v = product
			*( RWS ( product / comment ) )
	Example:		Example:
	Server: CERN/3.0 libwww/2.17		Server: CERN/3.0 libwww/2.17
	If the response is being forwarded through a proxy, the proxy		If the response is being forwarded through a proxy, the proxy
	application MUST NOT modify the Server response-header. Instead, it		application MUST NOT modify the Server response-header. Instead, it
	MUST include a Via field (as described in Section 8.9 of [Part1]).		MUST include a Via field (as described in Section 8.9 of [Part1]).
	Note: Revealing the specific software version of the server might		Note: Revealing the specific software version of the server might
	allow the server machine to become more vulnerable to attacks		allow the server machine to become more vulnerable to attacks
	against software that is known to contain security holes. Server		against software that is known to contain security holes. Server
	implementors are encouraged to make this field a configurable		implementors are encouraged to make this field a configurable
	option.		option.
	10.9. User-Agent		10.9. User-Agent
	The User-Agent request-header field contains information about the		The request-header field "User-Agent" contains information about the
	user agent originating the request. This is for statistical		user agent originating the request. This is for statistical
	purposes, the tracing of protocol violations, and automated		purposes, the tracing of protocol violations, and automated
	recognition of user agents for the sake of tailoring responses to		recognition of user agents for the sake of tailoring responses to
	avoid particular user agent limitations. User agents SHOULD include		avoid particular user agent limitations. User agents SHOULD include
	this field with requests. The field can contain multiple product		this field with requests. The field can contain multiple product
	tokens (Section 3.5 of [Part1]) and comments identifying the agent		tokens (Section 3.5 of [Part1]) and comments identifying the agent
	and any subproducts which form a significant part of the user agent.		and any subproducts which form a significant part of the user agent.
	By convention, the product tokens are listed in order of their		By convention, the product tokens are listed in order of their
	significance for identifying the application.		significance for identifying the application.
	User-Agent = "User-Agent" ":" 1*( product | comment )		User-Agent = "User-Agent" ":" OWS User-Agent-v
			User-Agent-v = product
			*( RWS ( product / comment ) )
	Example:		Example:
	User-Agent: CERN-LineMode/2.15 libwww/2.17b3		User-Agent: CERN-LineMode/2.15 libwww/2.17b3
	11. IANA Considerations		11. IANA Considerations
	11.1. Method Registry		11.1. Method Registry
	The registration procedure for HTTP Methods is defined by Section 3.1		The registration procedure for HTTP Methods is defined by Section 3.1
	skipping to change at page 41, line 22		skipping to change at page 41, line 22
	13. Acknowledgments		13. Acknowledgments
	14. References		14. References
	14.1. Normative References		14.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.
	[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-04		and Content Negotiation", draft-ietf-httpbis-p3-payload-05
	(work in progress), August 2008.		(work in progress), November 2008.
	[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-04 (work in		Requests", draft-ietf-httpbis-p4-conditional-05 (work in
	progress), August 2008.		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.
	[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-04 (work in progress),		draft-ietf-httpbis-p7-auth-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.
	14.2. Informative References		14.2. Informative References
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
	Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.		Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
	[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.
	[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within		[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
	HTTP/1.1", RFC 2817, May 2000.		HTTP/1.1", RFC 2817, May 2000.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
			[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
			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 9.5.5).		(e.g. DNS failures). (Section 9.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 9.2.2).		resource is first created. (Section 9.2.2).
	skipping to change at page 44, line 32		skipping to change at page 44, line 32
	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-p2-semantics-00		B.2. Since draft-ietf-httpbis-p2-semantics-00
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a		o <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
	MUST" (<http://purl.org/NET/http-errata#via-must>)		(<http://purl.org/NET/http-errata#via-must>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments		o <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
	allowed in Location"		allowed in Location"
	(<http://purl.org/NET/http-errata#location-fragments>)		(<http://purl.org/NET/http-errata#location-fragments>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe		o <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
	Methods vs Redirection"		vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>)
	(<http://purl.org/NET/http-errata#saferedirect>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise		o <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
	description of the POST method"		description of the POST method"
	(<http://purl.org/NET/http-errata#post>)		(<http://purl.org/NET/http-errata#post>)
	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"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
	Compliance"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
	"Informative references"		Compliance"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
			references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant		o <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
	cross-references"		cross-references"
	Other changes:		Other changes:
	o Move definitions of 304 and 412 condition codes to [Part4]		o Move definitions of 304 and 412 condition codes to [Part4]
	B.3. Since draft-ietf-httpbis-p2-semantics-01		B.3. Since draft-ietf-httpbis-p2-semantics-01
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side		o <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
	effects"		effects"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate		o <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
	Host header requirements"		header requirements"
	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 Move "Product Tokens" section (back) into Part 1, as "token" is		o Move "Product Tokens" section (back) into Part 1, as "token" is
	used in the definition of the Upgrade header.		used in the definition of the Upgrade header.
	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.
	o Copy definition of delta-seconds from Part6 instead of referencing		o Copy definition of delta-seconds from Part6 instead of referencing
	it.		it.
	B.4. Since draft-ietf-httpbis-p2-semantics-02		B.4. Since draft-ietf-httpbis-p2-semantics-02
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring		o <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
	Allow in 405 responses"		Allow in 405 responses"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status		o <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code
	Code Registry"		Registry"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection
	"Redirection vs. Location"		vs. Location"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70>:
	"Cacheability of 303 response"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use		o <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability
	Proxy"		of 303 response"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
	"Classification for Allow header"		"Classification for Allow header"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT -		o <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
	'store under' vs 'store at'"		under' vs 'store at'"
	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.
	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 Replace string literals when the string really is case-sensitive		o Replace string literals when the string really is case-sensitive
	(method).		(method).
	B.5. Since draft-ietf-httpbis-p2-semantics-03		B.5. Since draft-ietf-httpbis-p2-semantics-03
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS		o <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
	request bodies"		request bodies"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/119>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description
	"Description of CONNECT should refer to RFC2817"		of CONNECT should refer to RFC2817"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location		o <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
	Content-Location reference request/response mixup"		Content-Location reference request/response mixup"
	Ongoing work on Method Registry		Ongoing work on Method Registry
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/72>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/72>):
	o Added initial proposal for registration process, plus initial		o Added initial proposal for registration process, plus initial
	content (non-HTTP/1.1 methods to be added by a separate		content (non-HTTP/1.1 methods to be added by a separate
	specification).		specification).
			B.6. Since draft-ietf-httpbis-p2-semantics-04
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
			updated by RFC 5322"
			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
	1		1
	100 Continue (status code) 19		100 Continue (status code) 19
	101 Switching Protocols (status code) 20		101 Switching Protocols (status code) 20
	2		2
	200 OK (status code) 20		200 OK (status code) 20
	201 Created (status code) 20		201 Created (status code) 20
	202 Accepted (status code) 21		202 Accepted (status code) 21
	skipping to change at page 48, line 25		skipping to change at page 48, line 40
	E		E
	Expect header 31		Expect header 31
	F		F
	From header 32		From header 32
	G		G
	GET method 15		GET method 15
	Grammar		Grammar
	Allow 31		Allow 31
			Allow-v 31
	delta-seconds 35		delta-seconds 35
	Expect 32		Expect 32
	expect-params 32		expect-params 32
			Expect-v 32
	expectation 32		expectation 32
	expectation-extension 32		expectation-extension 32
	extension-code 11		extension-code 11
	extension-method 8		extension-method 8
	From 32		From 32
			From-v 32
	Location 33		Location 33
			Location-v 33
	Max-Forwards 34		Max-Forwards 34
			Max-Forwards-v 34
	Method 8		Method 8
	Reason-Phrase 11		Reason-Phrase 11
	Referer 34		Referer 35
			Referer-v 35
	request-header 9		request-header 9
	response-header 12		response-header 12
	Retry-After 35		Retry-After 35
	Server 35		Retry-After-v 35
			Server 36
			Server-v 36
	Status-Code 11		Status-Code 11
	User-Agent 36		User-Agent 36
			User-Agent-v 36
	H		H
	HEAD method 16		HEAD method 16
	Headers		Headers
	Allow 31		Allow 31
	Expect 31		Expect 31
	From 32		From 32
	Location 33		Location 33
	Max-Forwards 34		Max-Forwards 34
	Referer 34		Referer 34
End of changes. 80 change blocks.
	187 lines changed or deleted		226 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/