draft-ietf-httpbis-p2-semantics-18.txt		draft-ietf-httpbis-p2-semantics-latest.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: July 7, 2012 HP		Expires: August 6, 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
	January 4, 2012		February 3, 2012
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-18		draft-ietf-httpbis-p2-semantics-latest
	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.19.		The changes in this draft are summarized in Appendix C.20.
	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 July 7, 2012.		This Internet-Draft will expire on August 6, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	skipping to change at page 3, line 49		skipping to change at page 3, line 49
	7.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 26		7.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 26
	7.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 26		7.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 26
	7.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 26		7.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 26
	7.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 27		7.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 27
	7.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 27		7.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 27		7.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 27
	7.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 28		7.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 28
	7.2.4. 203 Non-Authoritative Information . . . . . . . . . . 28		7.2.4. 203 Non-Authoritative Information . . . . . . . . . . 28
	7.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 28		7.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 28
	7.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 29		7.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 29
	7.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 29
	7.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 29		7.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 29
	7.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 30		7.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 30
	7.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 31		7.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 31
	7.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 32		7.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 31
	7.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 32		7.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 32
	7.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 33		7.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 33
	7.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 33		7.3.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33
	7.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 33		7.3.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33
	7.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 33		7.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 33
	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. 402 Payment Required . . . . . . . . . . . . . . . . . 34
	7.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 34		7.4.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34
	7.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 34		7.4.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 34
	7.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 35		7.4.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 34
	7.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 35		7.4.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 34
	7.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 35		7.4.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 35
	7.4.8. 407 Proxy Authentication Required . . . . . . . . . . 36		7.4.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 35
	7.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 36		7.4.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36
	7.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 36		7.4.10. 411 Length Required . . . . . . . . . . . . . . . . . 36
	7.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 36		7.4.11. 413 Request Representation Too Large . . . . . . . . . 36
	7.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 37		7.4.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 36
	7.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 37		7.4.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 37
	7.4.14. 413 Request Representation Too Large . . . . . . . . . 37		7.4.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 37
	7.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 37		7.4.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 37
	7.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 37		7.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 37
	7.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 38
	7.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 38
	7.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 38
	7.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 38
	7.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 38		7.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 38
	7.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 39		7.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 38
	7.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 39		7.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 38
	7.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 39		7.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 38
	7.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 39		7.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 38
	7.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 39		7.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 38
	8. Date/Time Formats . . . . . . . . . . . . . . . . . . . . . . 40		8. Date/Time Formats . . . . . . . . . . . . . . . . . . . . . . 39
	9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 42		9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 41
	9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 42		9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	9.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 43		9.2. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 44		9.3. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 44		9.4. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 45		9.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 44
	9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 46		9.6. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 45
	9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 47		9.7. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 46
	9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 47		9.8. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 46
	9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 48		9.9. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 48		9.10. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 47
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
	10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 49		10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 48
	10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 50		10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 49
	10.3. Header Field Registration . . . . . . . . . . . . . . . . 51		10.3. Header Field Registration . . . . . . . . . . . . . . . . 50
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 52		11. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	11.1. Transfer of Sensitive Information . . . . . . . . . . . . 52		11.1. Transfer of Sensitive Information . . . . . . . . . . . . 51
	11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 53		11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 52
	11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 54		11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 53
	11.4. Security Considerations for CONNECT . . . . . . . . . . . 54		11.4. Security Considerations for CONNECT . . . . . . . . . . . 53
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 54		13.1. Normative References . . . . . . . . . . . . . . . . . . . 53
	13.2. Informative References . . . . . . . . . . . . . . . . . . 55		13.2. Informative References . . . . . . . . . . . . . . . . . . 54
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 56		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 55
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 57		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 56
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 60		publication) . . . . . . . . . . . . . . . . . . . . 59
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 60		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 59
	C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 60		C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 59
	C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 60		C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 60
	C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 61		C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 60
	C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 62		C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 61
	C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 62		C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 61
	C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 62		C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 62
	C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 63		C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 62
	C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 63		C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 62
	C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 64		C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 63
	C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 64		C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 63
	C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 64		C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 63
	C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 65		C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 64
	C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 65		C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 64
	C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 66		C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 66
	C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 67		C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 66
	C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 67		C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 66
	C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 67		C.18. Since draft-ietf-httpbis-p2-semantics-16 . . . . . . . . . 66
	C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . . 67		C.19. Since draft-ietf-httpbis-p2-semantics-17 . . . . . . . . . 67
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68		C.20. Since draft-ietf-httpbis-p2-semantics-18 . . . . . . . . . 67
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
	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 10		skipping to change at page 7, line 10
	define specific error handling mechanisms, except in cases where it		define specific error handling mechanisms, except in cases where it
	has direct impact on security. This is because different uses of the		has direct impact on security. This is because different uses of the
	protocol require different error handling strategies; for example, a		protocol require different error handling strategies; for example, a
	Web browser may wish to transparently recover from a response where		Web browser may wish to transparently recover from a response where
	the Location header field doesn't parse according to the ABNF,		the Location header field doesn't parse according to the ABNF,
	whereby in a systems control protocol using HTTP, this type of error		whereby in a systems control protocol using HTTP, this type of error
	recovery could lead to dangerous consequences.		recovery could lead to dangerous consequences.
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the Augmented Backus-Naur Form (ABNF)
	[Part1] (which extends the syntax defined in [RFC5234] with a list		notation of [RFC5234] with the list rule extension defined in Section
	rule). Appendix B shows the collected ABNF, with the list rule		1.2 of [Part1]. Appendix B shows the collected ABNF with the list
	expanded.		rule expanded.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[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>		BWS = <BWS, defined in [Part1], Section 3.2.1>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	RWS = <RWS, defined in [Part1], Section 1.2.2>		RWS = <RWS, defined in [Part1], Section 3.2.1>
	obs-text = <obs-text, defined in [Part1], Section 1.2.2>		obs-text = <obs-text, defined in [Part1], Section 3.2.4>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.4>
	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:
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
	comment = <comment, defined in [Part1], Section 3.2>		comment = <comment, defined in [Part1], Section 3.2.4>
	partial-URI = <partial-URI, defined in [Part1], Section 2.7>		partial-URI = <partial-URI, defined in [Part1], Section 2.7>
	product = <product, defined in [Part1], Section 5.2>		product = <product, defined in [Part1], Section 5.2>
	URI-reference = <URI-reference, defined in [Part1], Section 2.7>		URI-reference = <URI-reference, defined in [Part1], Section 2.7>
	2. Method		2. Method
	The Method token indicates the request method to be performed on the		The Method token indicates the request method to be performed on the
	target resource (Section 4.3 of [Part1]). The method is case-		target resource (Section 4.3 of [Part1]). The method is case-
	sensitive.		sensitive.
	skipping to change at page 10, line 6		skipping to change at page 10, line 6
	New header fields are registered using the procedures described in		New header fields are registered using the procedures described in
	[RFC3864].		[RFC3864].
	The requirements for header field names are defined in Section 4.1 of		The requirements for header field names are defined in Section 4.1 of
	[RFC3864]. Authors of specifications defining new fields are advised		[RFC3864]. Authors of specifications defining new fields are advised
	to keep the name as short as practical, and not to prefix them with		to keep the name as short as practical, and not to prefix them with
	"X-" if they are to be registered (either immediately or in the		"X-" if they are to be registered (either immediately or in the
	future).		future).
	New header field values typically have their syntax defined using		New header field values typically have their syntax defined using
	ABNF ([RFC5234]), using the extensions defined in Section 1.2.1 of		ABNF ([RFC5234]), using the extension defined in Section 3.2.5 of
	[Part1] as necessary, and are usually constrained to the range of		[Part1] as necessary, and are usually constrained to the range of
	ASCII characters. Header fields needing a greater range of		ASCII characters. Header fields needing a greater range of
	characters can use an encoding such as the one defined in [RFC5987].		characters can use an encoding such as the one defined in [RFC5987].
	Because commas (",") are used as a generic delimiter between field-		Because commas (",") are used as a generic delimiter between field-
	values, they need to be treated with care if they are allowed in the		values, they need to be treated with care if they are allowed in the
	field-value's payload. Typically, components that might contain a		field-value's payload. Typically, components that might contain a
	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.4 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		Note that double quote delimiters almost always are used with the
	quoted-string production; using a different syntax inside double		quoted-string production; using a different syntax inside double
	skipping to change at page 14, line 25		skipping to change at page 14, line 25
	| 204 | No Content | Section 7.2.5 |		| 204 | No Content | Section 7.2.5 |
	| 205 | Reset Content | Section 7.2.6 |		| 205 | Reset Content | Section 7.2.6 |
	| 206 | Partial Content | Section 3.1 of |		| 206 | Partial Content | Section 3.1 of |
	| | | [Part5] |		| | | [Part5] |
	| 300 | Multiple Choices | Section 7.3.1 |		| 300 | Multiple Choices | Section 7.3.1 |
	| 301 | Moved Permanently | Section 7.3.2 |		| 301 | Moved Permanently | Section 7.3.2 |
	| 302 | Found | Section 7.3.3 |		| 302 | Found | Section 7.3.3 |
	| 303 | See Other | Section 7.3.4 |		| 303 | See Other | Section 7.3.4 |
	| 304 | Not Modified | Section 4.1 of |		| 304 | Not Modified | Section 4.1 of |
	| | | [Part4] |		| | | [Part4] |
	| 305 | Use Proxy | Section 7.3.6 |		| 305 | Use Proxy | Section 7.3.5 |
	| 307 | Temporary Redirect | Section 7.3.8 |		| 307 | Temporary Redirect | Section 7.3.7 |
	| 400 | Bad Request | Section 7.4.1 |		| 400 | Bad Request | Section 7.4.1 |
	| 401 | Unauthorized | Section 3.1 of |		| 401 | Unauthorized | Section 3.1 of |
	| | | [Part7] |		| | | [Part7] |
	| 402 | Payment Required | Section 7.4.3 |		| 402 | Payment Required | Section 7.4.2 |
	| 403 | Forbidden | Section 7.4.4 |		| 403 | Forbidden | Section 7.4.3 |
	| 404 | Not Found | Section 7.4.5 |		| 404 | Not Found | Section 7.4.4 |
	| 405 | Method Not Allowed | Section 7.4.6 |		| 405 | Method Not Allowed | Section 7.4.5 |
	| 406 | Not Acceptable | Section 7.4.7 |		| 406 | Not Acceptable | Section 7.4.6 |
	| 407 | Proxy Authentication | Section 3.2 of |		| 407 | Proxy Authentication | Section 3.2 of |
	| | Required | [Part7] |		| | Required | [Part7] |
	| 408 | Request Time-out | Section 7.4.9 |		| 408 | Request Time-out | Section 7.4.7 |
	| 409 | Conflict | Section 7.4.10 |		| 409 | Conflict | Section 7.4.8 |
	| 410 | Gone | Section 7.4.11 |		| 410 | Gone | Section 7.4.9 |
	| 411 | Length Required | Section 7.4.12 |		| 411 | Length Required | Section 7.4.10 |
	| 412 | Precondition Failed | Section 4.2 of |		| 412 | Precondition Failed | Section 4.2 of |
	| | | [Part4] |		| | | [Part4] |
	| 413 | Request Representation Too | Section 7.4.14 |		| 413 | Request Representation Too | Section 7.4.11 |
	| | Large | |		| | Large | |
	| 414 | URI Too Long | Section 7.4.15 |		| 414 | URI Too Long | Section 7.4.12 |
	| 415 | Unsupported Media Type | Section 7.4.16 |		| 415 | Unsupported Media Type | Section 7.4.13 |
	| 416 | Requested range not | Section 3.2 of |		| 416 | Requested range not | Section 3.2 of |
	| | satisfiable | [Part5] |		| | satisfiable | [Part5] |
	| 417 | Expectation Failed | Section 7.4.18 |		| 417 | Expectation Failed | Section 7.4.14 |
	| 426 | Upgrade Required | Section 7.4.19 |		| 426 | Upgrade Required | Section 7.4.15 |
	| 500 | Internal Server Error | Section 7.5.1 |		| 500 | Internal Server Error | Section 7.5.1 |
	| 501 | Not Implemented | Section 7.5.2 |		| 501 | Not Implemented | Section 7.5.2 |
	| 502 | Bad Gateway | Section 7.5.3 |		| 502 | Bad Gateway | Section 7.5.3 |
	| 503 | Service Unavailable | Section 7.5.4 |		| 503 | Service Unavailable | Section 7.5.4 |
	| 504 | Gateway Time-out | Section 7.5.5 |		| 504 | Gateway Time-out | Section 7.5.5 |
	| 505 | HTTP Version not supported | Section 7.5.6 |		| 505 | HTTP Version not supported | Section 7.5.6 |
	+-------------+------------------------------+----------------------+		+-------------+------------------------------+----------------------+
	Note that this list is not exhaustive -- it does not include		Note that this list is not exhaustive -- it does not include
	extension status codes defined in other specifications.		extension status codes defined in other specifications.
	skipping to change at page 18, line 33		skipping to change at page 18, line 33
	specification does not define any use for such a body, future		specification does not define any use for such a body, future
	extensions to HTTP might use the OPTIONS body to make more detailed		extensions to HTTP might use the OPTIONS body to make more detailed
	queries on the server.		queries on the server.
	If the request-target is an asterisk ("*"), the OPTIONS request is		If the request-target is an asterisk ("*"), the OPTIONS request is
	intended to apply to the server in general rather than to a specific		intended to apply to the server in general rather than to a specific
	resource. Since a server's communication options typically depend on		resource. Since a server's communication options typically depend on
	the resource, the "*" request is only useful as a "ping" or "no-op"		the resource, the "*" request is only useful as a "ping" or "no-op"
	type of method; it does nothing beyond allowing the client to test		type of method; it does nothing beyond allowing the client to test
	the capabilities of the server. For example, this can be used to		the capabilities of the server. For example, this can be used to
	test a proxy for HTTP/1.1 compliance (or lack thereof).		test a proxy for HTTP/1.1 conformance (or lack thereof).
	If the request-target is not an asterisk, the OPTIONS request applies		If the request-target is not an asterisk, the OPTIONS request applies
	only to the options that are available when communicating with that		only to the options that are available when communicating with that
	resource.		resource.
	A 200 response SHOULD include any header fields that indicate		A 200 response SHOULD include any header fields that indicate
	optional features implemented by the server and applicable to that		optional features implemented by the server and applicable to that
	resource (e.g., Allow), possibly including extensions not defined by		resource (e.g., Allow), possibly including extensions not defined by
	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
	skipping to change at page 26, line 11		skipping to change at page 26, line 11
	o 4xx: Client Error - The request contains bad syntax or cannot be		o 4xx: Client Error - The request contains bad syntax or cannot be
	fulfilled		fulfilled
	o 5xx: Server Error - The server failed to fulfill an apparently		o 5xx: Server Error - The server failed to fulfill an apparently
	valid request		valid request
	Each Status-Code is described below, including any metadata required		Each Status-Code is described below, including any metadata required
	in the response.		in the response.
			For most status codes the response can carry a payload, in which case
			a Content-Type header field indicates the payload's media type
			(Section 6.8 of [Part3]).
	7.1. Informational 1xx		7.1. Informational 1xx
	This class of status code indicates a provisional response,		This class of status code indicates a provisional response,
	consisting only of the Status-Line and optional header fields, and is		consisting only of the Status-Line and optional header fields, and is
	terminated by an empty line. There are no required header fields for		terminated by an empty line. There are no required header fields for
	this class of status code. Since HTTP/1.0 did not define any 1xx		this class of status code. Since HTTP/1.0 did not define any 1xx
	status codes, servers MUST NOT send a 1xx response to an HTTP/1.0		status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
	client except under experimental conditions.		client except under experimental conditions.
	A client MUST be prepared to accept one or more 1xx status responses		A client MUST be prepared to accept one or more 1xx status responses
	skipping to change at page 27, line 39		skipping to change at page 27, line 43
	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to		Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
	determine freshness for 200 responses.		determine freshness for 200 responses.
	7.2.2. 201 Created		7.2.2. 201 Created
	The request has been fulfilled and has resulted in a new resource		The request has been fulfilled and has resulted in a new resource
	being created. The newly created resource can be referenced by the		being created. The newly created resource can be referenced by the
	URI(s) returned in the payload of the response, with the most		URI(s) returned in the payload of the response, with the most
	specific URI for the resource given by a Location header field. The		specific URI for the resource given by a Location header field. The
	response SHOULD include a payload containing a list of resource		response can include a payload containing a list of resource
	characteristics and location(s) from which the user or user agent can		characteristics and location(s) from which the user or user agent can
	choose the one most appropriate. The payload format is specified by		choose the one most appropriate.
	the media type given in the Content-Type header field. The origin
	server MUST create the resource before returning the 201 status code.		The origin server MUST create the resource before returning the 201
	If the action cannot be carried out immediately, the server SHOULD		status code. If the action cannot be carried out immediately, the
	respond with 202 (Accepted) response instead.		server SHOULD respond with 202 (Accepted) response instead.
	A 201 response MAY contain an ETag response header field indicating		A 201 response MAY contain an ETag response header field indicating
	the current value of the entity-tag for the representation of the		the current value of the entity-tag for the representation of the
	resource just created (see Section 2.3 of [Part4]).		resource just created (see Section 2.3 of [Part4]).
	7.2.3. 202 Accepted		7.2.3. 202 Accepted
	The request has been accepted for processing, but the processing has		The request has been accepted for processing, but the processing has
	not been completed. The request might or might not eventually be		not been completed. The request might or might not eventually be
	acted upon, as it might be disallowed when processing actually takes		acted upon, as it might be disallowed when processing actually takes
	skipping to change at page 28, line 25		skipping to change at page 28, line 27
	batch-oriented process that is only run once per day) without		batch-oriented process that is only run once per day) without
	requiring that the user agent's connection to the server persist		requiring that the user agent's connection to the server persist
	until the process is completed. The representation returned with		until the process is completed. The representation returned with
	this response SHOULD include an indication of the request's current		this response SHOULD include an indication of the request's current
	status and either a pointer to a status monitor or some estimate of		status and either a pointer to a status monitor or some estimate of
	when the user can expect the request to be fulfilled.		when the user can expect the request to be fulfilled.
	7.2.4. 203 Non-Authoritative Information		7.2.4. 203 Non-Authoritative Information
	The representation in the response has been transformed or otherwise		The representation in the response has been transformed or otherwise
	modified by a transforming proxy (Section 2.4 of [Part1]). Note that		modified by a transforming proxy (Section 2.3 of [Part1]). Note that
	the behaviour of transforming intermediaries is controlled by the no-		the behavior of transforming intermediaries is controlled by the no-
	transform Cache-Control directive (Section 3.2 of [Part6]).		transform Cache-Control directive (Section 3.2 of [Part6]).
	This status code is only appropriate when the response status code		This status code is only appropriate when the response status code
	would have been 200 (OK) otherwise. When the status code before		would have been 200 (OK) otherwise. When the status code before
	transformation would have been different, the 214 Transformation		transformation would have been different, the 214 Transformation
	Applied warn-code (Section 3.6 of [Part6]) is appropriate.		Applied warn-code (Section 3.6 of [Part6]) is appropriate.
	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to		Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
	determine freshness for 203 responses.		determine freshness for 203 responses.
	skipping to change at page 29, line 30		skipping to change at page 29, line 34
	The server has fulfilled the request and the user agent SHOULD reset		The server has fulfilled the request and the user agent SHOULD reset
	the document view which caused the request to be sent. This response		the document view which caused the request to be sent. This response
	is primarily intended to allow input for actions to take place via		is primarily intended to allow input for actions to take place via
	user input, followed by a clearing of the form in which the input is		user input, followed by a clearing of the form in which the input is
	given so that the user can easily initiate another input action.		given so that the user can easily initiate another input action.
	The message-body included with the response MUST be empty. Note that		The message-body included with the response MUST be empty. Note that
	receivers still need to parse the response according to the algorithm		receivers still need to parse the response according to the algorithm
	defined in Section 3.3 of [Part1].		defined in Section 3.3 of [Part1].
	7.2.7. 206 Partial Content
	The server has fulfilled the partial GET request for the resource and
	the enclosed payload is a partial representation as defined in
	Section 3.1 of [Part5].
	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
	determine freshness for 206 responses.
	7.3. Redirection 3xx		7.3. Redirection 3xx
	This class of status code indicates that further action needs to be		This class of status code indicates that further action needs to be
	taken by the user agent in order to fulfill the request. If the		taken by the user agent in order to fulfill the request. If the
	required action involves a subsequent HTTP request, it MAY be carried		required action involves a subsequent HTTP request, it MAY be carried
	out by the user agent without interaction with the user if and only		out by the user agent without interaction with the user if and only
	if the method used in the second request is known to be "safe", as		if the method used in the second request is known to be "safe", as
	defined in Section 6.1.1.		defined in Section 6.1.1.
	There are several types of redirects:		There are several types of redirects:
	skipping to change at page 30, line 18		skipping to change at page 30, line 12
	2. Redirection to a new location that represents an indirect		2. Redirection to a new location that represents an indirect
	response to the request, such as the result of a POST operation		response to the request, such as the result of a POST operation
	to be retrieved with a subsequent GET request. This is status		to be retrieved with a subsequent GET request. This is status
	code 303 (See Other).		code 303 (See Other).
	3. Redirection offering a choice of matching resources for use by		3. Redirection offering a choice of matching resources for use by
	agent-driven content negotiation (Section 5.2 of [Part3]). This		agent-driven content negotiation (Section 5.2 of [Part3]). This
	is status code 300 (Multiple Choices).		is status code 300 (Multiple Choices).
	4. Other kinds of redirection, such as to a cached result (status		4. Other kinds of redirection, such as to a cached result (status
	code 304 (Not Modified)).		code 304 (Not Modified), see Section 4.1 of [Part4]).
	Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)		Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
	and 302 (Found) were defined for the first type of redirect, and		and 302 (Found) were defined for the first type of redirect, and
	the second type did not exist at all ([RFC1945], Section 9.3).		the second type did not exist at all ([RFC1945], Section 9.3).
	However it turned out that web forms using POST expected redirects		However it turned out that web forms using POST expected redirects
	to change the operation for the subsequent request to retrieval		to change the operation for the subsequent request to retrieval
	(GET). To address this use case, HTTP/1.1 introduced the second		(GET). To address this use case, HTTP/1.1 introduced the second
	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 conformant in case the original
	request was POST.		request was POST.
	A Location header field on a 3xx response indicates that a client MAY		A Location header field on a 3xx response indicates that a client MAY
	automatically redirect to the URI provided; see Section 9.5.		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
	skipping to change at page 31, line 10		skipping to change at page 31, line 4
	The target resource has more than one representation, each with its		The target resource has more than one representation, each with its
	own specific location, and agent-driven negotiation information		own specific location, and agent-driven negotiation information
	(Section 5 of [Part3]) is being provided so that the user (or user		(Section 5 of [Part3]) is being provided so that the user (or user
	agent) can select a preferred representation by redirecting its		agent) can select a preferred representation by redirecting its
	request to that location.		request to that location.
	Unless it was a HEAD request, the response SHOULD include a		Unless it was a HEAD request, the response SHOULD include a
	representation containing a list of representation metadata and		representation containing a list of representation metadata and
	location(s) from which the user or user agent can choose the one most		location(s) from which the user or user agent can choose the one most
	appropriate. The data format is specified by the media type given in		appropriate. Depending upon the format and the capabilities of the
	the Content-Type header field. Depending upon the format and the		user agent, selection of the most appropriate choice MAY be performed
	capabilities of the user agent, selection of the most appropriate		automatically. However, this specification does not define any
	choice MAY be performed automatically. However, this specification		standard for such automatic selection.
	does not define any standard for such automatic selection.
	If the server has a preferred choice of representation, it SHOULD		If the server has a preferred choice of representation, it SHOULD
	include the specific URI for that representation in the Location		include the specific URI for that representation in the Location
	field; user agents MAY use the Location field value for automatic		field; user agents MAY use the Location field value for automatic
	redirection.		redirection.
	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to		Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
	determine freshness for 300 responses.		determine freshness for 300 responses.
	7.3.2. 301 Moved Permanently		7.3.2. 301 Moved Permanently
	skipping to change at page 31, line 36		skipping to change at page 31, line 29
	The target resource has been assigned a new permanent URI and any		The target resource has been assigned a new permanent URI and any
	future references to this resource SHOULD use one of the returned		future references to this resource SHOULD use one of the returned
	URIs. Clients with link editing capabilities ought to automatically		URIs. Clients with link editing capabilities ought to automatically
	re-link references to the effective request URI to one or more of the		re-link references to the effective request URI to one or more of the
	new references returned by the server, where possible.		new references returned by the server, where possible.
	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to		Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
	determine freshness for 301 responses.		determine freshness for 301 responses.
	The new permanent URI SHOULD be given by the Location field in the		The new permanent URI SHOULD be given by the Location field in the
	response. Unless the request method was HEAD, the representation of		response. A response payload can contain a short hypertext note with
	the response SHOULD contain a short hypertext note with a hyperlink		a hyperlink to the new URI(s).
	to the new URI(s).
	If the 301 status code is received in response to a request method		If the 301 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: For historic reasons, user agents MAY change the request		Note: For historic reasons, user agents MAY change the request
	method from POST to GET for the subsequent request. If this		method from POST to GET for the subsequent request. If this
	behavior is undesired, status code 307 (Temporary Redirect) can be		behavior is undesired, status code 307 (Temporary Redirect) can be
	used instead.		used instead.
	7.3.3. 302 Found		7.3.3. 302 Found
	The target resource resides temporarily under a different URI. Since		The target resource resides temporarily under a different URI. Since
	the redirection might be altered on occasion, the client SHOULD		the redirection might be altered on occasion, the client SHOULD
	continue to use the effective request URI for future requests.		continue to use the effective request URI for future requests.
	The temporary URI SHOULD be given by the Location field in the		The temporary URI SHOULD be given by the Location field in the
	response. Unless the request method was HEAD, the representation of		response. A response payload can contain a short hypertext note with
	the response SHOULD contain a short hypertext note with a hyperlink		a hyperlink to the new URI(s).
	to the new URI(s).
	If the 302 status code is received in response to a request method		If the 302 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: For historic reasons, user agents MAY change the request		Note: For historic reasons, user agents MAY change the request
	method from POST to GET for the subsequent request. If this		method from POST to GET for the subsequent request. If this
	behavior is undesired, status code 307 (Temporary Redirect) can be		behavior is undesired, status code 307 (Temporary Redirect) can be
	used instead. [[issue312: but see		used instead.
	<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/312>]]
	7.3.4. 303 See Other		7.3.4. 303 See Other
	The 303 status code indicates that the server is redirecting the user		The 303 status code indicates that the server is redirecting the user
	agent to a different resource, as indicated by a URI in the Location		agent to a different resource, as indicated by a URI in the Location
	header field, that is intended to provide an indirect response to the		header field, that is intended to provide an indirect response to the
	original request. In order to satisfy the original request, a user		original request. In order to satisfy the original request, a user
	agent SHOULD perform a retrieval request using the Location URI (a		agent SHOULD perform a retrieval request using the Location URI (a
	GET or HEAD request if using HTTP), which may itself be redirected		GET or HEAD request if using HTTP), which may itself be redirected
	further, and present the eventual result as an answer to the original		further, and present the eventual result as an answer to the original
	skipping to change at page 33, line 13		skipping to change at page 33, line 5
	representation might be useful to recipients without implying that it		representation might be useful to recipients without implying that it
	adequately represents the target resource. Note that answers to the		adequately represents the target resource. Note that answers to the
	questions of what can be represented, what representations are		questions of what can be represented, what representations are
	adequate, and what might be a useful description are outside the		adequate, and what might be a useful description are outside the
	scope of HTTP and thus entirely determined by the URI owner(s).		scope of HTTP and thus entirely determined by the URI owner(s).
	Except for responses to a HEAD request, the representation of a 303		Except for responses to a HEAD request, the representation of a 303
	response SHOULD contain a short hypertext note with a hyperlink to		response SHOULD contain a short hypertext note with a hyperlink to
	the Location URI.		the Location URI.
	7.3.5. 304 Not Modified		7.3.5. 305 Use Proxy
	The response to the request has not been modified since the
	conditions indicated by the client's conditional GET request, as
	defined in Section 4.1 of [Part4].
	7.3.6. 305 Use Proxy
	The 305 status code was defined in a previous version of this		The 305 status code was defined in a previous version of this
	specification (see Appendix A), and is now deprecated.		specification (see Appendix A), and is now deprecated.
	7.3.7. 306 (Unused)		7.3.6. 306 (Unused)
	The 306 status code was used in a previous version of the		The 306 status code was used in a previous version of the
	specification, is no longer used, and the code is reserved.		specification, is no longer used, and the code is reserved.
	7.3.8. 307 Temporary Redirect		7.3.7. 307 Temporary Redirect
	The target resource resides temporarily under a different URI. Since		The target resource resides temporarily under a different URI. Since
	the redirection can change over time, the client SHOULD continue to		the redirection can change over time, the client SHOULD continue to
	use the effective request URI for future requests.		use the effective request URI for future requests.
	The temporary URI SHOULD be given by the Location field in the		The temporary URI SHOULD be given by the Location field in the
	response. Unless the request method was HEAD, the representation of		response. A response payload can contain a short hypertext note with
	the response SHOULD contain a short hypertext note with a hyperlink		a hyperlink to the new URI(s).
	to the new URI(s), since many pre-HTTP/1.1 user agents do not
	understand the 307 status code. Therefore, the note SHOULD contain
	the information necessary for a user to repeat the original request
	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		Note: This status code is similar to 302 Found, except that it
	does not allow rewriting the request method from POST to GET.		does not allow rewriting the request method from POST to GET.
	skipping to change at page 34, line 34		skipping to change at page 34, line 12
	after the close, the server's TCP stack will send a reset packet to		after the close, the server's TCP stack will send a reset packet to
	the client, which might erase the client's unacknowledged input		the client, which might erase the client's unacknowledged input
	buffers before they can be read and interpreted by the HTTP		buffers before they can be read and interpreted by the HTTP
	application.		application.
	7.4.1. 400 Bad Request		7.4.1. 400 Bad Request
	The server cannot or will not process the request, due to a client		The server cannot or will not process the request, due to a client
	error (e.g., malformed syntax).		error (e.g., malformed syntax).
	7.4.2. 401 Unauthorized		7.4.2. 402 Payment Required
	The request requires user authentication (see Section 3.1 of
	[Part7]).
	7.4.3. 402 Payment Required
	This code is reserved for future use.		This code is reserved for future use.
	7.4.4. 403 Forbidden		7.4.3. 403 Forbidden
	The server understood the request, but refuses to authorize it.		The server understood the request, but refuses to authorize it.
	Providing different user authentication credentials might be		Providing different user authentication credentials might be
	successful, but any credentials that were provided in the request are		successful, but any credentials that were provided in the request are
	insufficient. The request SHOULD NOT be repeated with the same		insufficient. The request SHOULD NOT be repeated with the same
	credentials.		credentials.
	If the request method was not HEAD and the server wishes to make		If the request method was not HEAD and the server wishes to make
	public why the request has not been fulfilled, it SHOULD describe the		public why the request has not been fulfilled, it SHOULD describe the
	reason for the refusal in the representation. If the server does not		reason for the refusal in the representation. If the server does not
	wish to make this information available to the client, the status		wish to make this information available to the client, the status
	code 404 (Not Found) MAY be used instead.		code 404 (Not Found) MAY be used instead.
	7.4.5. 404 Not Found		7.4.4. 404 Not Found
	The server has not found anything matching the effective request URI.		The server has not found anything matching the effective request URI.
	No indication is given of whether the condition is temporary or		No indication is given of whether the condition is temporary or
	permanent. The 410 (Gone) status code SHOULD be used if the server		permanent. The 410 (Gone) status code SHOULD be used if the server
	knows, through some internally configurable mechanism, that an old		knows, through some internally configurable mechanism, that an old
	resource is permanently unavailable and has no forwarding address.		resource is permanently unavailable and has no forwarding address.
	This status code is commonly used when the server does not wish to		This status code is commonly used when the server does not wish to
	reveal exactly why the request has been refused, or when no other		reveal exactly why the request has been refused, or when no other
	response is applicable.		response is applicable.
	7.4.6. 405 Method Not Allowed		7.4.5. 405 Method Not Allowed
	The method specified in the Request-Line is not allowed for the		The method specified in the Request-Line is not allowed for the
	target resource. The response MUST include an Allow header field		target resource. The response MUST include an Allow header field
	containing a list of valid methods for the requested resource.		containing a list of valid methods for the requested resource.
	7.4.7. 406 Not Acceptable		7.4.6. 406 Not Acceptable
	The resource identified by the request is only capable of generating		The resource identified by the request is only capable of generating
	response representations which have content characteristics not		response representations which have content characteristics not
	acceptable according to the Accept and Accept-* header fields sent in		acceptable according to the Accept and Accept-* header fields sent in
	the request (see Section 6 of [Part3]).		the request (see Section 6 of [Part3]).
	Unless it was a HEAD request, the response SHOULD include a		Unless it was a HEAD request, the response SHOULD include a
	representation containing a list of available representation		representation containing a list of available representation
	characteristics and location(s) from which the user or user agent can		characteristics and location(s) from which the user or user agent can
	choose the one most appropriate. The data format is specified by the		choose the one most appropriate. Depending upon the format and the
	media type given in the Content-Type header field. Depending upon		capabilities of the user agent, selection of the most appropriate
	the format and the capabilities of the user agent, selection of the		choice MAY be performed automatically. However, this specification
	most appropriate choice MAY be performed automatically. However,		does not define any standard for such automatic selection.
	this specification does not define any standard for such automatic
	selection.
	Note: HTTP/1.1 servers are allowed to return responses which are		Note: HTTP/1.1 servers are allowed to return responses which are
	not acceptable according to the accept header fields sent in the		not acceptable according to the accept header fields sent in the
	request. In some cases, this might even be preferable to sending		request. In some cases, this might even be preferable to sending
	a 406 response. User agents are encouraged to inspect the header		a 406 response. User agents are encouraged to inspect the header
	fields of an incoming response to determine if it is acceptable.		fields of an incoming response to determine if it is acceptable.
	If the response could be unacceptable, a user agent SHOULD		If the response could be unacceptable, a user agent SHOULD
	temporarily stop receipt of more data and query the user for a		temporarily stop receipt of more data and query the user for a
	decision on further actions.		decision on further actions.
	7.4.8. 407 Proxy Authentication Required		7.4.7. 408 Request Timeout
	This code is similar to 401 (Unauthorized), but indicates that the
	client must first authenticate itself with the proxy (see Section 3.2
	of [Part7]).
	7.4.9. 408 Request Timeout
	The client did not produce a request within the time that the server		The client did not produce a request within the time that the server
	was prepared to wait. The client MAY repeat the request without		was prepared to wait. The client MAY repeat the request without
	modifications at any later time.		modifications at any later time.
	7.4.10. 409 Conflict		7.4.8. 409 Conflict
	The request could not be completed due to a conflict with the current		The request could not be completed due to a conflict with the current
	state of the resource. This code is only allowed in situations where		state of the resource. This code is only allowed in situations where
	it is expected that the user might be able to resolve the conflict		it is expected that the user might be able to resolve the conflict
	and resubmit the request. The response body SHOULD include enough		and resubmit the request. The response body SHOULD include enough
	information for the user to recognize the source of the conflict.		information for the user to recognize the source of the conflict.
	Ideally, the response representation would include enough information		Ideally, the response representation would include enough information
	for the user or user agent to fix the problem; however, that might		for the user or user agent to fix the problem; however, that might
	not be possible and is not required.		not be possible and is not required.
	Conflicts are most likely to occur in response to a PUT request. For		Conflicts are most likely to occur in response to a PUT request. For
	example, if versioning were being used and the representation being		example, if versioning were being used and the representation being
	PUT included changes to a resource which conflict with those made by		PUT included changes to a resource which conflict with those made by
	an earlier (third-party) request, the server might use the 409		an earlier (third-party) request, the server might use the 409
	response to indicate that it can't complete the request. In this		response to indicate that it can't complete the request. In this
	case, the response representation would likely contain a list of the		case, the response representation would likely contain a list of the
	differences between the two versions in a format defined by the		differences between the two versions.
	response Content-Type.
	7.4.11. 410 Gone		7.4.9. 410 Gone
	The target resource is no longer available at the server and no		The target resource is no longer available at the server and no
	forwarding address is known. This condition is expected to be		forwarding address is known. This condition is expected to be
	considered permanent. Clients with link editing capabilities SHOULD		considered permanent. Clients with link editing capabilities SHOULD
	delete references to the effective request URI after user approval.		delete references to the effective request URI after user approval.
	If the server does not know, or has no facility to determine, whether		If the server does not know, or has no facility to determine, whether
	or not the condition is permanent, the status code 404 (Not Found)		or not the condition is permanent, the status code 404 (Not Found)
	SHOULD be used instead.		SHOULD be used instead.
	The 410 response is primarily intended to assist the task of web		The 410 response is primarily intended to assist the task of web
	skipping to change at page 37, line 11		skipping to change at page 36, line 28
	remote links to that resource be removed. Such an event is common		remote links to that resource be removed. Such an event is common
	for limited-time, promotional services and for resources belonging to		for limited-time, promotional services and for resources belonging to
	individuals no longer working at the server's site. It is not		individuals no longer working at the server's site. It is not
	necessary to mark all permanently unavailable resources as "gone" or		necessary to mark all permanently unavailable resources as "gone" or
	to keep the mark for any length of time -- that is left to the		to keep the mark for any length of time -- that is left to the
	discretion of the server owner.		discretion of the server owner.
	Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to		Caches MAY use a heuristic (see Section 2.3.1.1 of [Part6]) to
	determine freshness for 410 responses.		determine freshness for 410 responses.
	7.4.12. 411 Length Required		7.4.10. 411 Length Required
	The server refuses to accept the request without a defined Content-		The server refuses to accept the request without a defined Content-
	Length. The client MAY repeat the request if it adds a valid		Length. The client MAY repeat the request if it adds a valid
	Content-Length header field containing the length of the message-body		Content-Length header field containing the length of the message-body
	in the request message.		in the request message.
	7.4.13. 412 Precondition Failed		7.4.11. 413 Request Representation Too Large
	The precondition given in one or more of the header fields evaluated
	to false when it was tested on the server, as defined in Section 4.2
	of [Part4].
	7.4.14. 413 Request Representation Too Large
	The server is refusing to process a request because the request		The server is refusing to process a request because the request
	representation is larger than the server is willing or able to		representation is larger than the server is willing or able to
	process. The server MAY close the connection to prevent the client		process. The server MAY close the connection to prevent the client
	from continuing the request.		from continuing the request.
	If the condition is temporary, the server SHOULD include a Retry-		If the condition is temporary, the server SHOULD include a Retry-
	After header field to indicate that it is temporary and after what		After header field to indicate that it is temporary and after what
	time the client MAY try again.		time the client MAY try again.
	7.4.15. 414 URI Too Long		7.4.12. 414 URI Too Long
	The server is refusing to service the request because the effective		The server is refusing to service the request because the effective
	request URI is longer than the server is willing to interpret. This		request URI is longer than the server is willing to interpret. This
	rare condition is only likely to occur when a client has improperly		rare condition is only likely to occur when a client has improperly
	converted a POST request to a GET request with long query		converted a POST request to a GET request with long query
	information, when the client has descended into a URI "black hole" of		information, when the client has descended into a URI "black hole" of
	redirection (e.g., a redirected URI prefix that points to a suffix of		redirection (e.g., a redirected URI prefix that points to a suffix of
	itself), or when the server is under attack by a client attempting to		itself), or when the server is under attack by a client attempting to
	exploit security holes present in some servers using fixed-length		exploit security holes present in some servers using fixed-length
	buffers for reading or manipulating the effective request URI.		buffers for reading or manipulating the effective request URI.
	7.4.16. 415 Unsupported Media Type		7.4.13. 415 Unsupported Media Type
	The server is refusing to service the request because the request		The server is refusing to service the request because the request
	payload is in a format not supported by this request method on the		payload is in a format not supported by this request method on the
	target resource.		target resource.
	7.4.17. 416 Requested Range Not Satisfiable		7.4.14. 417 Expectation Failed
	The request included a Range header field (Section 5.4 of [Part5])
	and none of the range-specifier values in this field overlap the
	current extent of the selected resource. See Section 3.2 of [Part5].
	7.4.18. 417 Expectation Failed
	The expectation given in an Expect header field (see Section 9.3)		The expectation given in an Expect header field (see Section 9.3)
	could not be met by this server, or, if the server is a proxy, the		could not be met by this server, or, if the server is a proxy, the
	server has unambiguous evidence that the request could not be met by		server has unambiguous evidence that the request could not be met by
	the next-hop server.		the next-hop server.
	7.4.19. 426 Upgrade Required		7.4.15. 426 Upgrade Required
	The request can not be completed without a prior protocol upgrade.		The request can not be completed without a prior protocol upgrade.
	This response MUST include an Upgrade header field (Section 8.7 of		This response MUST include an Upgrade header field (Section 8.7 of
	[Part1]) specifying the required protocols.		[Part1]) specifying the required protocols.
	Example:		Example:
	HTTP/1.1 426 Upgrade Required		HTTP/1.1 426 Upgrade Required
	Upgrade: HTTP/2.0		Upgrade: HTTP/3.0
	Connection: Upgrade		Connection: Upgrade
			Content-Length: 53
			Content-Type: text/plain
			This service requires use of the HTTP/3.0 protocol.
	The server SHOULD include a message body in the 426 response which		The server SHOULD include a message body in the 426 response which
	indicates in human readable form the reason for the error and		indicates in human readable form the reason for the error and
	describes any alternative courses which may be available to the user.		describes any alternative courses which may be available to the user.
	7.5. Server Error 5xx		7.5. Server Error 5xx
	Response status codes beginning with the digit "5" indicate cases in		Response status codes beginning with the digit "5" indicate cases in
	which the server is aware that it has erred or is incapable of		which the server is aware that it has erred or is incapable of
	performing the request. Except when responding to a HEAD request,		performing the request. Except when responding to a HEAD request,
	skipping to change at page 43, line 44		skipping to change at page 42, line 44
	3. If the server does not have a clock that can provide a reasonable		3. If the server does not have a clock that can provide a reasonable
	approximation of the current time, its responses MUST NOT include		approximation of the current time, its responses MUST NOT include
	a Date header field.		a Date header field.
	A received message that does not have a Date header field MUST be		A received message that does not have a Date header field MUST be
	assigned one by the recipient if the message will be cached by that		assigned one by the recipient if the message will be cached by that
	recipient.		recipient.
	Clients can use the Date header field as well; in order to keep		Clients can use the Date header field as well; in order to keep
	request messages small, they are advised not to include it when it		request messages small, they are advised not to include it when it
	doesn't convey any useful information (as it is usually the case for		doesn't convey any useful information (as is usually the case for
	requests that do not contain a payload).		requests that do not contain a payload).
	The HTTP-date sent in a Date header field SHOULD NOT represent a date		The HTTP-date sent in a Date header field SHOULD NOT represent a date
	and time subsequent to the generation of the message. It SHOULD		and time subsequent to the generation of the message. It SHOULD
	represent the best available approximation of the date and time of		represent the best available approximation of the date and time of
	message generation, unless the implementation has no means of		message generation, unless the implementation has no means of
	generating a reasonably accurate date and time. In theory, the date		generating a reasonably accurate date and time. In theory, the date
	ought to represent the moment just before the payload is generated.		ought to represent the moment just before the payload is generated.
	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
	skipping to change at page 46, line 39		skipping to change at page 45, line 39
	most specific resource corresponding to the enclosed		most specific resource corresponding to the enclosed
	representation. It is therefore possible for a response to		representation. It is therefore possible for a response to
	contain header fields for both Location and Content-Location.		contain header fields for both Location and Content-Location.
	9.6. Max-Forwards		9.6. Max-Forwards
	The "Max-Forwards" header field provides a mechanism with the TRACE		The "Max-Forwards" header field provides a mechanism with the TRACE
	(Section 6.8) and OPTIONS (Section 6.2) methods to limit the number		(Section 6.8) and OPTIONS (Section 6.2) methods to limit the number
	of times that the request is forwarded by proxies. This can be		of times that the request is forwarded by proxies. This can be
	useful when the client is attempting to trace a request which appears		useful when the client is attempting to trace a request which appears
	to be failing or looping in mid-chain.		to be failing or looping mid-chain.
	Max-Forwards = 1*DIGIT		Max-Forwards = 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 can be forwarded.		number of times this request message can be forwarded.
	Each recipient of a TRACE or OPTIONS request containing a Max-		Each recipient of a TRACE or OPTIONS request containing a Max-
	Forwards header field MUST check and update its value prior to		Forwards header field MUST check and update its value prior to
	forwarding the request. If the received value is zero (0), the		forwarding the request. If the received value is zero (0), the
	recipient MUST NOT forward the request; instead, it MUST respond as		recipient MUST NOT forward the request; instead, it MUST respond as
	skipping to change at page 47, line 43		skipping to change at page 46, line 43
	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 effective request URI. The URI MUST NOT include a		relative to the effective request URI. The URI MUST NOT include a
	fragment. See Section 11.2 for security considerations.		fragment. See Section 11.2 for security considerations.
	9.8. Retry-After		9.8. Retry-After
	The header "Retry-After" field can be used with a 503 (Service		The header "Retry-After" field can be used with a 503 (Service
	Unavailable) response to indicate how long the service is expected to		Unavailable) response to indicate how long the service is expected to
	be unavailable to the requesting client. This field MAY also be used		be unavailable to the requesting client. This field MAY also be used
	with any 3xx (Redirection) response to indicate the minimum time the		with any 3xx (Redirection) response to indicate the minimum time the
	user-agent is asked wait before issuing the redirected request.		user-agent is asked to wait before issuing the redirected request.
	The value of this field can be either an HTTP-date or an integer		The value of this field can be either an HTTP-date or an integer
	number of seconds (in decimal) after the time of the response.		number of seconds (in decimal) after the time of the response.
	Retry-After = HTTP-date / delta-seconds		Retry-After = 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
	skipping to change at page 51, line 20		skipping to change at page 50, line 20
	| 200 | OK | Section 7.2.1 |		| 200 | OK | Section 7.2.1 |
	| 201 | Created | Section 7.2.2 |		| 201 | Created | Section 7.2.2 |
	| 202 | Accepted | Section 7.2.3 |		| 202 | Accepted | Section 7.2.3 |
	| 203 | Non-Authoritative Information | Section 7.2.4 |		| 203 | Non-Authoritative Information | Section 7.2.4 |
	| 204 | No Content | Section 7.2.5 |		| 204 | No Content | Section 7.2.5 |
	| 205 | Reset Content | Section 7.2.6 |		| 205 | Reset Content | Section 7.2.6 |
	| 300 | Multiple Choices | Section 7.3.1 |		| 300 | Multiple Choices | Section 7.3.1 |
	| 301 | Moved Permanently | Section 7.3.2 |		| 301 | Moved Permanently | Section 7.3.2 |
	| 302 | Found | Section 7.3.3 |		| 302 | Found | Section 7.3.3 |
	| 303 | See Other | Section 7.3.4 |		| 303 | See Other | Section 7.3.4 |
	| 305 | Use Proxy | Section 7.3.6 |		| 305 | Use Proxy | Section 7.3.5 |
	| 306 | (Unused) | Section 7.3.7 |		| 306 | (Unused) | Section 7.3.6 |
	| 307 | Temporary Redirect | Section 7.3.8 |		| 307 | Temporary Redirect | Section 7.3.7 |
	| 400 | Bad Request | Section 7.4.1 |		| 400 | Bad Request | Section 7.4.1 |
	| 402 | Payment Required | Section 7.4.3 |		| 402 | Payment Required | Section 7.4.2 |
	| 403 | Forbidden | Section 7.4.4 |		| 403 | Forbidden | Section 7.4.3 |
	| 404 | Not Found | Section 7.4.5 |		| 404 | Not Found | Section 7.4.4 |
	| 405 | Method Not Allowed | Section 7.4.6 |		| 405 | Method Not Allowed | Section 7.4.5 |
	| 406 | Not Acceptable | Section 7.4.7 |		| 406 | Not Acceptable | Section 7.4.6 |
	| 407 | Proxy Authentication Required | Section 7.4.8 |		| 408 | Request Timeout | Section 7.4.7 |
	| 408 | Request Timeout | Section 7.4.9 |		| 409 | Conflict | Section 7.4.8 |
	| 409 | Conflict | Section 7.4.10 |		| 410 | Gone | Section 7.4.9 |
	| 410 | Gone | Section 7.4.11 |		| 411 | Length Required | Section 7.4.10 |
	| 411 | Length Required | Section 7.4.12 |		| 413 | Request Representation Too Large | Section 7.4.11 |
	| 413 | Request Representation Too Large | Section 7.4.14 |		| 414 | URI Too Long | Section 7.4.12 |
	| 414 | URI Too Long | Section 7.4.15 |		| 415 | Unsupported Media Type | Section 7.4.13 |
	| 415 | Unsupported Media Type | Section 7.4.16 |		| 417 | Expectation Failed | Section 7.4.14 |
	| 417 | Expectation Failed | Section 7.4.18 |		| 426 | Upgrade Required | Section 7.4.15 |
	| 426 | Upgrade Required | Section 7.4.19 |
	| 500 | Internal Server Error | Section 7.5.1 |		| 500 | Internal Server Error | Section 7.5.1 |
	| 501 | Not Implemented | Section 7.5.2 |		| 501 | Not Implemented | Section 7.5.2 |
	| 502 | Bad Gateway | Section 7.5.3 |		| 502 | Bad Gateway | Section 7.5.3 |
	| 503 | Service Unavailable | Section 7.5.4 |		| 503 | Service Unavailable | Section 7.5.4 |
	| 504 | Gateway Timeout | Section 7.5.5 |		| 504 | Gateway Timeout | Section 7.5.5 |
	| 505 | HTTP Version Not Supported | Section 7.5.6 |		| 505 | HTTP Version Not Supported | Section 7.5.6 |
	+-------+----------------------------------+----------------+		+-------+----------------------------------+----------------+
	10.3. Header Field Registration		10.3. Header Field Registration
	skipping to change at page 53, line 23		skipping to change at page 52, line 23
	enable, and modify the contents of the field. The user MUST be able		enable, and modify the contents of the field. The user MUST be able
	to set the contents of this field within a user preference or		to set the contents of this field within a user preference or
	application defaults configuration.		application defaults configuration.
	We suggest, though do not require, that a convenient toggle interface		We suggest, though do not require, that a convenient toggle interface
	be provided for the user to enable or disable the sending of From and		be provided for the user to enable or disable the sending of From and
	Referer information.		Referer information.
	The User-Agent (Section 9.10) or Server (Section 9.9) header fields		The User-Agent (Section 9.10) or Server (Section 9.9) header fields
	can sometimes be used to determine that a specific client or server		can sometimes be used to determine that a specific client or server
	have a particular security hole which might be exploited.		has a particular security hole which might be exploited.
	Unfortunately, this same information is often used for other valuable		Unfortunately, this same information is often used for other valuable
	purposes for which HTTP currently has no better mechanism.		purposes for which HTTP currently has no better mechanism.
	Furthermore, the User-Agent header field may contain enough entropy		Furthermore, the User-Agent header field may contain enough entropy
	to be used, possibly in conjunction with other material, to uniquely		to be used, possibly in conjunction with other material, to uniquely
	identify the user.		identify the user.
	Some request methods, like TRACE (Section 6.8), expose information		Some request methods, like TRACE (Section 6.8), expose information
	that was sent in request header fields within the body of their		that was sent in request header fields within the body of their
	response. Clients SHOULD be careful with sensitive information, like		response. Clients SHOULD be careful with sensitive information, like
	skipping to change at page 54, line 37		skipping to change at page 53, 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-18		and Message Parsing",
	(work in progress), January 2012.		draft-ietf-httpbis-p1-messaging-latest (work in progress),
			February 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-18		and Content Negotiation",
	(work in progress), January 2012.		draft-ietf-httpbis-p3-payload-latest (work in progress),
			February 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-18 (work in		Requests", draft-ietf-httpbis-p4-conditional-latest (work
	progress), January 2012.		in progress), February 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-18 (work		Partial Responses", draft-ietf-httpbis-p5-range-latest
	in progress), January 2012.		(work in progress), February 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-18 (work in		6: Caching", draft-ietf-httpbis-p6-cache-latest (work in
	progress), January 2012.		progress), February 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-18 (work in progress),		draft-ietf-httpbis-p7-auth-latest (work in progress),
	January 2012.		February 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 36		skipping to change at page 55, line 38
	Clarify definition of POST. (Section 6.5)		Clarify definition of POST. (Section 6.5)
	Remove requirement to handle all Content-* header fields; ban use of		Remove requirement to handle all Content-* header fields; ban use of
	Content-Range with PUT. (Section 6.6)		Content-Range with PUT. (Section 6.6)
	Take over definition of CONNECT method from [RFC2817]. (Section 6.9)		Take over definition of CONNECT method from [RFC2817]. (Section 6.9)
	Broadened the definition of 203 (Non-Authoritative Information) to		Broadened the definition of 203 (Non-Authoritative Information) to
	include cases of payload transformations as well. (Section 7.2.4)		include cases of payload transformations as well. (Section 7.2.4)
			Removed the normative requirements on response payloads for status
			codes 301, 302, and 307. (Section 7.3)
	Failed to consider that there are many other request methods that are		Failed to consider that there are many other request methods that are
	safe to automatically redirect, and further that the user agent is		safe to automatically redirect, and further that the user agent is
	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.7)
	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.5)
	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.15)
	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		The ABNF for the Expect header field has been both fixed (allowing
	parameters for value-less expectations as well) and simplified		parameters for value-less expectations as well) and simplified
	skipping to change at page 57, line 37		skipping to change at page 56, line 40
	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>		BWS = <BWS, defined in [Part1], Section 3.2.1>
	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 48		skipping to change at page 57, line 4
	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
	Location = URI-reference		Location = URI-reference
	Max-Forwards = 1*DIGIT		Max-Forwards = 1*DIGIT
	Method = token		Method = token
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	RWS = <RWS, defined in [Part1], Section 1.2.2>		RWS = <RWS, defined in [Part1], Section 3.2.1>
	Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )		Reason-Phrase = *( HTAB / SP / VCHAR / obs-text )
	Referer = absolute-URI / partial-URI		Referer = absolute-URI / partial-URI
	Retry-After = HTTP-date / delta-seconds		Retry-After = HTTP-date / delta-seconds
	Server = product *( RWS ( product / comment ) )		Server = product *( RWS ( product / comment ) )
	Status-Code = 3DIGIT		Status-Code = 3DIGIT
	URI-reference = <URI-reference, defined in [Part1], Section 2.7>		URI-reference = <URI-reference, defined in [Part1], Section 2.7>
	User-Agent = product *( RWS ( product / comment ) )		User-Agent = product *( RWS ( product / comment ) )
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
	asctime-date = day-name SP date3 SP time-of-day SP year		asctime-date = day-name SP date3 SP time-of-day SP year
	comment = <comment, defined in [Part1], Section 3.2>		comment = <comment, defined in [Part1], Section 3.2.4>
	date1 = day SP month SP year		date1 = day SP month SP year
	date2 = day "-" month "-" 2DIGIT		date2 = day "-" month "-" 2DIGIT
	date3 = month SP ( 2DIGIT / ( SP DIGIT ) )		date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
	day = 2DIGIT		day = 2DIGIT
	day-name = %x4D.6F.6E ; Mon		day-name = %x4D.6F.6E ; Mon
	/ %x54.75.65 ; Tue		/ %x54.75.65 ; Tue
	/ %x57.65.64 ; Wed		/ %x57.65.64 ; Wed
	/ %x54.68.75 ; Thu		/ %x54.68.75 ; Thu
	/ %x46.72.69 ; Fri		/ %x46.72.69 ; Fri
	skipping to change at page 59, line 20		skipping to change at page 58, line 23
	/ %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
	/ %x53.65.70 ; Sep		/ %x53.65.70 ; Sep
	/ %x4F.63.74 ; Oct		/ %x4F.63.74 ; Oct
	/ %x4E.6F.76 ; Nov		/ %x4E.6F.76 ; Nov
	/ %x44.65.63 ; Dec		/ %x44.65.63 ; Dec
	obs-date = rfc850-date / asctime-date		obs-date = rfc850-date / asctime-date
	obs-text = <obs-text, defined in [Part1], Section 1.2.2>		obs-text = <obs-text, defined in [Part1], Section 3.2.4>
	partial-URI = <partial-URI, defined in [Part1], Section 2.7>		partial-URI = <partial-URI, defined in [Part1], Section 2.7>
	product = <product, defined in [Part1], Section 5.2>		product = <product, defined in [Part1], Section 5.2>
	quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
	rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT		rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
	rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT		rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
	second = 2DIGIT		second = 2DIGIT
	time-of-day = hour ":" minute ":" second		time-of-day = hour ":" minute ":" second
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.4>
	year = 4DIGIT		year = 4DIGIT
	ABNF diagnostics:		ABNF diagnostics:
	; Allow defined but not used		; Allow defined but not used
	; Date defined but not used		; Date defined but not used
	; Expect defined but not used		; Expect defined but not used
	; From defined but not used		; From defined but not used
	; Location defined but not used		; Location defined but not used
	; Max-Forwards defined but not used		; Max-Forwards defined but not used
	; Reason-Phrase defined but not used		; Reason-Phrase defined but not used
	; Referer defined but not used		; Referer defined but not used
	skipping to change at page 68, line 21		skipping to change at page 67, line 31
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are		o <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are
	Location's semantics triggered?"		Location's semantics triggered?"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect'		o <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect'
	grammar missing OWS"		grammar missing OWS"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field		o <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field
	considerations: quoted-string vs use of double quotes"		considerations: quoted-string vs use of double quotes"
			C.20. Since draft-ietf-httpbis-p2-semantics-18
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/332>: "relax
			requirements on hypertext in 3/4/5xx error responses"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/333>: "example for
			426 response should have a payload"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/336>: "drop
			indirection entries for status codes"
	Index		Index
	1		1
	100 Continue (status code) 26		100 Continue (status code) 26
	100-continue (expect value) 44		100-continue (expect value) 43
	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
	3		3
	300 Multiple Choices (status code) 30		300 Multiple Choices (status code) 30
	301 Moved Permanently (status code) 31		301 Moved Permanently (status code) 31
	302 Found (status code) 32		302 Found (status code) 31
	303 See Other (status code) 32		303 See Other (status code) 32
	304 Not Modified (status code) 33
	305 Use Proxy (status code) 33		305 Use Proxy (status code) 33
	306 (Unused) (status code) 33		306 (Unused) (status code) 33
	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
	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) 34
	405 Method Not Allowed (status code) 35		405 Method Not Allowed (status code) 34
	406 Not Acceptable (status code) 35		406 Not Acceptable (status code) 34
	407 Proxy Authentication Required (status code) 36		408 Request Timeout (status code) 35
	408 Request Timeout (status code) 36		409 Conflict (status code) 35
	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) 36
	412 Precondition Failed (status code) 37		413 Request Representation Too Large (status code) 36
	413 Request Representation Too Large (status code) 37		414 URI Too Long (status code) 36
	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		417 Expectation Failed (status code) 37
	417 Expectation Failed (status code) 38		426 Upgrade Required (status code) 37
	426 Upgrade Required (status code) 38
	5		5
	500 Internal Server Error (status code) 38		500 Internal Server Error (status code) 38
	501 Not Implemented (status code) 39		501 Not Implemented (status code) 38
	502 Bad Gateway (status code) 39		502 Bad Gateway (status code) 38
	503 Service Unavailable (status code) 39		503 Service Unavailable (status code) 38
	504 Gateway Timeout (status code) 39		504 Gateway Timeout (status code) 38
	505 HTTP Version Not Supported (status code) 39		505 HTTP Version Not Supported (status code) 38
	A		A
	Allow header field 42		Allow header field 41
	C		C
	CONNECT method 24		CONNECT method 24
	D		D
	Date header field 43		Date header field 42
	DELETE method 23		DELETE method 23
	E		E
	Expect header field 44		Expect header field 43
	Expect Values		Expect Values
	100-continue 44		100-continue 43
	F		F
	From header field 44		From header field 43
	G		G
	GET method 19		GET method 19
	Grammar		Grammar
	Allow 42		Allow 41
	asctime-date 42		asctime-date 41
	Date 43		Date 42
	date1 41		date1 40
	day 41		day 40
	day-name 41		day-name 40
	day-name-l 41		day-name-l 40
	delta-seconds 47		delta-seconds 46
	Expect 44		Expect 43
	expect-name 44		expect-name 43
	expect-param 44		expect-param 43
	expect-value 44		expect-value 43
	expectation 44		expectation 43
	extension-code 13		extension-code 13
	From 45		From 44
	GMT 41		GMT 40
	hour 41		hour 40
	HTTP-date 40		HTTP-date 39
	Location 45		Location 44
	Max-Forwards 46		Max-Forwards 45
	Method 7		Method 7
	minute 41		minute 40
	month 41		month 40
	obs-date 41		obs-date 40
	Reason-Phrase 13		Reason-Phrase 13
	Referer 47		Referer 46
	Retry-After 47		Retry-After 46
	rfc850-date 42		rfc850-date 41
	rfc1123-date 41		rfc1123-date 40
	second 41		second 40
	Server 48		Server 47
	Status-Code 13		Status-Code 13
	time-of-day 41		time-of-day 40
	User-Agent 49		User-Agent 48
	year 41		year 40
	H		H
	HEAD method 19		HEAD method 19
	Header Fields		Header Fields
	Allow 42		Allow 41
	Date 43		Date 42
	Expect 44		Expect 43
	From 44		From 43
	Location 45		Location 44
	Max-Forwards 46		Max-Forwards 45
	Referer 47		Referer 46
	Retry-After 47		Retry-After 46
	Server 48		Server 47
	User-Agent 48		User-Agent 47
	I		I
	Idempotent Methods 17		Idempotent Methods 17
	L		L
	Location header field 45		Location header field 44
	M		M
	Max-Forwards header field 46		Max-Forwards header field 45
	Methods		Methods
	CONNECT 24		CONNECT 24
	DELETE 23		DELETE 23
	GET 19		GET 19
	HEAD 19		HEAD 19
	OPTIONS 18		OPTIONS 18
	POST 20		POST 20
	PUT 21		PUT 21
	TRACE 23		TRACE 23
	O		O
	OPTIONS method 18		OPTIONS method 18
	P		P
	POST method 20		POST method 20
	PUT method 21		PUT method 21
	R		R
	Referer header field 47		Referer header field 46
	Retry-After header field 47		Retry-After header field 46
	S		S
	Safe Methods 17		Safe Methods 17
	Server header field 48		Server header field 47
	Status Codes		Status Codes
	100 Continue 26		100 Continue 26
	101 Switching Protocols 26		101 Switching Protocols 26
	200 OK 27		200 OK 27
	201 Created 27		201 Created 27
	202 Accepted 28		202 Accepted 28
	203 Non-Authoritative Information 28		203 Non-Authoritative Information 28
	204 No Content 28		204 No Content 28
	205 Reset Content 29		205 Reset Content 29
	206 Partial Content 29
	300 Multiple Choices 30		300 Multiple Choices 30
	301 Moved Permanently 31		301 Moved Permanently 31
	302 Found 32		302 Found 31
	303 See Other 32		303 See Other 32
	304 Not Modified 33
	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
	402 Payment Required 34		402 Payment Required 34
	403 Forbidden 34		403 Forbidden 34
	404 Not Found 35		404 Not Found 34
	405 Method Not Allowed 35		405 Method Not Allowed 34
	406 Not Acceptable 35		406 Not Acceptable 34
	407 Proxy Authentication Required 36		408 Request Timeout 35
	408 Request Timeout 36		409 Conflict 35
	409 Conflict 36
	410 Gone 36		410 Gone 36
	411 Length Required 37		411 Length Required 36
	412 Precondition Failed 37		413 Request Representation Too Large 36
	413 Request Representation Too Large 37		414 URI Too Long 36
	414 URI Too Long 37
	415 Unsupported Media Type 37		415 Unsupported Media Type 37
	416 Requested Range Not Satisfiable 38		417 Expectation Failed 37
	417 Expectation Failed 38		426 Upgrade Required 37
	426 Upgrade Required 38
	500 Internal Server Error 38		500 Internal Server Error 38
	501 Not Implemented 39		501 Not Implemented 38
	502 Bad Gateway 39		502 Bad Gateway 38
	503 Service Unavailable 39		503 Service Unavailable 38
	504 Gateway Timeout 39		504 Gateway Timeout 38
	505 HTTP Version Not Supported 39		505 HTTP Version Not Supported 38
	T		T
	TRACE method 23		TRACE method 23
	U		U
	User-Agent header field 48		User-Agent header field 47
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
End of changes. 119 change blocks.
	347 lines changed or deleted		304 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/