draft-ietf-httpbis-p2-semantics-17.txt		draft-ietf-httpbis-p2-semantics-18.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Updates: 2817 (if approved) Alcatel-Lucent		Updates: 2817 (if approved) Alcatel-Lucent
	Intended status: Standards Track J. Mogul		Intended status: Standards Track J. Mogul
	Expires: May 3, 2012 HP		Expires: July 7, 2012 HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	October 31, 2011		January 4, 2012
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-17		draft-ietf-httpbis-p2-semantics-18
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 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.		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	skipping to change at page 2, line 5		skipping to change at page 2, line 5
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org), which is archived at		group mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.18.		The changes in this draft are summarized in Appendix C.19.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 3, 2012.		This Internet-Draft will expire on July 7, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 18		skipping to change at page 3, line 18
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8		2.1. Overview of Methods . . . . . . . . . . . . . . . . . . . 8
	2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8		2.2. Method Registry . . . . . . . . . . . . . . . . . . . . . 8
	2.2.1. Considerations for New Methods . . . . . . . . . . . . 9		2.2.1. Considerations for New Methods . . . . . . . . . . . . 9
	3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Considerations for Creating Header Fields . . . . . . . . 9		3.1. Considerations for Creating Header Fields . . . . . . . . 9
	3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11		3.2. Request Header Fields . . . . . . . . . . . . . . . . . . 11
	3.3. Response Header Fields . . . . . . . . . . . . . . . . . . 12		3.3. Response Header Fields . . . . . . . . . . . . . . . . . . 12
	4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 12		4. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 13
	4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 13		4.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 13
	4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 15		4.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 15
	4.2.1. Considerations for New Status Codes . . . . . . . . . 15		4.2.1. Considerations for New Status Codes . . . . . . . . . 15
	5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16		5. Representation . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. Identifying the Resource Associated with a		5.1. Identifying the Resource Associated with a
	Representation . . . . . . . . . . . . . . . . . . . . . . 16		Representation . . . . . . . . . . . . . . . . . . . . . . 16
	6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17		6. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 17
	6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17		6.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 17
	6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17		6.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 17
	6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17		6.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 17
	skipping to change at page 4, line 19		skipping to change at page 4, line 19
	7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33		7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33
	7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33		7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33
	7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 34		7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 34
	7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 34		7.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 34
	7.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 34		7.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 34
	7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34		7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34
	7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34		7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34
	7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35		7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35
	7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35		7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35
	7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35		7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35
	7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 35		7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 36
	7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36		7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36
	7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36		7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36
	7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36		7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36
	7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37		7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37
	7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37		7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37
	7.4.14. 413 Request Representation Too Large . . . . . . . . . 37		7.4.14. 413 Request Representation Too Large . . . . . . . . . 37
	7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37		7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37
	7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37		7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37
	7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38		7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38
	7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38		7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38
	skipping to change at page 5, line 4		skipping to change at page 5, line 4
	9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44		9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44
	9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44		9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
	9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45		9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45
	9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46		9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46
	9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47		9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47
	9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47		9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47
	9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48		9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48
	9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48		9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
	10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49		10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49
	10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 49		10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 50
	10.3. Header Field Registration . . . . . . . . . . . . . . . . 51		10.3. Header Field Registration . . . . . . . . . . . . . . . . 51
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 51		11. Security Considerations . . . . . . . . . . . . . . . . . . . 52
	11.1. Transfer of Sensitive Information . . . . . . . . . . . . 51		11.1. Transfer of Sensitive Information . . . . . . . . . . . . 52
	11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 52		11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 53
	11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 53		11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 54
	11.4. Security Considerations for CONNECT . . . . . . . . . . . 53		11.4. Security Considerations for CONNECT . . . . . . . . . . . 54
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 53		13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
	13.2. Informative References . . . . . . . . . . . . . . . . . . 54		13.2. Informative References . . . . . . . . . . . . . . . . . . 55
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 56
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 57
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 59		publication) . . . . . . . . . . . . . . . . . . . . 60
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 59		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 60
	C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 59		C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 60
	C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 59		C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 60
	C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 60		C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 61
	C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 61		C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 62
	C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 61		C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 62
	C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 61		C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 62
	C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 62		C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 63
	C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 62		C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 63
	C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 63		C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 64
	C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 63		C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 64
	C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 63		C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 64
	C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 64		C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 65
	C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 64		C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 65
	C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 65		C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 66
	C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 66		C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 67
	C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 66		C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 67
	C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 66		C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 67
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66		C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . . 67
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
	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
	uniform interface, the intentions defined by each request method, and		uniform interface, the intentions defined by each request method, and
	skipping to change at page 7, line 26		skipping to change at page 7, line 26
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line		HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
	feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any		feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
	visible US-ASCII character).		visible US-ASCII character).
	1.2.1. Core Rules		1.2.1. Core Rules
	The core rules below are defined in [Part1]:		The core rules below are defined in [Part1]:
			BWS = <BWS, defined in [Part1], Section 1.2.2>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	RWS = <RWS, defined in [Part1], Section 1.2.2>		RWS = <RWS, defined in [Part1], Section 1.2.2>
	obs-text = <obs-text, defined in [Part1], Section 1.2.2>		obs-text = <obs-text, defined in [Part1], Section 1.2.2>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.3>
	1.2.2. ABNF Rules defined in other Parts of the Specification		1.2.2. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	skipping to change at page 10, line 22		skipping to change at page 10, line 24
	comma are protected with double-quotes using the quoted-string ABNF		comma are protected with double-quotes using the quoted-string ABNF
	production (Section 3.2.3 of [Part1]).		production (Section 3.2.3 of [Part1]).
	For example, a textual date and a URI (either of which might contain		For example, a textual date and a URI (either of which might contain
	a comma) could be safely carried in field-values like these:		a comma) could be safely carried in field-values like these:
	Example-URI-Field: "http://example.com/a.html,foo",		Example-URI-Field: "http://example.com/a.html,foo",
	"http://without-a-comma.example.com/"		"http://without-a-comma.example.com/"
	Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"		Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
			Note that double quote delimiters almost always are used with the
			quoted-string production; using a different syntax inside double
			quotes will likely cause unnecessary confusion.
	Many header fields use a format including (case-insensitively) named		Many header fields use a format including (case-insensitively) named
	parameters (for instance, Content-Type, defined in Section 6.8 of		parameters (for instance, Content-Type, defined in Section 6.8 of
	[Part3]). Allowing both unquoted (token) and quoted (quoted-string)		[Part3]). Allowing both unquoted (token) and quoted (quoted-string)
	syntax for the parameter value enables recipients to use existing		syntax for the parameter value enables recipients to use existing
	parser components. When allowing both forms, the meaning of a		parser components. When allowing both forms, the meaning of a
	parameter value ought to be independent of the syntax used for it		parameter value ought to be independent of the syntax used for it
	(for an example, see the notes on parameter handling for media types		(for an example, see the notes on parameter handling for media types
	in Section 2.3 of [Part3]).		in Section 2.3 of [Part3]).
	Authors of specifications defining new header fields are advised to		Authors of specifications defining new header fields are advised to
	skipping to change at page 30, line 36		skipping to change at page 30, line 36
	type of redirect with the status code 303 (See Other) ([RFC2068],		type of redirect with the status code 303 (See Other) ([RFC2068],
	Section 10.3.4). As user agents did not change their behavior to		Section 10.3.4). As user agents did not change their behavior to
	maintain backwards compatibility, the first revision of HTTP/1.1		maintain backwards compatibility, the first revision of HTTP/1.1
	added yet another status code, 307 (Temporary Redirect), for which		added yet another status code, 307 (Temporary Redirect), for which
	the backwards compatibility problems did not apply ([RFC2616],		the backwards compatibility problems did not apply ([RFC2616],
	Section 10.3.8). Over 10 years later, most user agents still do		Section 10.3.8). Over 10 years later, most user agents still do
	method rewriting for status codes 301 and 302, therefore this		method rewriting for status codes 301 and 302, therefore this
	specification makes that behavior compliant in case the original		specification makes that behavior compliant in case the original
	request was POST.		request was POST.
			A Location header field on a 3xx response indicates that a client MAY
			automatically redirect to the URI provided; see Section 9.5.
	Clients SHOULD detect and intervene in cyclical redirections (i.e.,		Clients SHOULD detect and intervene in cyclical redirections (i.e.,
	"infinite" redirection loops).		"infinite" redirection loops).
	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 need to be aware that some clients might implement such		developers need to be aware that some clients might implement such
	a fixed limitation.		a fixed limitation.
	7.3.1. 300 Multiple Choices		7.3.1. 300 Multiple Choices
	skipping to change at page 34, line 5		skipping to change at page 34, line 5
	the information necessary for a user to repeat the original request		the information necessary for a user to repeat the original request
	on the new URI.		on the new URI.
	If the 307 status code is received in response to a request method		If the 307 status code is received in response to a request method
	that is known to be "safe", as defined in Section 6.1.1, then the		that is known to be "safe", as defined in Section 6.1.1, then the
	request MAY be automatically redirected by the user agent without		request MAY be automatically redirected by the user agent without
	confirmation. Otherwise, the user agent MUST NOT automatically		confirmation. Otherwise, the user agent MUST NOT automatically
	redirect the request unless it can be confirmed by the user, since		redirect the request unless it can be confirmed by the user, since
	this might change the conditions under which the request was issued.		this might change the conditions under which the request was issued.
			Note: This status code is similar to 302 Found, except that it
			does not allow rewriting the request method from POST to GET.
			This specification defines no equivalent counterpart for 301 Moved
			Permanently.
	7.4. Client Error 4xx		7.4. Client Error 4xx
	The 4xx class of status code is intended for cases in which the		The 4xx class of status code is intended for cases in which the
	client seems to have erred. Except when responding to a HEAD		client seems to have erred. Except when responding to a HEAD
	request, the server SHOULD include a representation containing an		request, the server SHOULD include a representation containing an
	explanation of the error situation, and whether it is a temporary or		explanation of the error situation, and whether it is a temporary or
	permanent condition. These status codes are applicable to any		permanent condition. These status codes are applicable to any
	request method. User agents SHOULD display any included		request method. User agents SHOULD display any included
	representation to the user.		representation to the user.
	skipping to change at page 39, line 20		skipping to change at page 39, line 20
	any resource.		any resource.
	7.5.3. 502 Bad Gateway		7.5.3. 502 Bad Gateway
	The server, while acting as a gateway or proxy, received an invalid		The server, while acting as a gateway or proxy, received an invalid
	response from the upstream server it accessed in attempting to		response from the upstream server it accessed in attempting to
	fulfill the request.		fulfill the request.
	7.5.4. 503 Service Unavailable		7.5.4. 503 Service Unavailable
	The server is currently unable or unwilling to handle the request due		The server is currently unable to handle the request due to a
	to reasons such as temporary overloading, maintenance of the server,		temporary overloading or maintenance of the server.
	or rate limiting of the client.
	The implication is that this is a temporary condition which will be		The implication is that this is a temporary condition which will be
	alleviated after some delay. If known, the length of the delay MAY		alleviated after some delay. If known, the length of the delay MAY
	be indicated in a Retry-After header field (Section 9.8). If no		be indicated in a Retry-After header field (Section 9.8). If no
	Retry-After is given, the client SHOULD handle the response as it		Retry-After is given, the client SHOULD handle the response as it
	would for a 500 response.		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 might		server must use it when becoming overloaded. Some servers might
	wish to simply refuse the connection.		wish to simply refuse the connection.
	skipping to change at page 44, line 15		skipping to change at page 44, line 15
	In practice, the date can be generated at any time during the message		In practice, the date can be generated at any time during the message
	origination without affecting its semantic value.		origination without affecting its semantic value.
	9.3. Expect		9.3. Expect
	The "Expect" header field is used to indicate that particular server		The "Expect" header field is used to indicate that particular server
	behaviors are required by the client.		behaviors are required by the client.
	Expect = 1#expectation		Expect = 1#expectation
	expectation = "100-continue" / expectation-extension		expectation = expect-name [ BWS "=" BWS expect-value ]
	expectation-extension = token [ "=" ( token / quoted-string )		*( OWS ";" [ OWS expect-param ] )
	*expect-params ]		expect-param = expect-name [ BWS "=" BWS expect-value ]
	expect-params = ";" token [ "=" ( token / quoted-string ) ]
	A server that does not understand or is unable to comply with any of		expect-name = token
	the expectation values in the Expect field of a request MUST respond		expect-value = token / quoted-string
	with appropriate error status code. The server MUST respond with a
	417 (Expectation Failed) status code if any of the expectations
	cannot be met or, if there are other problems with the request, some
	other 4xx status code.
	This header field is defined with extensible syntax to allow for		If all received Expect header field(s) are syntactically valid but
	future extensions. If a server receives a request containing an		contain an expectation that the recipient does not understand or
	Expect field that includes an expectation-extension that it does not		cannot comply with, the recipient MUST respond with a 417
	support, it MUST respond with a 417 (Expectation Failed) status code.		(Expectation Failed) status code. A recipient of a syntactically
			invalid Expectation header field MUST respond with a 4xx status code
			other than 417.
	Comparison of expectation values is case-insensitive for unquoted		The only expectation defined by this specification is:
	tokens (including the 100-continue token), and is case-sensitive for
	quoted-string expectation-extensions.
	The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST		100-continue
	return a 417 (Expectation Failed) status code if it receives a
	request with an expectation that it cannot meet. However, the Expect		The "100-continue" expectation is defined Section 6.2.3 of
	header field itself is end-to-end; it MUST be forwarded if the		[Part1]. It does not support any expect-params.
	request is forwarded.
			Comparison is case-insensitive for names (expect-name), and case-
			sensitive for values (expect-value).
			The Expect mechanism is hop-by-hop: the above requirements apply to
			any server, including proxies. However, the Expect header field
			itself is end-to-end; it MUST be forwarded if the 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 field.		Expect header field.
	See Section 6.2.3 of [Part1] for the use of the 100 (Continue) status
	code.
	9.4. From		9.4. From
	The "From" header field, if given, SHOULD contain an Internet e-mail		The "From" header field, if given, SHOULD contain an Internet e-mail
	address for the human user who controls the requesting user agent.		address for the human user who controls the requesting user agent.
	The address SHOULD be machine-usable, as defined by "mailbox" in		The address SHOULD be machine-usable, as defined by "mailbox" in
	Section 3.4 of [RFC5322]:		Section 3.4 of [RFC5322]:
	From = mailbox		From = mailbox
	mailbox = <mailbox, defined in [RFC5322], Section 3.4>		mailbox = <mailbox, defined in [RFC5322], Section 3.4>
	skipping to change at page 46, line 11		skipping to change at page 46, line 11
	([RFC3986], Section 5).		([RFC3986], Section 5).
	Location = URI-reference		Location = URI-reference
	Examples are:		Examples are:
	Location: http://www.example.org/pub/WWW/People.html#tim		Location: http://www.example.org/pub/WWW/People.html#tim
	Location: /index.html		Location: /index.html
			Note: Some recipients attempt to recover from Location fields that
			are not valid URI references. This specification does not mandate
			or define such processing, but does allow it (see Section 1.1).
	There are circumstances in which a fragment identifier in a Location		There are circumstances in which a fragment identifier in a Location
	URI would not be appropriate. For instance, when it appears in a 201		URI would not be appropriate. For instance, when it appears in a 201
	Created response, where the Location header field specifies the URI		Created response, where the Location header field specifies the URI
	for the entire created resource.		for the entire created resource.
	Note: This specification does not define precedence rules for the		Note: This specification does not define precedence rules for the
	case where the original URI, as navigated to by the user agent,		case where the original URI, as navigated to by the user agent,
	and the Location header field value both contain fragment		and the Location header field value both contain fragment
	identifiers. Thus be aware that including fragment identifiers		identifiers. Thus be aware that including fragment identifiers
	might inconvenience anyone relying on the semantics of the		might inconvenience anyone relying on the semantics of the
	skipping to change at page 53, line 43		skipping to change at page 54, line 37
	See Section 11 of [Part1].		See Section 11 of [Part1].
	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-17		and Message Parsing", draft-ietf-httpbis-p1-messaging-18
	(work in progress), October 2011.		(work in progress), January 2012.
	[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-17		and Content Negotiation", draft-ietf-httpbis-p3-payload-18
	(work in progress), October 2011.		(work in progress), January 2012.
	[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-17 (work in		Requests", draft-ietf-httpbis-p4-conditional-18 (work in
	progress), October 2011.		progress), January 2012.
	[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-17 (work		Partial Responses", draft-ietf-httpbis-p5-range-18 (work
	in progress), October 2011.		in progress), January 2012.
	[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-17 (work in		6: Caching", draft-ietf-httpbis-p6-cache-18 (work in
	progress), October 2011.		progress), January 2012.
	[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-17 (work in progress),		draft-ietf-httpbis-p7-auth-18 (work in progress),
	October 2011.		January 2012.
	[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.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[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.
	skipping to change at page 56, line 4		skipping to change at page 56, line 48
	able to make that determination based on the request method		able to make that determination based on the request method
	semantics. Furthermore, allow user agents to rewrite the method from		semantics. Furthermore, allow user agents to rewrite the method from
	POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and		POST to GET for status codes 301 and 302. (Sections 7.3.2, 7.3.3 and
	7.3.8)		7.3.8)
	Deprecate 305 Use Proxy status code, because user agents did not		Deprecate 305 Use Proxy status code, because user agents did not
	implement it. It used to indicate that the target resource must be		implement it. It used to indicate that the target resource must be
	accessed through the proxy given by the Location field. The Location		accessed through the proxy given by the Location field. The Location
	field gave the URI of the proxy. The recipient was expected to		field gave the URI of the proxy. The recipient was expected to
	repeat this single request via the proxy. (Section 7.3.6)		repeat this single request via the proxy. (Section 7.3.6)
	Define status 426 (Upgrade Required) (this was incorporated from		Define status 426 (Upgrade Required) (this was incorporated from
	[RFC2817]). (Section 7.4.19)		[RFC2817]). (Section 7.4.19)
	Change ABNF productions for header fields to only define the field		Change ABNF productions for header fields to only define the field
	value. (Section 9)		value. (Section 9)
	Reclassify "Allow" as response header field, removing the option to		Reclassify "Allow" as response header field, removing the option to
	specify it in a PUT request. Relax the server requirement on the		specify it in a PUT request. Relax the server requirement on the
	contents of the Allow header field and remove requirement on clients		contents of the Allow header field and remove requirement on clients
	to always trust the header field value. (Section 9.1)		to always trust the header field value. (Section 9.1)
			The ABNF for the Expect header field has been both fixed (allowing
			parameters for value-less expectations as well) and simplified
			(allowing trailing semicolons after "100-continue" when they were
			invalid before). (Section 9.3)
	Correct syntax of Location header field to allow URI references		Correct syntax of Location header field to allow URI references
	(including relative references and fragments), as referred symbol		(including relative references and fragments), as referred symbol
	"absoluteURI" wasn't what was expected, and add some clarifications		"absoluteURI" wasn't what was expected, and add some clarifications
	as to when use of fragments would not be appropriate. (Section 9.5)		as to when use of fragments would not be appropriate. (Section 9.5)
	Restrict Max-Forwards header field to OPTIONS and TRACE (previously,		Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
	extension methods could have used it as well). (Section 9.6)		extension methods could have used it as well). (Section 9.6)
	Allow Referer field value of "about:blank" as alternative to not		Allow Referer field value of "about:blank" as alternative to not
	specifying it. (Section 9.7)		specifying it. (Section 9.7)
	In the description of the Server header field, the Via field was		In the description of the Server header field, the Via field was
	described as a SHOULD. The requirement was and is stated correctly		described as a SHOULD. The requirement was and is stated correctly
	in the description of the Via header field in Section 8.8 of [Part1].		in the description of the Via header field in Section 8.8 of [Part1].
	(Section 9.9)		(Section 9.9)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]		Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
			BWS = <BWS, defined in [Part1], Section 1.2.2>
	Date = HTTP-date		Date = HTTP-date
	Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )		Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
	From = mailbox		From = mailbox
	GMT = %x47.4D.54 ; GMT		GMT = %x47.4D.54 ; GMT
	HTTP-date = rfc1123-date / obs-date		HTTP-date = rfc1123-date / obs-date
	skipping to change at page 57, line 40		skipping to change at page 58, line 44
	/ %x53.75.6E ; Sun		/ %x53.75.6E ; Sun
	day-name-l = %x4D.6F.6E.64.61.79 ; Monday		day-name-l = %x4D.6F.6E.64.61.79 ; Monday
	/ %x54.75.65.73.64.61.79 ; Tuesday		/ %x54.75.65.73.64.61.79 ; Tuesday
	/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday		/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
	/ %x54.68.75.72.73.64.61.79 ; Thursday		/ %x54.68.75.72.73.64.61.79 ; Thursday
	/ %x46.72.69.64.61.79 ; Friday		/ %x46.72.69.64.61.79 ; Friday
	/ %x53.61.74.75.72.64.61.79 ; Saturday		/ %x53.61.74.75.72.64.61.79 ; Saturday
	/ %x53.75.6E.64.61.79 ; Sunday		/ %x53.75.6E.64.61.79 ; Sunday
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	expect-params = ";" token [ "=" ( token / quoted-string ) ]		expect-name = token
	expectation = "100-continue" / expectation-extension		expect-param = expect-name [ BWS "=" BWS expect-value ]
	expectation-extension = token [ "=" ( token / quoted-string )		expect-value = token / quoted-string
	*expect-params ]		expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
			OWS expect-param ] )
	hour = 2DIGIT		hour = 2DIGIT
	mailbox = <mailbox, defined in [RFC5322], Section 3.4>		mailbox = <mailbox, defined in [RFC5322], Section 3.4>
	minute = 2DIGIT		minute = 2DIGIT
	month = %x4A.61.6E ; Jan		month = %x4A.61.6E ; Jan
	/ %x46.65.62 ; Feb		/ %x46.65.62 ; Feb
	/ %x4D.61.72 ; Mar		/ %x4D.61.72 ; Mar
	/ %x41.70.72 ; Apr		/ %x41.70.72 ; Apr
	/ %x4D.61.79 ; May		/ %x4D.61.79 ; May
	/ %x4A.75.6E ; Jun		/ %x4A.75.6E ; Jun
	/ %x4A.75.6C ; Jul		/ %x4A.75.6C ; Jul
	/ %x41.75.67 ; Aug		/ %x41.75.67 ; Aug
	skipping to change at page 66, line 47		skipping to change at page 67, line 47
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document		o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
	HTTP's error-handling philosophy"		HTTP's error-handling philosophy"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>:		o <http://tools.ietf.org/wg/httpbis/trac/ticket/231>:
	"Considerations for new headers"		"Considerations for new headers"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303		o <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303
	redirect on HEAD"		redirect on HEAD"
			C.19. Since draft-ietf-httpbis-p2-semantics-17
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
			header payload handling"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
			status code for rate limiting" (change backed out because a new
			status code is being defined for this purpose)
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there
			be a permanent variant of 307"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are
			Location's semantics triggered?"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect'
			grammar missing OWS"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field
			considerations: quoted-string vs use of double quotes"
	Index		Index
	1		1
	100 Continue (status code) 26		100 Continue (status code) 26
			100-continue (expect value) 44
	101 Switching Protocols (status code) 26		101 Switching Protocols (status code) 26
	2		2
	200 OK (status code) 27		200 OK (status code) 27
	201 Created (status code) 27		201 Created (status code) 27
	202 Accepted (status code) 28		202 Accepted (status code) 28
	203 Non-Authoritative Information (status code) 28		203 Non-Authoritative Information (status code) 28
	204 No Content (status code) 28		204 No Content (status code) 28
	205 Reset Content (status code) 29		205 Reset Content (status code) 29
	206 Partial Content (status code) 29		206 Partial Content (status code) 29
	skipping to change at page 67, line 32		skipping to change at page 69, line 6
	307 Temporary Redirect (status code) 33		307 Temporary Redirect (status code) 33
	4		4
	400 Bad Request (status code) 34		400 Bad Request (status code) 34
	401 Unauthorized (status code) 34		401 Unauthorized (status code) 34
	402 Payment Required (status code) 34		402 Payment Required (status code) 34
	403 Forbidden (status code) 34		403 Forbidden (status code) 34
	404 Not Found (status code) 35		404 Not Found (status code) 35
	405 Method Not Allowed (status code) 35		405 Method Not Allowed (status code) 35
	406 Not Acceptable (status code) 35		406 Not Acceptable (status code) 35
	407 Proxy Authentication Required (status code) 35		407 Proxy Authentication Required (status code) 36
	408 Request Timeout (status code) 36		408 Request Timeout (status code) 36
	409 Conflict (status code) 36		409 Conflict (status code) 36
	410 Gone (status code) 36		410 Gone (status code) 36
	411 Length Required (status code) 37		411 Length Required (status code) 37
	412 Precondition Failed (status code) 37		412 Precondition Failed (status code) 37
	413 Request Representation Too Large (status code) 37		413 Request Representation Too Large (status code) 37
	414 URI Too Long (status code) 37		414 URI Too Long (status code) 37
	415 Unsupported Media Type (status code) 37		415 Unsupported Media Type (status code) 37
	416 Requested Range Not Satisfiable (status code) 38		416 Requested Range Not Satisfiable (status code) 38
	417 Expectation Failed (status code) 38		417 Expectation Failed (status code) 38
	skipping to change at page 68, line 17		skipping to change at page 69, line 39
	C		C
	CONNECT method 24		CONNECT method 24
	D		D
	Date header field 43		Date header field 43
	DELETE method 23		DELETE method 23
	E		E
	Expect header field 44		Expect header field 44
			Expect Values
			100-continue 44
	F		F
	From header field 44		From header field 44
	G		G
	GET method 19		GET method 19
	Grammar		Grammar
	Allow 42		Allow 42
	asctime-date 42		asctime-date 42
	Date 43		Date 43
	date1 41		date1 41
	day 41		day 41
	day-name 41		day-name 41
	day-name-l 41		day-name-l 41
	delta-seconds 47		delta-seconds 47
	Expect 44		Expect 44
	expect-params 44		expect-name 44
			expect-param 44
			expect-value 44
	expectation 44		expectation 44
	expectation-extension 44		extension-code 13
	extension-code 12
	From 45		From 45
	GMT 41		GMT 41
	hour 41		hour 41
	HTTP-date 40		HTTP-date 40
	Location 45		Location 45
	Max-Forwards 46		Max-Forwards 46
	Method 7		Method 7
	minute 41		minute 41
	month 41		month 41
	obs-date 41		obs-date 41
	Reason-Phrase 12		Reason-Phrase 13
	Referer 47		Referer 47
	Retry-After 47		Retry-After 47
	rfc850-date 42		rfc850-date 42
	rfc1123-date 41		rfc1123-date 41
	second 41		second 41
	Server 48		Server 48
	Status-Code 12		Status-Code 13
	time-of-day 41		time-of-day 41
	User-Agent 49		User-Agent 49
	year 41		year 41
	H		H
	HEAD method 19		HEAD method 19
	Header Fields		Header Fields
	Allow 42		Allow 42
	Date 43		Date 43
	Expect 44		Expect 44
	skipping to change at page 70, line 33		skipping to change at page 72, line 10
	305 Use Proxy 33		305 Use Proxy 33
	306 (Unused) 33		306 (Unused) 33
	307 Temporary Redirect 33		307 Temporary Redirect 33
	400 Bad Request 34		400 Bad Request 34
	401 Unauthorized 34		401 Unauthorized 34
	402 Payment Required 34		402 Payment Required 34
	403 Forbidden 34		403 Forbidden 34
	404 Not Found 35		404 Not Found 35
	405 Method Not Allowed 35		405 Method Not Allowed 35
	406 Not Acceptable 35		406 Not Acceptable 35
	407 Proxy Authentication Required 35		407 Proxy Authentication Required 36
	408 Request Timeout 36		408 Request Timeout 36
	409 Conflict 36		409 Conflict 36
	410 Gone 36		410 Gone 36
	411 Length Required 37		411 Length Required 37
	412 Precondition Failed 37		412 Precondition Failed 37
	413 Request Representation Too Large 37		413 Request Representation Too Large 37
	414 URI Too Long 37		414 URI Too Long 37
	415 Unsupported Media Type 37		415 Unsupported Media Type 37
	416 Requested Range Not Satisfiable 38		416 Requested Range Not Satisfiable 38
	417 Expectation Failed 38		417 Expectation Failed 38
End of changes. 44 change blocks.
	93 lines changed or deleted		143 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/