draft-ietf-httpbis-p2-semantics-13.txt		draft-ietf-httpbis-p2-semantics-14.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: September 15, 2011 HP		Expires: October 20, 2011 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
	March 14, 2011		April 18, 2011
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-13		draft-ietf-httpbis-p2-semantics-14
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 2 of the		information initiative since 1990. This document is Part 2 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
	the semantics of HTTP messages as expressed by request methods,		the semantics of HTTP messages as expressed by request methods,
	request header fields, response status codes, and response header		request header fields, response status codes, and response header
	fields.		fields.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org), which is archived at
	at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
			The current issues list is at
			<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.14.		The changes in this draft are summarized in Appendix C.15.
	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
	skipping to change at page 2, line 17		skipping to change at page 2, line 20
	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 September 15, 2011.		This Internet-Draft will expire on October 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 32		skipping to change at page 3, line 34
	7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 15		7.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 15
	7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15		7.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		7.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		7.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		7.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 20		7.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21		7.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21		7.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22		7.9.1. Establishing a Tunnel with CONNECT . . . . . . . . . . 22
	8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 22		8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 23
	8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 22		8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 23
	8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23		8.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 23
	8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23		8.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 23
	8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 23		8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 24
	8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 23		8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 24
	8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24		8.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 24
	8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 24		8.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 25
	8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25		8.2.4. 203 Non-Authoritative Information . . . . . . . . . . 25
	8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25		8.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 25
	8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 25		8.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 26
	8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26		8.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 26
	8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26		8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 26
	8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 26		8.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 27
	8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27		8.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 27
	8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 27		8.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 28
	8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28		8.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 28
	8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 28		8.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 29
	8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29		8.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 29
	8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29		8.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 29
	8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29		8.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 29
	8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 29		8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 30
	8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30		8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 30
	8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30		8.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 30
	8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30		8.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 30
	8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30		8.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 30
	8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 30		8.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 31
	8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 30		8.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 31
	8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 30		8.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 31
	8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 31		8.4.8. 407 Proxy Authentication Required . . . . . . . . . . 32
	8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 31		8.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 32
	8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 31		8.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 32
	8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32		8.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 32
	8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 32		8.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 33
	8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 32		8.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 33
	8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 32		8.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 33
	8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33		8.4.15. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 33
	8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33		8.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 33
	8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 33		8.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 34
	8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 33		8.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 34
	8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 33		8.4.19. 426 Upgrade Required . . . . . . . . . . . . . . . . . 34
	8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34		8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 34
	8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34		8.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 34
	8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 34		8.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 35
	8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 34		8.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 35
	8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 34		8.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 35
	8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35		8.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 35
	8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35		8.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 35
	9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 35		9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 36
	9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 35		9.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36		9.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 36		9.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 37		9.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 38
	9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 38		9.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 39
	9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39		9.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 39
	9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 39		9.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 40
	9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40		9.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 40		9.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 41
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41		10.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 41
	10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42		10.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 42
	10.3. Header Field Registration . . . . . . . . . . . . . . . . 43		10.3. Header Field Registration . . . . . . . . . . . . . . . . 43
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 44		11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
	11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44		11.1. Transfer of Sensitive Information . . . . . . . . . . . . 44
	11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45		11.2. Encoding Sensitive Information in URIs . . . . . . . . . . 45
	11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46		11.3. Location Headers and Spoofing . . . . . . . . . . . . . . 46
	11.4. Security Considerations for CONNECT . . . . . . . . . . . 46		11.4. Security Considerations for CONNECT . . . . . . . . . . . 46
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 46		13.1. Normative References . . . . . . . . . . . . . . . . . . . 46
	13.2. Informative References . . . . . . . . . . . . . . . . . . 47		13.2. Informative References . . . . . . . . . . . . . . . . . . 47
	Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48		Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 48
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 49		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 49
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 50		publication) . . . . . . . . . . . . . . . . . . . . 51
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 50		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 51
	C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 50		C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 51
	C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 51		C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 52
	C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52		C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 52
	C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 52		C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 53
	C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53		C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 53
	C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 53		C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54
	C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 53		C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54
	C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54		C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54
	C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 54		C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55
	C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55		C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55
	C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55		C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55
	C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 55		C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56
	C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56		C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57		C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
	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 9, line 16		skipping to change at page 9, line 16
	so that this is clear.		so that this is clear.
	Due to the parsing rules defined in Section 3.3 of [Part1],		Due to the parsing rules defined in Section 3.3 of [Part1],
	definitions of HTTP methods cannot prohibit the presence of a		definitions of HTTP methods cannot prohibit the presence of a
	message-body on either the request or the response message (with		message-body on either the request or the response message (with
	responses to HEAD requests being the single exception). Definitions		responses to HEAD requests being the single exception). Definitions
	of new methods cannot change this rule, but they can specify that		of new methods cannot change this rule, but they can specify that
	only zero-length bodies (as opposed to absent bodies) are allowed.		only zero-length bodies (as opposed to absent bodies) are allowed.
	New method definitions need to indicate whether they are safe		New method definitions need to indicate whether they are safe
	(Section 7.1.1) and whether they are idempotent (Section 7.1.2).		(Section 7.1.1), what semantics (if any) the request body has, and
	They also need to state whether they can be cached ([Part6]); in		whether they are idempotent (Section 7.1.2). They also need to state
	particular what conditions a cache may store the response, and under		whether they can be cached ([Part6]); in particular what conditions a
	what conditions such a stored response may be used to satisfy a		cache may store the response, and under what conditions such a stored
	subsequent request.		response may be used to satisfy a subsequent request.
	3. Request Header Fields		3. Request Header Fields
	The request header fields allow the client to pass additional		The request header fields allow the client to pass additional
	information about the request, and about the client itself, to the		information about the request, and about the client itself, to the
	server. These fields act as request modifiers, with semantics		server. These fields act as request modifiers, with semantics
	equivalent to the parameters on a programming language method		equivalent to the parameters on a programming language method
	invocation.		invocation.
	+---------------------+------------------------+		+---------------------+------------------------+
	| Header Field Name | Defined in... |		| Header Field Name | Defined in... |
	+---------------------+------------------------+		+---------------------+------------------------+
	| Accept | Section 6.1 of [Part3] |		| Accept | Section 6.1 of [Part3] |
	| Accept-Charset | Section 6.2 of [Part3] |		| Accept-Charset | Section 6.2 of [Part3] |
	| Accept-Encoding | Section 6.3 of [Part3] |		| Accept-Encoding | Section 6.3 of [Part3] |
	| Accept-Language | Section 6.4 of [Part3] |		| Accept-Language | Section 6.4 of [Part3] |
	| Authorization | Section 4.1 of [Part7] |		| Authorization | Section 4.1 of [Part7] |
	| Expect | Section 9.2 |		| Expect | Section 9.2 |
	| From | Section 9.3 |		| From | Section 9.3 |
	| Host | Section 9.4 of [Part1] |		| Host | Section 9.4 of [Part1] |
	| If-Match | Section 6.2 of [Part4] |		| If-Match | Section 3.1 of [Part4] |
	| If-Modified-Since | Section 6.3 of [Part4] |		| If-Modified-Since | Section 3.3 of [Part4] |
	| If-None-Match | Section 6.4 of [Part4] |		| If-None-Match | Section 3.2 of [Part4] |
	| If-Range | Section 5.3 of [Part5] |		| If-Range | Section 5.3 of [Part5] |
	| If-Unmodified-Since | Section 6.5 of [Part4] |		| If-Unmodified-Since | Section 3.4 of [Part4] |
	| Max-Forwards | Section 9.5 |		| Max-Forwards | Section 9.5 |
	| Proxy-Authorization | Section 4.3 of [Part7] |		| Proxy-Authorization | Section 4.3 of [Part7] |
	| Range | Section 5.4 of [Part5] |		| Range | Section 5.4 of [Part5] |
	| Referer | Section 9.6 |		| Referer | Section 9.6 |
	| TE | Section 9.5 of [Part1] |		| TE | Section 9.5 of [Part1] |
	| User-Agent | Section 9.9 |		| User-Agent | Section 9.9 |
	+---------------------+------------------------+		+---------------------+------------------------+
	4. Status Code and Reason Phrase		4. Status Code and Reason Phrase
	skipping to change at page 10, line 37		skipping to change at page 10, line 37
	safely assume that there was something wrong with its request and		safely assume that there was something wrong with its request and
	treat the response as if it had received a 400 status code. In such		treat the response as if it had received a 400 status code. In such
	cases, user agents SHOULD present to the user the representation		cases, user agents SHOULD present to the user the representation
	enclosed with the response, since that representation is likely to		enclosed with the response, since that representation is likely to
	include human-readable information which will explain the unusual		include human-readable information which will explain the unusual
	status.		status.
	4.1. Overview of Status Codes		4.1. Overview of Status Codes
	The status codes listed below are defined in Section 8 of this		The status codes listed below are defined in Section 8 of this
	specification, Section 3 of [Part4], Section 3 of [Part5], and		specification, Section 4 of [Part4], Section 3 of [Part5], and
	Section 3 of [Part7]. The reason phrases listed here are only		Section 3 of [Part7]. The reason phrases listed here are only
	recommendations -- they can be replaced by local equivalents without		recommendations -- they can be replaced by local equivalents without
	affecting the protocol.		affecting the protocol.
	+-------------+------------------------------+----------------------+		+-------------+------------------------------+----------------------+
	| Status-Code | Reason-Phrase | Defined in... |		| Status-Code | Reason-Phrase | Defined in... |
	+-------------+------------------------------+----------------------+		+-------------+------------------------------+----------------------+
	| 100 | Continue | Section 8.1.1 |		| 100 | Continue | Section 8.1.1 |
	| 101 | Switching Protocols | Section 8.1.2 |		| 101 | Switching Protocols | Section 8.1.2 |
	| 200 | OK | Section 8.2.1 |		| 200 | OK | Section 8.2.1 |
	skipping to change at page 11, line 23		skipping to change at page 11, line 23
	| 203 | Non-Authoritative | Section 8.2.4 |		| 203 | Non-Authoritative | Section 8.2.4 |
	| | Information | |		| | Information | |
	| 204 | No Content | Section 8.2.5 |		| 204 | No Content | Section 8.2.5 |
	| 205 | Reset Content | Section 8.2.6 |		| 205 | Reset Content | Section 8.2.6 |
	| 206 | Partial Content | Section 3.1 of |		| 206 | Partial Content | Section 3.1 of |
	| | | [Part5] |		| | | [Part5] |
	| 300 | Multiple Choices | Section 8.3.1 |		| 300 | Multiple Choices | Section 8.3.1 |
	| 301 | Moved Permanently | Section 8.3.2 |		| 301 | Moved Permanently | Section 8.3.2 |
	| 302 | Found | Section 8.3.3 |		| 302 | Found | Section 8.3.3 |
	| 303 | See Other | Section 8.3.4 |		| 303 | See Other | Section 8.3.4 |
	| 304 | Not Modified | Section 3.1 of |		| 304 | Not Modified | Section 4.1 of |
	| | | [Part4] |		| | | [Part4] |
	| 305 | Use Proxy | Section 8.3.6 |		| 305 | Use Proxy | Section 8.3.6 |
	| 307 | Temporary Redirect | Section 8.3.8 |		| 307 | Temporary Redirect | Section 8.3.8 |
	| 400 | Bad Request | Section 8.4.1 |		| 400 | Bad Request | Section 8.4.1 |
	| 401 | Unauthorized | Section 3.1 of |		| 401 | Unauthorized | Section 3.1 of |
	| | | [Part7] |		| | | [Part7] |
	| 402 | Payment Required | Section 8.4.3 |		| 402 | Payment Required | Section 8.4.3 |
	| 403 | Forbidden | Section 8.4.4 |		| 403 | Forbidden | Section 8.4.4 |
	| 404 | Not Found | Section 8.4.5 |		| 404 | Not Found | Section 8.4.5 |
	| 405 | Method Not Allowed | Section 8.4.6 |		| 405 | Method Not Allowed | Section 8.4.6 |
	| 406 | Not Acceptable | Section 8.4.7 |		| 406 | Not Acceptable | Section 8.4.7 |
	| 407 | Proxy Authentication | Section 3.2 of |		| 407 | Proxy Authentication | Section 3.2 of |
	| | Required | [Part7] |		| | Required | [Part7] |
	| 408 | Request Time-out | Section 8.4.9 |		| 408 | Request Time-out | Section 8.4.9 |
	| 409 | Conflict | Section 8.4.10 |		| 409 | Conflict | Section 8.4.10 |
	| 410 | Gone | Section 8.4.11 |		| 410 | Gone | Section 8.4.11 |
	| 411 | Length Required | Section 8.4.12 |		| 411 | Length Required | Section 8.4.12 |
	| 412 | Precondition Failed | Section 3.2 of |		| 412 | Precondition Failed | Section 4.2 of |
	| | | [Part4] |		| | | [Part4] |
	| 413 | Request Entity Too Large | Section 8.4.14 |		| 413 | Request Entity Too Large | Section 8.4.14 |
	| 414 | URI Too Long | Section 8.4.15 |		| 414 | URI Too Long | Section 8.4.15 |
	| 415 | Unsupported Media Type | Section 8.4.16 |		| 415 | Unsupported Media Type | Section 8.4.16 |
	| 416 | Requested range not | Section 3.2 of |		| 416 | Requested range not | Section 3.2 of |
	| | satisfiable | [Part5] |		| | satisfiable | [Part5] |
	| 417 | Expectation Failed | Section 8.4.18 |		| 417 | Expectation Failed | Section 8.4.18 |
	| 426 | Upgrade Required | Section 8.4.19 |		| 426 | Upgrade Required | Section 8.4.19 |
	| 500 | Internal Server Error | Section 8.5.1 |		| 500 | Internal Server Error | Section 8.5.1 |
	| 501 | Not Implemented | Section 8.5.2 |		| 501 | Not Implemented | Section 8.5.2 |
	skipping to change at page 13, line 20		skipping to change at page 13, line 20
	information about the response which cannot be placed in the Status-		information about the response which cannot be placed in the Status-
	Line. These header fields give information about the server and		Line. These header fields give information about the server and
	about further access to the target resource (Section 4.3 of [Part1]).		about further access to the target resource (Section 4.3 of [Part1]).
	+--------------------+------------------------+		+--------------------+------------------------+
	| Header Field Name | Defined in... |		| Header Field Name | Defined in... |
	+--------------------+------------------------+		+--------------------+------------------------+
	| Accept-Ranges | Section 5.1 of [Part5] |		| Accept-Ranges | Section 5.1 of [Part5] |
	| Age | Section 3.1 of [Part6] |		| Age | Section 3.1 of [Part6] |
	| Allow | Section 9.1 |		| Allow | Section 9.1 |
	| ETag | Section 6.1 of [Part4] |		| ETag | Section 2.2 of [Part4] |
	| Location | Section 9.4 |		| Location | Section 9.4 |
	| Proxy-Authenticate | Section 4.2 of [Part7] |		| Proxy-Authenticate | Section 4.2 of [Part7] |
	| Retry-After | Section 9.7 |		| Retry-After | Section 9.7 |
	| Server | Section 9.8 |		| Server | Section 9.8 |
	| Vary | Section 3.5 of [Part6] |		| Vary | Section 3.5 of [Part6] |
	| WWW-Authenticate | Section 4.4 of [Part7] |		| WWW-Authenticate | Section 4.4 of [Part7] |
	+--------------------+------------------------+		+--------------------+------------------------+
	6. Representation		6. Representation
	skipping to change at page 17, line 7		skipping to change at page 17, line 7
	client.		client.
	The semantics of the GET method change to a "partial GET" if the		The semantics of the GET method change to a "partial GET" if the
	request message includes a Range header field. A partial GET		request message includes a Range header field. A partial GET
	requests that only part of the representation be transferred, as		requests that only part of the representation be transferred, as
	described in Section 5.4 of [Part5]. The partial GET request is		described in Section 5.4 of [Part5]. The partial GET request is
	intended to reduce unnecessary network usage by allowing partially-		intended to reduce unnecessary network usage by allowing partially-
	retrieved representations to be completed without transferring data		retrieved representations to be completed without transferring data
	already held by the client.		already held by the client.
			Bodies on GET requests have no defined semantics. Note that sending
			a body on a GET request might cause some existing implementations to
			reject the request.
	The response to a GET request is cacheable and MAY be used to satisfy		The response to a GET request is cacheable and MAY be used to satisfy
	subsequent GET and HEAD requests (see [Part6]).		subsequent GET and HEAD requests (see [Part6]).
	See Section 11.2 for security considerations when used for forms.		See Section 11.2 for security considerations when used for forms.
	7.4. HEAD		7.4. HEAD
	The HEAD method is identical to GET except that the server MUST NOT		The HEAD method is identical to GET except that the server MUST NOT
	return a message-body in the response. The metadata contained in the		return a message-body in the response. The metadata contained in the
	HTTP header fields in response to a HEAD request SHOULD be identical		HTTP header fields in response to a HEAD request SHOULD be identical
	skipping to change at page 17, line 31		skipping to change at page 17, line 35
	accessibility, and recent modification.		accessibility, and recent modification.
	The response to a HEAD request is cacheable and MAY be used to		The response to a HEAD request is cacheable and MAY be used to
	satisfy a subsequent HEAD request; see [Part6]. It also MAY be used		satisfy a subsequent HEAD request; see [Part6]. It also MAY be used
	to update a previously cached representation from that resource; if		to update a previously cached representation from that resource; if
	the new field values indicate that the cached representation differs		the new field values indicate that the cached representation differs
	from the current representation (as would be indicated by a change in		from the current representation (as would be indicated by a change in
	Content-Length, Content-MD5, ETag or Last-Modified), then the cache		Content-Length, Content-MD5, ETag or Last-Modified), then the cache
	MUST treat the cache entry as stale.		MUST treat the cache entry as stale.
			Bodies on HEAD requests have no defined semantics. Note that sending
			a body on a HEAD request might cause some existing implementations to
			reject the request.
	7.5. POST		7.5. POST
	The POST method requests that the origin server accept the		The POST method requests that the origin server accept the
	representation enclosed in the request as data to be processed by the		representation enclosed in the request as data to be processed by the
	target resource. POST is designed to allow a uniform method to cover		target resource. POST is designed to allow a uniform method to cover
	the following functions:		the following functions:
	o Annotation of existing resources;		o Annotation of existing resources;
	o Posting a message to a bulletin board, newsgroup, mailing list, or		o Posting a message to a bulletin board, newsgroup, mailing list, or
	skipping to change at page 20, line 51		skipping to change at page 21, line 12
	returned from the origin server indicates that the action has been		returned from the origin server indicates that the action has been
	completed successfully. However, the server SHOULD NOT indicate		completed successfully. However, the server SHOULD NOT indicate
	success unless, at the time the response is given, it intends to		success unless, at the time the response is given, it intends to
	delete the resource or move it to an inaccessible location.		delete the resource or move it to an inaccessible location.
	A successful response SHOULD be 200 (OK) if the response includes an		A successful response SHOULD be 200 (OK) if the response includes an
	representation describing the status, 202 (Accepted) if the action		representation describing the status, 202 (Accepted) if the action
	has not yet been enacted, or 204 (No Content) if the action has been		has not yet been enacted, or 204 (No Content) if the action has been
	enacted but the response does not include a representation.		enacted but the response does not include a representation.
			Bodies on DELETE requests have no defined semantics. Note that
			sending a body on a DELETE request might cause some existing
			implementations to reject the request.
	Responses to the DELETE method are not cacheable. If a DELETE		Responses to the DELETE method are not cacheable. If a DELETE
	request passes through a cache that has one or more stored responses		request passes through a cache that has one or more stored responses
	for the effective request URI, those stored responses will be		for the effective request URI, those stored responses will be
	invalidated (see Section 2.5 of [Part6]).		invalidated (see Section 2.5 of [Part6]).
	7.8. TRACE		7.8. TRACE
	The TRACE method requests a remote, application-layer loop-back of		The TRACE method requests a remote, application-layer loop-back of
	the request message. The final recipient of the request SHOULD		the request message. The final recipient of the request SHOULD
	reflect the message received back to the client as the message-body		reflect the message received back to the client as the message-body
	skipping to change at page 22, line 9		skipping to change at page 22, line 21
	except end-to-end protocol Upgrade requests, since the tunnel must be		except end-to-end protocol Upgrade requests, since the tunnel must be
	established first.		established first.
	For example, proxy authentication might be used to establish the		For example, proxy authentication might be used to establish the
	authority to create a tunnel:		authority to create a tunnel:
	CONNECT server.example.com:80 HTTP/1.1		CONNECT server.example.com:80 HTTP/1.1
	Host: server.example.com:80		Host: server.example.com:80
	Proxy-Authorization: basic aGVsbG86d29ybGQ=		Proxy-Authorization: basic aGVsbG86d29ybGQ=
			Bodies on CONNECT requests have no defined semantics. Note that
			sending a body on a CONNECT request might cause some existing
			implementations to reject the request.
	Like any other pipelined HTTP/1.1 request, data to be tunnel may be		Like any other pipelined HTTP/1.1 request, data to be tunnel may be
	sent immediately after the blank line. The usual caveats also apply:		sent immediately after the blank line. The usual caveats also apply:
	data may be discarded if the eventual response is negative, and the		data may be discarded if the eventual response is negative, and the
	connection may be reset with no response if more than one TCP segment		connection may be reset with no response if more than one TCP segment
	is outstanding.		is outstanding.
	7.9.1. Establishing a Tunnel with CONNECT		7.9.1. Establishing a Tunnel with CONNECT
	Any successful (2xx) response to a CONNECT request indicates that the		Any successful (2xx) response to a CONNECT request indicates that the
	proxy has established a connection to the requested host and port,		proxy has established a connection to the requested host and port,
	skipping to change at page 24, line 35		skipping to change at page 25, line 5
	response SHOULD include a payload containing a list of resource		response SHOULD 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 payload format is specified by
	the media type given in the Content-Type header field. The origin		the media type given in the Content-Type header field. The origin
	server MUST create the resource before returning the 201 status code.		server MUST create the resource before returning the 201 status code.
	If the action cannot be carried out immediately, the server SHOULD		If the action cannot be carried out immediately, the server SHOULD
	respond with 202 (Accepted) response instead.		respond with 202 (Accepted) response instead.
	A 201 response MAY contain an ETag response header field indicating		A 201 response MAY contain an ETag response header field indicating
	the current value of the entity-tag for the representation of the		the current value of the entity-tag for the representation of the
	resource just created (see Section 6.1 of [Part4]).		resource just created (see Section 2.2 of [Part4]).
	8.2.3. 202 Accepted		8.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
	place. There is no facility for re-sending a status code from an		place. There is no facility for re-sending a status code from an
	asynchronous operation such as this.		asynchronous operation such as this.
	The 202 response is intentionally non-committal. Its purpose is to		The 202 response is intentionally non-committal. Its purpose is to
	skipping to change at page 25, line 21		skipping to change at page 25, line 40
	information about the resource might result in a superset of the		information about the resource might result in a superset of the
	metadata known by the origin server. Use of this response code is		metadata known by the origin server. Use of this response code is
	not required and is only appropriate when the response would		not required and is only appropriate when the response would
	otherwise be 200 (OK).		otherwise be 200 (OK).
	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.
	8.2.5. 204 No Content		8.2.5. 204 No Content
	The server has successfully fulfilled the request, but there is no		The 204 (No Content) status code indicates that the server has
	additional content to return in the response payload body. The		successfully fulfilled the request and that there is no additional
	resource metadata and representation metadata in the response		content to return in the response payload body. Metadata in the
	message's header fields refer to the target resource and its current		response header fields refer to the target resource and its current
	representation, respectively, after the requested action. For		representation after the requested action.
	example, if a 204 status code is received in response to a PUT and
	the response contains an ETag header field, then the value of that
	field is the current entity-tag for the representation that was
	successfully PUT.
	If the client is a user agent, it SHOULD NOT change its document view		For example, if a 204 status code is received in response to a PUT
	from that which caused the request to be sent. This response is		request and the response contains an ETag header field, then the PUT
	primarily intended to allow input for actions to take place without		was successful and the ETag field-value contains the entity-tag for
	causing a change to the user agent's active document view, although		the new representation of that target resource.
	any new or updated metadata SHOULD be applied to the document
	currently in the user agent's active view.		The 204 response allows a server to indicate that the action has been
			successfully applied to the target resource while implying that the
			user agent SHOULD NOT traverse away from its current "document view"
			(if any). The server assumes that the user agent will provide some
			indication of the success to its user, in accord with its own
			interface, and apply any new or updated metadata in the response to
			the active representation. For example, a 204 status code is
			commonly used with document editing interfaces corresponding to a
			"save" action, such that the document being saved remains available
			to the user for editing. It is also frequently used with interfaces
			that expect automated data transfers to be prevalent, such as within
			distributed version control systems.
	The 204 response MUST NOT include a message-body, and thus is always		The 204 response MUST NOT include a message-body, and thus is always
	terminated by the first empty line after the header fields.		terminated by the first empty line after the header fields.
	8.2.6. 205 Reset Content		8.2.6. 205 Reset Content
	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
	skipping to change at page 28, line 48		skipping to change at page 29, line 30
	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.
	8.3.5. 304 Not Modified		8.3.5. 304 Not Modified
	The response to the request has not been modified since the		The response to the request has not been modified since the
	conditions indicated by the client's conditional GET request, as		conditions indicated by the client's conditional GET request, as
	defined in Section 3.1 of [Part4].		defined in Section 4.1 of [Part4].
	8.3.6. 305 Use Proxy		8.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.
	8.3.7. 306 (Unused)		8.3.7. 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.
	skipping to change at page 32, line 43		skipping to change at page 33, line 21
	8.4.12. 411 Length Required		8.4.12. 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.
	8.4.13. 412 Precondition Failed		8.4.13. 412 Precondition Failed
	The precondition given in one or more of the header fields evaluated		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 3.2		to false when it was tested on the server, as defined in Section 4.2
	of [Part4].		of [Part4].
	8.4.14. 413 Request Entity Too Large		8.4.14. 413 Request Entity 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-
	skipping to change at page 35, line 37		skipping to change at page 36, line 17
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to request and response semantics.		fields related to request and response semantics.
	9.1. Allow		9.1. Allow
	The "Allow" header field lists the set of methods advertised as		The "Allow" header field lists the set of methods advertised as
	supported by the target resource. The purpose of this field is		supported by the target resource. The purpose of this field is
	strictly to inform the recipient of valid request methods associated		strictly to inform the recipient of valid request methods associated
	with the resource.		with the resource.
	Allow = "Allow" ":" OWS Allow-v		Allow = #Method
	Allow-v = #Method
	Example of use:		Example of use:
	Allow: GET, HEAD, PUT		Allow: GET, HEAD, PUT
	The actual set of allowed methods is defined by the origin server at		The actual set of allowed methods is defined by the origin server at
	the time of each request.		the time of each request.
	A proxy MUST NOT modify the Allow header field -- it does not need to		A proxy MUST NOT modify the Allow header field -- it does not need to
	understand all the methods specified in order to handle them		understand all the methods specified in order to handle them
	according to the generic message handling rules.		according to the generic message handling rules.
	9.2. Expect		9.2. Expect
	The "Expect" header field is used to indicate that particular server		The "Expect" header field is used to indicate that particular server
	behaviors are required by the client.		behaviors are required by the client.
	Expect = "Expect" ":" OWS Expect-v		Expect = 1#expectation
	Expect-v = 1#expectation
	expectation = "100-continue" / expectation-extension		expectation = "100-continue" / expectation-extension
	expectation-extension = token [ "=" ( token / quoted-string )		expectation-extension = token [ "=" ( token / quoted-string )
	*expect-params ]		*expect-params ]
	expect-params = ";" token [ "=" ( token / quoted-string ) ]		expect-params = ";" token [ "=" ( token / quoted-string ) ]
	A server that does not understand or is unable to comply with any of		A server that does not understand or is unable to comply with any of
	the expectation values in the Expect field of a request MUST respond		the expectation values in the Expect field of a request MUST respond
	with appropriate error status code. The server MUST respond with a		with appropriate error status code. The server MUST respond with a
	417 (Expectation Failed) status code if any of the expectations		417 (Expectation Failed) status code if any of the expectations
	skipping to change at page 37, line 5		skipping to change at page 37, line 28
	See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status		See Section 7.2.3 of [Part1] for the use of the 100 (Continue) status
	code.		code.
	9.3. From		9.3. From
	The "From" header field, if given, SHOULD contain an Internet e-mail		The "From" header field, if given, SHOULD contain an Internet e-mail
	address for the human user who controls the requesting user agent.		address for the human user who controls the requesting user agent.
	The address SHOULD be machine-usable, as defined by "mailbox" in		The address SHOULD be machine-usable, as defined by "mailbox" in
	Section 3.4 of [RFC5322]:		Section 3.4 of [RFC5322]:
	From = "From" ":" OWS From-v		From = mailbox
	From-v = mailbox
	mailbox = <mailbox, defined in [RFC5322], Section 3.4>		mailbox = <mailbox, defined in [RFC5322], Section 3.4>
	An example is:		An example is:
	From: webmaster@example.org		From: webmaster@example.org
	This header field MAY be used for logging purposes and as a means for		This header field MAY be used for logging purposes and as a means for
	identifying the source of invalid or unwanted requests. It SHOULD		identifying the source of invalid or unwanted requests. It SHOULD
	NOT be used as an insecure form of access protection. The		NOT be used as an insecure form of access protection. The
	skipping to change at page 37, line 50		skipping to change at page 38, line 23
	For 201 (Created) responses, the Location is the URI of the new		For 201 (Created) responses, the Location is the URI of the new
	resource which was created by the request. For 3xx responses, the		resource which was created by the request. For 3xx responses, the
	location SHOULD indicate the server's preferred URI for automatic		location SHOULD indicate the server's preferred URI for automatic
	redirection to the resource.		redirection to the resource.
	The field value consists of a single URI-reference. When it has the		The field value consists of a single URI-reference. When it has the
	form of a relative reference ([RFC3986], Section 4.2), the final		form of a relative reference ([RFC3986], Section 4.2), the final
	value is computed by resolving it against the effective request URI		value is computed by resolving it against the effective request URI
	([RFC3986], Section 5).		([RFC3986], Section 5).
	Location = "Location" ":" OWS Location-v		Location = URI-reference
	Location-v = URI-reference
	Examples are:		Examples are:
	Location: http://www.example.org/pub/WWW/People.html#tim		Location: http://www.example.org/pub/WWW/People.html#tim
	Location: /index.html		Location: /index.html
	There are circumstances in which a fragment identifier in a Location		There are circumstances in which a fragment identifier in a Location
	URI would not be appropriate:		URI would not be appropriate:
	skipping to change at page 38, line 40		skipping to change at page 39, line 13
	contain header fields for both Location and Content-Location.		contain header fields for both Location and Content-Location.
	9.5. Max-Forwards		9.5. 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 7.8) and OPTIONS (Section 7.2) methods to limit the number		(Section 7.8) and OPTIONS (Section 7.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 in mid-chain.
	Max-Forwards = "Max-Forwards" ":" OWS Max-Forwards-v		Max-Forwards = 1*DIGIT
	Max-Forwards-v = 1*DIGIT
	The Max-Forwards value is a decimal integer indicating the remaining		The Max-Forwards value is a decimal integer indicating the remaining
	number of times this request message 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
	the final recipient. If the received Max-Forwards value is greater		the final recipient. If the received Max-Forwards value is greater
	than zero, then the forwarded message MUST contain an updated Max-		than zero, then the forwarded message MUST contain an updated Max-
	skipping to change at page 39, line 27		skipping to change at page 39, line 48
	Some servers use Referer as a means of controlling where they allow		Some servers use Referer as a means of controlling where they allow
	links from (so-called "deep linking"), but legitimate requests do not		links from (so-called "deep linking"), but legitimate requests do not
	always contain a Referer header field.		always contain a Referer header field.
	If the effective request URI was obtained from a source that does not		If the effective request URI was obtained from a source that does not
	have its own URI (e.g., input from the user keyboard), the Referer		have its own URI (e.g., input from the user keyboard), the Referer
	field MUST either be sent with the value "about:blank", or not be		field MUST either be sent with the value "about:blank", or not be
	sent at all. Note that this requirement does not apply to sources		sent at all. Note that this requirement does not apply to sources
	with non-HTTP URIs (e.g., FTP).		with non-HTTP URIs (e.g., FTP).
	Referer = "Referer" ":" OWS Referer-v		Referer = absolute-URI / partial-URI
	Referer-v = absolute-URI / partial-URI
	Example:		Example:
	Referer: http://www.example.org/hypertext/Overview.html		Referer: http://www.example.org/hypertext/Overview.html
	If the field value is a relative URI, it SHOULD be interpreted		If the field value is a relative URI, it SHOULD be interpreted
	relative to the 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.7. Retry-After		9.7. 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 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 = "Retry-After" ":" OWS Retry-After-v		Retry-After = HTTP-date / delta-seconds
	Retry-After-v = HTTP-date / delta-seconds
	Time spans are non-negative decimal integers, representing time in		Time spans are non-negative decimal integers, representing time in
	seconds.		seconds.
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	Two examples of its use are		Two examples of its use are
	Retry-After: Fri, 31 Dec 1999 23:59:59 GMT		Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
	Retry-After: 120		Retry-After: 120
	skipping to change at page 40, line 25		skipping to change at page 40, line 44
	9.8. Server		9.8. Server
	The "Server" header field contains information about the software		The "Server" header field contains information about the software
	used by the origin server to handle the request.		used by the origin server to handle the request.
	The field can contain multiple product tokens (Section 6.3 of		The field can contain multiple product tokens (Section 6.3 of
	[Part1]) and comments (Section 3.2 of [Part1]) identifying the server		[Part1]) and comments (Section 3.2 of [Part1]) identifying the server
	and any significant subproducts. The product tokens are listed in		and any significant subproducts. The product tokens are listed in
	order of their significance for identifying the application.		order of their significance for identifying the application.
	Server = "Server" ":" OWS Server-v		Server = product *( RWS ( product / comment ) )
	Server-v = product
	*( RWS ( product / comment ) )
	Example:		Example:
	Server: CERN/3.0 libwww/2.17		Server: CERN/3.0 libwww/2.17
	If the response is being forwarded through a proxy, the proxy		If the response is being forwarded through a proxy, the proxy
	application MUST NOT modify the Server header field. Instead, it		application MUST NOT modify the Server header field. Instead, it
	MUST include a Via field (as described in Section 9.9 of [Part1]).		MUST include a Via field (as described in Section 9.9 of [Part1]).
	Note: Revealing the specific software version of the server might		Note: Revealing the specific software version of the server might
	skipping to change at page 41, line 24		skipping to change at page 41, line 40
	subproducts by third parties. Overly long and detailed User-Agent		subproducts by third parties. Overly long and detailed User-Agent
	field values make requests larger and can also be used to identify		field values make requests larger and can also be used to identify
	("fingerprint") the user against their wishes.		("fingerprint") the user against their wishes.
	Likewise, implementations are encouraged not to use the product		Likewise, implementations are encouraged not to use the product
	tokens of other implementations in order to declare compatibility		tokens of other implementations in order to declare compatibility
	with them, as this circumvents the purpose of the field. Finally,		with them, as this circumvents the purpose of the field. Finally,
	they are encouraged not to use comments to identify products; doing		they are encouraged not to use comments to identify products; doing
	so makes the field value more difficult to parse.		so makes the field value more difficult to parse.
	User-Agent = "User-Agent" ":" OWS User-Agent-v		User-Agent = product *( RWS ( product / comment ) )
	User-Agent-v = product *( RWS ( product / comment ) )
	Example:		Example:
	User-Agent: CERN-LineMode/2.15 libwww/2.17b3		User-Agent: CERN-LineMode/2.15 libwww/2.17b3
	10. IANA Considerations		10. IANA Considerations
	10.1. Method Registry		10.1. Method Registry
	The registration procedure for HTTP request methods is defined by		The registration procedure for HTTP request methods is defined by
	skipping to change at page 46, line 34		skipping to change at page 46, line 34
	12. Acknowledgments		12. Acknowledgments
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-13		and Message Parsing", draft-ietf-httpbis-p1-messaging-14
	(work in progress), March 2011.		(work in progress), April 2011.
	[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-13		and Content Negotiation", draft-ietf-httpbis-p3-payload-14
	(work in progress), March 2011.		(work in progress), April 2011.
	[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-13 (work in		Requests", draft-ietf-httpbis-p4-conditional-14 (work in
	progress), March 2011.		progress), April 2011.
	[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-13 (work		Partial Responses", draft-ietf-httpbis-p5-range-14 (work
	in progress), March 2011.		in progress), April 2011.
	[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-13 (work in		6: Caching", draft-ietf-httpbis-p6-cache-14 (work in
	progress), March 2011.		progress), April 2011.
	[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-13 (work in progress),		draft-ietf-httpbis-p7-auth-14 (work in progress),
	March 2011.		April 2011.
	[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 48, line 37		skipping to change at page 48, line 37
	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 8.3.6)		repeat this single request via the proxy. (Section 8.3.6)
	Define status 426 (Upgrade Required) (this was incorporated from		Define status 426 (Upgrade Required) (this was incorporated from
	[RFC2817]). (Section 8.4.19)		[RFC2817]). (Section 8.4.19)
			Change ABNF productions for header fields to only define the field
			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)
	Correct syntax of Location header field to allow URI references		Correct syntax of Location header field to allow URI references
	(including relative references and fragments), as referred symbol		(including relative references and fragments), as referred symbol
	"absoluteURI" wasn't what was expected, and add some clarifications		"absoluteURI" wasn't what was expected, and add some clarifications
	as to when use of fragments would not be appropriate. (Section 9.4)		as to when use of fragments would not be appropriate. (Section 9.4)
	skipping to change at page 48, line 49		skipping to change at page 49, line 4
	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)
	Correct syntax of Location header field to allow URI references		Correct syntax of Location header field to allow URI references
	(including relative references and fragments), as referred symbol		(including relative references and fragments), as referred symbol
	"absoluteURI" wasn't what was expected, and add some clarifications		"absoluteURI" wasn't what was expected, and add some clarifications
	as to when use of fragments would not be appropriate. (Section 9.4)		as to when use of fragments would not be appropriate. (Section 9.4)
	Restrict Max-Forwards header field to OPTIONS and TRACE (previously,		Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
	extension methods could have used it as well). (Section 9.5)		extension methods could have used it as well). (Section 9.5)
	Allow Referer field value of "about:blank" as alternative to not		Allow Referer field value of "about:blank" as alternative to not
	specifying it. (Section 9.6)		specifying it. (Section 9.6)
	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 9.9 of [Part1].		in the description of the Via header field in Section 9.9 of [Part1].
	(Section 9.8)		(Section 9.8)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
			Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
	Allow = "Allow:" OWS Allow-v		Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
	Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
	Expect = "Expect:" OWS Expect-v
	Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
	From = "From:" OWS From-v		From = mailbox
	From-v = mailbox
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
	Location = "Location:" OWS Location-v		Location = URI-reference
	Location-v = URI-reference
	Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v		Max-Forwards = 1*DIGIT
	Max-Forwards-v = 1*DIGIT
	Method = token		Method = token
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	RWS = <RWS, defined in [Part1], Section 1.2.2>		RWS = <RWS, defined in [Part1], Section 1.2.2>
	Reason-Phrase = *( WSP / VCHAR / obs-text )		Reason-Phrase = *( WSP / VCHAR / obs-text )
	Referer = "Referer:" OWS Referer-v		Referer = absolute-URI / partial-URI
	Referer-v = absolute-URI / partial-URI		Retry-After = HTTP-date / delta-seconds
	Retry-After = "Retry-After:" OWS Retry-After-v
	Retry-After-v = HTTP-date / delta-seconds
	Server = "Server:" OWS Server-v		Server = product *( RWS ( product / comment ) )
	Server-v = product *( RWS ( product / comment ) )
	Status-Code = 3DIGIT		Status-Code = 3DIGIT
	URI-reference = <URI-reference, defined in [Part1], Section 2.6>		URI-reference = <URI-reference, defined in [Part1], Section 2.6>
	User-Agent = "User-Agent:" OWS User-Agent-v		User-Agent = product *( RWS ( product / comment ) )
	User-Agent-v = product *( RWS ( product / comment ) )
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.6>
	comment = <comment, defined in [Part1], Section 3.2>		comment = <comment, defined in [Part1], Section 3.2>
	delta-seconds = 1*DIGIT		delta-seconds = 1*DIGIT
	expect-params = ";" token [ "=" ( token / quoted-string ) ]		expect-params = ";" token [ "=" ( token / quoted-string ) ]
	expectation = "100-continue" / expectation-extension		expectation = "100-continue" / expectation-extension
	expectation-extension = token [ "=" ( token / quoted-string )		expectation-extension = token [ "=" ( token / quoted-string )
	*expect-params ]		*expect-params ]
	mailbox = <mailbox, defined in [RFC5322], Section 3.4>		mailbox = <mailbox, defined in [RFC5322], Section 3.4>
	obs-text = <obs-text, defined in [Part1], Section 1.2.2>		obs-text = <obs-text, defined in [Part1], Section 1.2.2>
	partial-URI = <partial-URI, defined in [Part1], Section 2.6>		partial-URI = <partial-URI, defined in [Part1], Section 2.6>
	skipping to change at page 57, line 14		skipping to change at page 57, line 41
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not		o <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not
	supporting certain methods"		supporting certain methods"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate		o <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate
	CONNECT from RFC2817 to p2"		CONNECT from RFC2817 to p2"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate		o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
	Upgrade details from RFC2817"		Upgrade details from RFC2817"
	o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify		o <http://tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify PUT
	PUT semantics'"		semantics'"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate		o <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate
	ABNF for 'Method'"		ABNF for 'Method'"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle		o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
	ABNFs for header fields"		ABNFs for header fields"
			C.15. Since draft-ietf-httpbis-p2-semantics-13
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
			ABNFs for header fields"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/251>: "message-body
			in CONNECT request"
	Index		Index
	1		1
	100 Continue (status code) 23		100 Continue (status code) 23
	101 Switching Protocols (status code) 23		101 Switching Protocols (status code) 23
	2		2
	200 OK (status code) 23		200 OK (status code) 24
	201 Created (status code) 24		201 Created (status code) 24
	202 Accepted (status code) 24		202 Accepted (status code) 25
	203 Non-Authoritative Information (status code) 25		203 Non-Authoritative Information (status code) 25
	204 No Content (status code) 25		204 No Content (status code) 25
	205 Reset Content (status code) 25		205 Reset Content (status code) 26
	206 Partial Content (status code) 26		206 Partial Content (status code) 26
	3		3
	300 Multiple Choices (status code) 26		300 Multiple Choices (status code) 27
	301 Moved Permanently (status code) 27		301 Moved Permanently (status code) 27
	302 Found (status code) 27		302 Found (status code) 28
	303 See Other (status code) 28		303 See Other (status code) 28
	304 Not Modified (status code) 28		304 Not Modified (status code) 29
	305 Use Proxy (status code) 29		305 Use Proxy (status code) 29
	306 (Unused) (status code) 29		306 (Unused) (status code) 29
	307 Temporary Redirect (status code) 29		307 Temporary Redirect (status code) 29
	4		4
	400 Bad Request (status code) 30		400 Bad Request (status code) 30
	401 Unauthorized (status code) 30		401 Unauthorized (status code) 30
	402 Payment Required (status code) 30		402 Payment Required (status code) 30
	403 Forbidden (status code) 30		403 Forbidden (status code) 30
	404 Not Found (status code) 30		404 Not Found (status code) 31
	405 Method Not Allowed (status code) 30		405 Method Not Allowed (status code) 31
	406 Not Acceptable (status code) 30		406 Not Acceptable (status code) 31
	407 Proxy Authentication Required (status code) 31		407 Proxy Authentication Required (status code) 32
	408 Request Timeout (status code) 31		408 Request Timeout (status code) 32
	409 Conflict (status code) 31		409 Conflict (status code) 32
	410 Gone (status code) 32		410 Gone (status code) 32
	411 Length Required (status code) 32		411 Length Required (status code) 33
	412 Precondition Failed (status code) 32		412 Precondition Failed (status code) 33
	413 Request Entity Too Large (status code) 32		413 Request Entity Too Large (status code) 33
	414 URI Too Long (status code) 33		414 URI Too Long (status code) 33
	415 Unsupported Media Type (status code) 33		415 Unsupported Media Type (status code) 33
	416 Requested Range Not Satisfiable (status code) 33		416 Requested Range Not Satisfiable (status code) 34
	417 Expectation Failed (status code) 33		417 Expectation Failed (status code) 34
	426 Upgrade Required (status code) 33		426 Upgrade Required (status code) 34
	5		5
	500 Internal Server Error (status code) 34		500 Internal Server Error (status code) 34
	501 Not Implemented (status code) 34		501 Not Implemented (status code) 35
	502 Bad Gateway (status code) 34		502 Bad Gateway (status code) 35
	503 Service Unavailable (status code) 34		503 Service Unavailable (status code) 35
	504 Gateway Timeout (status code) 35		504 Gateway Timeout (status code) 35
	505 HTTP Version Not Supported (status code) 35		505 HTTP Version Not Supported (status code) 35
	A		A
	Allow header field 35		Allow header field 36
	C		C
	CONNECT method 21		CONNECT method 21
	D		D
	DELETE method 20		DELETE method 20
	E		E
	Expect header field 36		Expect header field 36
	F		F
	From header field 36		From header field 37
	G		G
	GET method 16		GET method 16
	Grammar		Grammar
	Allow 35		Allow 36
	Allow-v 35
	delta-seconds 40		delta-seconds 40
	Expect 36		Expect 36
	expect-params 36		expect-params 36
	Expect-v 36
	expectation 36		expectation 36
	expectation-extension 36		expectation-extension 36
	extension-code 10		extension-code 10
	From 37		From 37
	From-v 37		Location 38
	Location 37		Max-Forwards 39
	Location-v 37
	Max-Forwards 38
	Max-Forwards-v 38
	Method 7		Method 7
	Reason-Phrase 10		Reason-Phrase 10
	Referer 39		Referer 39
	Referer-v 39		Retry-After 40
	Retry-After 39
	Retry-After-v 39
	Server 40		Server 40
	Server-v 40
	Status-Code 10		Status-Code 10
	User-Agent 41		User-Agent 41
	User-Agent-v 41
	H		H
	HEAD method 17		HEAD method 17
	Header Fields		Header Fields
	Allow 35		Allow 36
	Expect 36		Expect 36
	From 36		From 37
	Location 37		Location 38
	Max-Forwards 38		Max-Forwards 39
	Referer 39		Referer 39
	Retry-After 39		Retry-After 40
	Server 40		Server 40
	User-Agent 40		User-Agent 41
	I		I
	Idempotent Methods 15		Idempotent Methods 15
	L		L
	Location header field 37		Location header field 38
	M		M
	Max-Forwards header field 38		Max-Forwards header field 39
	Methods		Methods
	CONNECT 21		CONNECT 21
	DELETE 20		DELETE 20
	GET 16		GET 16
	HEAD 17		HEAD 17
	OPTIONS 15		OPTIONS 15
	POST 17		POST 17
	PUT 18		PUT 18
	TRACE 21		TRACE 21
	O		O
	OPTIONS method 15		OPTIONS method 15
	P		P
	POST method 17		POST method 17
	PUT method 18		PUT method 18
	R		R
	Referer header field 39		Referer header field 39
	Retry-After header field 39		Retry-After header field 40
	S		S
	Safe Methods 14		Safe Methods 14
	Server header field 40		Server header field 40
	Status Codes		Status Codes
	100 Continue 23		100 Continue 23
	101 Switching Protocols 23		101 Switching Protocols 23
	200 OK 23		200 OK 24
	201 Created 24		201 Created 24
	202 Accepted 24		202 Accepted 25
	203 Non-Authoritative Information 25		203 Non-Authoritative Information 25
	204 No Content 25		204 No Content 25
	205 Reset Content 25		205 Reset Content 26
	206 Partial Content 26		206 Partial Content 26
	300 Multiple Choices 26		300 Multiple Choices 27
	301 Moved Permanently 27		301 Moved Permanently 27
	302 Found 27		302 Found 28
	303 See Other 28		303 See Other 28
	304 Not Modified 28		304 Not Modified 29
	305 Use Proxy 29		305 Use Proxy 29
	306 (Unused) 29		306 (Unused) 29
	307 Temporary Redirect 29		307 Temporary Redirect 29
	400 Bad Request 30		400 Bad Request 30
	401 Unauthorized 30		401 Unauthorized 30
	402 Payment Required 30		402 Payment Required 30
	403 Forbidden 30		403 Forbidden 30
	404 Not Found 30		404 Not Found 31
	405 Method Not Allowed 30		405 Method Not Allowed 31
	406 Not Acceptable 30		406 Not Acceptable 31
	407 Proxy Authentication Required 31		407 Proxy Authentication Required 32
	408 Request Timeout 31		408 Request Timeout 32
	409 Conflict 31		409 Conflict 32
	410 Gone 32		410 Gone 32
	411 Length Required 32		411 Length Required 33
	412 Precondition Failed 32		412 Precondition Failed 33
	413 Request Entity Too Large 32		413 Request Entity Too Large 33
	414 URI Too Long 33		414 URI Too Long 33
	415 Unsupported Media Type 33		415 Unsupported Media Type 33
	416 Requested Range Not Satisfiable 33		416 Requested Range Not Satisfiable 34
	417 Expectation Failed 33		417 Expectation Failed 34
	426 Upgrade Required 33		426 Upgrade Required 34
	500 Internal Server Error 34		500 Internal Server Error 34
	501 Not Implemented 34		501 Not Implemented 35
	502 Bad Gateway 34		502 Bad Gateway 35
	503 Service Unavailable 34		503 Service Unavailable 35
	504 Gateway Timeout 35		504 Gateway Timeout 35
	505 HTTP Version Not Supported 35		505 HTTP Version Not Supported 35
	T		T
	TRACE method 21		TRACE method 21
	U		U
	User-Agent header field 40		User-Agent header field 41
	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. 110 change blocks.
	200 lines changed or deleted		213 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/