draft-ietf-httpbis-p2-semantics-02.txt		draft-ietf-httpbis-p2-semantics-03.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Updates: 2817 (if approved) One Laptop per Child
	Expires: August 27, 2008 J. Mogul		Intended status: Standards Track J. Mogul
	HP		Expires: December 19, 2008 HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	February 24, 2008		June 17, 2008
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-02		draft-ietf-httpbis-p2-semantics-03
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 27, 2008.		This Internet-Draft will expire on December 19, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	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,
	skipping to change at page 2, line 29		skipping to change at page 2, line 25
	fields.		fields.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://www.tools.ietf.org/wg/httpbis/>.		<http://www.tools.ietf.org/wg/httpbis/>.
	This draft incorporates those issue resolutions that were either		The changes in this draft are summarized in Appendix B.4.
	collected in the original RFC2616 errata list
	(<http://purl.org/NET/http-errata>), or which were agreed upon on the
	mailing list between October 2006 and November 2007 (as published in
	"draft-lafon-rfc2616bis-03").
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	2. Notational Conventions and Generic Grammar . . . . . . . . . . 6		2. Notational Conventions and Generic Grammar . . . . . . . . . . 6
	3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8		4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8
	5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9		5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9
			5.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 11
	6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11		6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11
	7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12		8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12		8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12
	8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12		8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12
	8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 12		8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 13
	8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13		8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18		8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18		9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18
	9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18		9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18
	9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 18		9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 19
	9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19		9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19
	9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19		9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19
	9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19		9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 19		9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 20
	9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20		9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20
	9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20		9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20
	9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 20		9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 21
	9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21		9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21
	9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21		9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21
	9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21		9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21
	9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 21		9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 22
	9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22		9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22
	9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 22		9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 23
	9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23		9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23
	9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 23		9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 24
	9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 23		9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 24
	9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24		9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24
	9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24		9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24
	9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 24		9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 25
	9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25		9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25
	9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25		9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25
	9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25		9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25
	9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25		9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25
	9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 25		9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 26
	9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 25		9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 26
	9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 25		9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 26
	9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26		9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26
	9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 26		9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 27
	9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 26		9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 27
	9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27		9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27
	9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 27		9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 28
	9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 27		9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 28
	9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 27		9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 28
	9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28		9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28
	9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28		9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28
	9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28		9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28
	9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 28		9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 29
	9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 28		9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 29
	9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 28		9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 29
	9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29		9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29
	9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29		9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29
	9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29		9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29
	9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 29		9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 30
	9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 29		9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 30
	10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30		10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30
	10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30		10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 30		10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31		10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32		10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32
	10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33		10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33
	10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33		10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33
	10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34		10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34
	10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34		10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35		10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 35		11.1. Status Code Registry . . . . . . . . . . . . . . . . . . . 35
	12.1. Transfer of Sensitive Information . . . . . . . . . . . . 35		11.2. Message Header Registration . . . . . . . . . . . . . . . 37
	12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 36		12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 37		12.1. Transfer of Sensitive Information . . . . . . . . . . . . 37
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37		12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 38
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37		12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 39
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 37		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
	14.2. Informative References . . . . . . . . . . . . . . . . . . 38		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
	Appendix A. Compatibility with Previous Versions . . . . . . . . 38		14.1. Normative References . . . . . . . . . . . . . . . . . . . 39
	A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 38		14.2. Informative References . . . . . . . . . . . . . . . . . . 40
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 39		Appendix A. Compatibility with Previous Versions . . . . . . . . 40
			A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 40
			A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 41
	Appendix B. Change Log (to be removed by RFC Editor before		Appendix B. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 40		publication) . . . . . . . . . . . . . . . . . . . . 42
	B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 40		B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 42
	B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 40		B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 42
	B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 41		B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 43
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41		B.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
	Intellectual Property and Copyright Statements . . . . . . . . . . 48		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
			Intellectual Property and Copyright Statements . . . . . . . . . . 51
	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 8, line 11		skipping to change at page 8, line 11
	Proxy-Authorization =		Proxy-Authorization =
	<Proxy-Authorization, defined in [Part7], Section 4.3>		<Proxy-Authorization, defined in [Part7], Section 4.3>
	WWW-Authenticate =		WWW-Authenticate =
	<WWW-Authenticate, defined in [Part7], Section 4.4>		<WWW-Authenticate, defined in [Part7], Section 4.4>
	3. Method		3. Method
	The Method token indicates the method to be performed on the resource		The Method token indicates the method to be performed on the resource
	identified by the Request-URI. The method is case-sensitive.		identified by the Request-URI. The method is case-sensitive.
	Method = "OPTIONS" ; Section 8.2		Method = %x4F.50.54.49.4F.4E.53 ; "OPTIONS", Section 8.2
	| "GET" ; Section 8.3		| %x47.45.54 ; "GET", Section 8.3
	| "HEAD" ; Section 8.4		| %x48.45.41.44 ; "HEAD", Section 8.4
	| "POST" ; Section 8.5		| %x50.4F.53.54 ; "POST", Section 8.5
	| "PUT" ; Section 8.6		| %x50.55.54 ; "PUT", Section 8.6
	| "DELETE" ; Section 8.7		| %x44.45.4C.45.54.45 ; "DELETE", Section 8.7
	| "TRACE" ; Section 8.8		| %x54.52.41.43.45 ; "TRACE", Section 8.8
	| "CONNECT" ; Section 8.9		| %x43.4F.4E.4E.45.43.54 ; "CONNECT", Section 8.9
	| extension-method		| extension-method
	extension-method = token		extension-method = token
	The list of methods allowed by a resource can be specified in an		The list of methods allowed by a resource can be specified in an
	Allow header field (Section 10.1). The return code of the response		Allow header field (Section 10.1). The return code of the response
	always notifies the client whether a method is currently allowed on a		always notifies the client whether a method is currently allowed on a
	resource, since the set of allowed methods can change dynamically.		resource, since the set of allowed methods can change dynamically.
	An origin server SHOULD return the status code 405 (Method Not		An origin server SHOULD return the status code 405 (Method Not
	Allowed) if the method is known by the origin server but not allowed		Allowed) if the method is known by the origin server but not allowed
	for the requested resource, and 501 (Not Implemented) if the method		for the requested resource, and 501 (Not Implemented) if the method
	skipping to change at page 11, line 16		skipping to change at page 11, line 16
	digit, and treat any unrecognized response as being equivalent to the		digit, and treat any unrecognized response as being equivalent to the
	x00 status code of that class, with the exception that an		x00 status code of that class, with the exception that an
	unrecognized response MUST NOT be cached. For example, if an		unrecognized response MUST NOT be cached. For example, if an
	unrecognized status code of 431 is received by the client, it can		unrecognized status code of 431 is received by the client, it can
	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 entity returned		cases, user agents SHOULD present to the user the entity returned
	with the response, since that entity is likely to include human-		with the response, since that entity is likely to include human-
	readable information which will explain the unusual status.		readable information which will explain the unusual status.
			5.1. Status Code Registry
			The HTTP Status Code Registry defines the name space for the Status-
			Code token in the Status line of an HTTP response.
			Values to be added to this name space are subject to IETF review
			([RFC5226], Section 4.1). Any document registering new status codes
			should be traceable through statuses of either 'Obsoletes' or
			'Updates' to this document.
			The registry itself is maintained at
			<http://www.iana.org/assignments/http-status-codes>.
	6. Response Header Fields		6. Response Header Fields
	The response-header fields allow the server to pass additional		The response-header fields allow the server to pass additional
	information about the response which cannot be placed in the Status-		information about the response which cannot be placed in the Status-
	Line. These header fields give information about the server and		Line. These header fields give information about the server and
	about further access to the resource identified by the Request-URI.		about further access to the resource identified by the Request-URI.
	response-header = Accept-Ranges ; [Part5], Section 6.1		response-header = Accept-Ranges ; [Part5], Section 6.1
	| Age ; [Part6], Section 16.1		| Age ; [Part6], Section 16.1
			| Allow ; Section 10.1
	| ETag ; [Part4], Section 7.1		| ETag ; [Part4], Section 7.1
	| Location ; Section 10.4		| Location ; Section 10.4
	| Proxy-Authenticate ; [Part7], Section 4.2		| Proxy-Authenticate ; [Part7], Section 4.2
	| Retry-After ; Section 10.7		| Retry-After ; Section 10.7
	| Server ; Section 10.8		| Server ; Section 10.8
	| Vary ; [Part6], Section 16.5		| Vary ; [Part6], Section 16.5
	| WWW-Authenticate ; [Part7], Section 4.4		| WWW-Authenticate ; [Part7], Section 4.4
	Response-header field names can be extended reliably only in		Response-header field names can be extended reliably only in
	combination with a change in the protocol version. However, new or		combination with a change in the protocol version. However, new or
	skipping to change at page 16, line 7		skipping to change at page 16, line 20
	status of the request and refers to the new resource, and a Location		status of the request and refers to the new resource, and a Location
	header (see Section 10.4).		header (see Section 10.4).
	Responses to this method are not cacheable, unless the response		Responses to this method are not cacheable, unless the response
	includes appropriate Cache-Control or Expires header fields.		includes appropriate Cache-Control or Expires header fields.
	However, the 303 (See Other) response can be used to direct the user		However, the 303 (See Other) response can be used to direct the user
	agent to retrieve a cacheable resource.		agent to retrieve a cacheable resource.
	8.6. PUT		8.6. PUT
	The PUT method requests that the enclosed entity be stored under the		The PUT method requests that the enclosed entity be stored at the
	supplied Request-URI. If the Request-URI refers to an already		supplied Request-URI. If the Request-URI refers to an already
	existing resource, the enclosed entity SHOULD be considered as a		existing resource, the enclosed entity SHOULD be considered as a
	modified version of the one residing on the origin server. If the		modified version of the one residing on the origin server. If the
	Request-URI does not point to an existing resource, and that URI is		Request-URI does not point to an existing resource, and that URI is
	capable of being defined as a new resource by the requesting user		capable of being defined as a new resource by the requesting user
	agent, the origin server can create the resource with that URI. If a		agent, the origin server can create the resource with that URI. If a
	new resource is created at the Request-URI, the origin server MUST		new resource is created at the Request-URI, the origin server MUST
	inform the user agent via the 201 (Created) response. If an existing		inform the user agent via the 201 (Created) response. If an existing
	resource is modified, either the 200 (OK) or 204 (No Content)		resource is modified, either the 200 (OK) or 204 (No Content)
	response codes SHOULD be sent to indicate successful completion of		response codes SHOULD be sent to indicate successful completion of
	skipping to change at page 17, line 47		skipping to change at page 18, line 13
	TRACE allows the client to see what is being received at the other		TRACE allows the client to see what is being received at the other
	end of the request chain and use that data for testing or diagnostic		end of the request chain and use that data for testing or diagnostic
	information. The value of the Via header field (Section 8.9 of		information. The value of the Via header field (Section 8.9 of
	[Part1]) is of particular interest, since it acts as a trace of the		[Part1]) is of particular interest, since it acts as a trace of the
	request chain. Use of the Max-Forwards header field allows the		request chain. Use of the Max-Forwards header field allows the
	client to limit the length of the request chain, which is useful for		client to limit the length of the request chain, which is useful for
	testing a chain of proxies forwarding messages in an infinite loop.		testing a chain of proxies forwarding messages in an infinite loop.
	If the request is valid, the response SHOULD contain the entire		If the request is valid, the response SHOULD contain the entire
	request message in the entity-body, with a Content-Type of "message/		request message in the entity-body, with a Content-Type of "message/
	http". Responses to this method MUST NOT be cached.		http" (see Appendix A.1 of [Part1]). Responses to this method MUST
			NOT be cached.
	8.9. CONNECT		8.9. CONNECT
	This specification reserves the method name CONNECT for use with a		This specification reserves the method name CONNECT for use with a
	proxy that can dynamically switch to being a tunnel (e.g. SSL		proxy that can dynamically switch to being a tunnel (e.g. SSL
	tunneling [Luo1998]).		tunneling [Luo1998]).
	9. Status Code Definitions		9. Status Code Definitions
	Each Status-Code is described below, including a description of which		Each Status-Code is described below, including a description of which
	skipping to change at page 23, line 17		skipping to change at page 23, line 36
	allowed to change the method on the redirected request. However,		allowed to change the method on the redirected request. However,
	most existing user agent implementations treat 302 as if it were a		most existing user agent implementations treat 302 as if it were a
	303 response, performing a GET on the Location field-value		303 response, performing a GET on the Location field-value
	regardless of the original request method. The status codes 303		regardless of the original request method. The status codes 303
	and 307 have been added for servers that wish to make		and 307 have been added for servers that wish to make
	unambiguously clear which kind of reaction is expected of the		unambiguously clear which kind of reaction is expected of the
	client.		client.
	9.3.4. 303 See Other		9.3.4. 303 See Other
	The response to the request can be found under a different URI and		The server directs the user agent to a different resource, indicated
	SHOULD be retrieved using a GET method on that resource. This method		by a URI in the Location header field, that provides an indirect
	exists primarily to allow the output of a POST-activated script to		response to the original request. The user agent MAY perform a GET
	redirect the user agent to a selected resource. The new URI is not a		request on the URI in the Location field in order to obtain a
	substitute reference for the originally requested resource. The 303		representation corresponding to the response, be redirected again, or
	response MUST NOT be cached, but the response to the second		end with an error status. The Location URI is not a substitute
	(redirected) request might be cacheable.		reference for the originally requested resource.
	The different URI SHOULD be given by the Location field in the		The 303 status is generally applicable to any HTTP method. It is
	response. Unless the request method was HEAD, the entity of the		primarily used to allow the output of a POST action to redirect the
	response SHOULD contain a short hypertext note with a hyperlink to		user agent to a selected resource, since doing so provides the
	the new URI(s).		information corresponding to the POST response in a form that can be
			separately identified, bookmarked, and cached independent of the
			original request.
	Note: Many pre-HTTP/1.1 user agents do not understand the 303		A 303 response to a GET request indicates that the requested resource
	status. When interoperability with such clients is a concern, the		does not have a representation of its own that can be transferred by
	302 status code may be used instead, since most user agents react		the server over HTTP. The Location URI indicates a resource that is
	to a 302 response as described here for 303.		descriptive of the requested resource such that the follow-on
			representation may be useful without implying that it adequately
			represents the previously requested resource. Note that answers to
			the questions of what can be represented, what representations are
			adequate, and what might be a useful description are outside the
			scope of HTTP and thus entirely determined by the resource owner(s).
			A 303 response SHOULD NOT be cached unless it is indicated as
			cacheable by Cache-Control or Expires header fields. Except for
			responses to a HEAD request, the entity of a 303 response SHOULD
			contain a short hypertext note with a hyperlink to the Location URI.
	9.3.5. 304 Not Modified		9.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 [Part4].		defined in [Part4].
	9.3.6. 305 Use Proxy		9.3.6. 305 Use Proxy
	The requested resource MUST be accessed through the proxy given by		The 305 status was defined in a previous version of this
	the Location field. The Location field gives the URI of the proxy.		specification (see Appendix A.2), and is now deprecated.
	The recipient is expected to repeat this single request via the
	proxy. 305 responses MUST only be generated by origin servers.
	Note: [RFC2068] was not clear that 305 was intended to redirect a
	single request, and to be generated by origin servers only. Not
	observing these limitations has significant security consequences.
	9.3.7. 306 (Unused)		9.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.
	9.3.8. 307 Temporary Redirect		9.3.8. 307 Temporary Redirect
	The requested resource resides temporarily under a different URI.		The requested resource resides temporarily under a different URI.
	Since the redirection MAY be altered on occasion, the client SHOULD		Since the redirection MAY be altered on occasion, the client SHOULD
	skipping to change at page 30, line 16		skipping to change at page 30, line 36
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to request and response semantics.		fields related to request and response semantics.
	For entity-header fields, both sender and recipient refer to either		For entity-header fields, both sender and recipient refer to either
	the client or the server, depending on who sends and who receives the		the client or the server, depending on who sends and who receives the
	entity.		entity.
	10.1. Allow		10.1. Allow
	The Allow entity-header field lists the set of methods supported by		The Allow response-header field lists the set of methods advertised
	the resource identified by the Request-URI. The purpose of this		as supported by the resource identified by the Request-URI. The
	field is strictly to inform the recipient of valid methods associated		purpose of this field is strictly to inform the recipient of valid
	with the resource. An Allow header field MUST be present in a 405		methods associated with the resource. An Allow header field MUST be
	(Method Not Allowed) response.		present in a 405 (Method Not Allowed) response.
	Allow = "Allow" ":" #Method		Allow = "Allow" ":" #Method
	Example of use:		Example of use:
	Allow: GET, HEAD, PUT		Allow: GET, HEAD, PUT
	This field cannot prevent a client from trying other methods.		The actual set of allowed methods is defined by the origin server at
	However, the indications given by the Allow header field value SHOULD		the time of each request.
	be followed. The actual set of allowed methods is defined by the
	origin server at the time of each request.
	The Allow header field MAY be provided with a PUT request to
	recommend the methods to be supported by the new or modified
	resource. The server is not required to support these methods and
	SHOULD include an Allow header in the response giving the actual
	supported methods.
	A proxy MUST NOT modify the Allow header field even if it does not		A proxy MUST NOT modify the Allow header field even if it does not
	understand all the methods specified, since the user agent might have		understand all the methods specified, since the user agent might have
	other means of communicating with the origin server.		other means of communicating with the origin server.
	10.2. Expect		10.2. Expect
	The Expect request-header field is used to indicate that particular		The Expect request-header field is used to indicate that particular
	server behaviors are required by the client.		server behaviors are required by the client.
	skipping to change at page 32, line 23		skipping to change at page 32, line 36
	used.		used.
	The client SHOULD NOT send the From header field without the user's		The client SHOULD NOT send the From header field without the user's
	approval, as it might conflict with the user's privacy interests or		approval, as it might conflict with the user's privacy interests or
	their site's security policy. It is strongly recommended that the		their site's security policy. It is strongly recommended that the
	user be able to disable, enable, and modify the value of this field		user be able to disable, enable, and modify the value of this field
	at any time prior to a request.		at any time prior to a request.
	10.4. Location		10.4. Location
	The Location response-header field is used to redirect the recipient		The Location response-header field is used for the identification of
	to a location other than the Request-URI for completion of the		a new resource or to redirect the recipient to a location other than
	request or identification of a new resource. For 201 (Created)		the Request-URI for completion of the request. For 201 (Created)
	responses, the Location is that of the new resource which was created		responses, the Location is that of the new resource which was created
	by the request. For 3xx responses, the location SHOULD indicate the		by the request. For 3xx responses, the location SHOULD indicate the
	server's preferred URI for automatic redirection to the resource.		server's preferred URI for automatic redirection to the resource.
	The field value consists of a single absolute URI.		The field value consists of a single absolute URI.
	Location = "Location" ":" absoluteURI [ "#" fragment ]		Location = "Location" ":" absoluteURI [ "#" fragment ]
	An example is:		An example is:
	Location: http://www.example.org/pub/WWW/People.html		Location: http://www.example.org/pub/WWW/People.html
	skipping to change at page 35, line 28		skipping to change at page 35, line 44
	significance for identifying the application.		significance for identifying the application.
	User-Agent = "User-Agent" ":" 1*( product | comment )		User-Agent = "User-Agent" ":" 1*( product | comment )
	Example:		Example:
	User-Agent: CERN-LineMode/2.15 libwww/2.17b3		User-Agent: CERN-LineMode/2.15 libwww/2.17b3
	11. IANA Considerations		11. IANA Considerations
	[[anchor1: TBD.]]		11.1. Status Code Registry
			The registration procedure for HTTP Status Codes -- previously
			defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1
			of this document.
			The HTTP Status Code Registry located at
			<http://www.iana.org/assignments/http-status-codes> should be updated
			with the registrations below:
			+-------+---------------------------------+----------------+
			| Value | Description | Reference |
			+-------+---------------------------------+----------------+
			| 100 | Continue | Section 9.1.1 |
			| 101 | Switching Protocols | Section 9.1.2 |
			| 200 | OK | Section 9.2.1 |
			| 201 | Created | Section 9.2.2 |
			| 202 | Accepted | Section 9.2.3 |
			| 203 | Non-Authoritative Information | Section 9.2.4 |
			| 204 | No Content | Section 9.2.5 |
			| 205 | Reset Content | Section 9.2.6 |
			| 206 | Partial Content | Section 9.2.7 |
			| 300 | Multiple Choices | Section 9.3.1 |
			| 301 | Moved Permanently | Section 9.3.2 |
			| 302 | Found | Section 9.3.3 |
			| 303 | See Other | Section 9.3.4 |
			| 304 | Not Modified | Section 9.3.5 |
			| 305 | Use Proxy | Section 9.3.6 |
			| 306 | (Unused) | Section 9.3.7 |
			| 307 | Temporary Redirect | Section 9.3.8 |
			| 400 | Bad Request | Section 9.4.1 |
			| 401 | Unauthorized | Section 9.4.2 |
			| 402 | Payment Required | Section 9.4.3 |
			| 403 | Forbidden | Section 9.4.4 |
			| 404 | Not Found | Section 9.4.5 |
			| 405 | Method Not Allowed | Section 9.4.6 |
			| 406 | Not Acceptable | Section 9.4.7 |
			| 407 | Proxy Authentication Required | Section 9.4.8 |
			| 408 | Request Timeout | Section 9.4.9 |
			| 409 | Conflict | Section 9.4.10 |
			| 410 | Gone | Section 9.4.11 |
			| 411 | Length Required | Section 9.4.12 |
			| 412 | Precondition Failed | Section 9.4.13 |
			| 413 | Request Entity Too Large | Section 9.4.14 |
			| 414 | Request-URI Too Long | Section 9.4.15 |
			| 415 | Unsupported Media Type | Section 9.4.16 |
			| 416 | Requested Range Not Satisfiable | Section 9.4.17 |
			| 417 | Expectation Failed | Section 9.4.18 |
			| 500 | Internal Server Error | Section 9.5.1 |
			| 501 | Not Implemented | Section 9.5.2 |
			| 502 | Bad Gateway | Section 9.5.3 |
			| 503 | Service Unavailable | Section 9.5.4 |
			| 504 | Gateway Timeout | Section 9.5.5 |
			| 505 | HTTP Version Not Supported | Section 9.5.6 |
			+-------+---------------------------------+----------------+
			11.2. Message Header Registration
			The Message Header Registry located at <http://www.iana.org/
			assignments/message-headers/message-header-index.html> should be
			updated with the permanent registrations below (see [RFC3864]):
			+-------------------+----------+----------+--------------+
			| Header Field Name | Protocol | Status | Reference |
			+-------------------+----------+----------+--------------+
			| Allow | http | standard | Section 10.1 |
			| Expect | http | standard | Section 10.2 |
			| From | http | standard | Section 10.3 |
			| Location | http | standard | Section 10.4 |
			| Max-Forwards | http | standard | Section 10.5 |
			| Referer | http | standard | Section 10.6 |
			| Retry-After | http | standard | Section 10.7 |
			| Server | http | standard | Section 10.8 |
			| User-Agent | http | standard | Section 10.9 |
			+-------------------+----------+----------+--------------+
			The change controller is: "IETF (iesg@ietf.org) - Internet
			Engineering Task Force".
	12. Security Considerations		12. Security Considerations
	This section is meant to inform application developers, information		This section is meant to inform application developers, information
	providers, and users of the security limitations in HTTP/1.1 as		providers, and users of the security limitations in HTTP/1.1 as
	described by this document. The discussion does not include		described by this document. The discussion does not include
	definitive solutions to the problems revealed, though it does make		definitive solutions to the problems revealed, though it does make
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	12.1. Transfer of Sensitive Information		12.1. Transfer of Sensitive Information
	skipping to change at page 37, line 26		skipping to change at page 39, line 22
	13. Acknowledgments		13. Acknowledgments
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-02		and Message Parsing", draft-ietf-httpbis-p1-messaging-03
	(work in progress), February 2008.		(work in progress), June 2008.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-02		and Content Negotiation", draft-ietf-httpbis-p3-payload-03
	(work in progress), February 2008.		(work in progress), June 2008.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-02 (work in		Requests", draft-ietf-httpbis-p4-conditional-03 (work in
	progress), February 2008.		progress), June 2008.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-02 (work		Partial Responses", draft-ietf-httpbis-p5-range-03 (work
	in progress), February 2008.		in progress), June 2008.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-02 (work in progress),		draft-ietf-httpbis-p6-cache-03 (work in progress),
	February 2008.		June 2008.
	[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",		and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
	draft-ietf-httpbis-p7-auth-02 (work in progress),		draft-ietf-httpbis-p7-auth-03 (work in progress),
	February 2008.		June 2008.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	14.2. Informative References		14.2. Informative References
	[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web		[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web
	proxy servers", draft-luotonen-web-proxy-tunneling-01		proxy servers", draft-luotonen-web-proxy-tunneling-01
	(work in progress), August 1998.		(work in progress), August 1998.
	skipping to change at page 38, line 33		skipping to change at page 40, line 28
	Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.		Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",		Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	RFC 2068, January 1997.		RFC 2068, January 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
			[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
			HTTP/1.1", RFC 2817, May 2000.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,		[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.		April 2001.
			[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
			Procedures for Message Header Fields", BCP 90, RFC 3864,
			September 2004.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	Appendix A. Compatibility with Previous Versions		Appendix A. Compatibility with Previous Versions
	A.1. Changes from RFC 2068		A.1. Changes from RFC 2068
	Clarified which error code should be used for inbound server failures		Clarified which error code should be used for inbound server failures
	(e.g. DNS failures). (Section 9.5.5).		(e.g. DNS failures). (Section 9.5.5).
	201 (Created) had a race that required an Etag be sent when a		201 (Created) had a race that required an Etag be sent when a
	resource is first created. (Section 9.2.2).		resource is first created. (Section 9.2.2).
	skipping to change at page 39, line 34		skipping to change at page 41, line 39
	7. Allow servers to defend against denial-of-service attacks and		7. Allow servers to defend against denial-of-service attacks and
	broken clients.		broken clients.
	This change adds the Expect header and 417 status code.		This change adds the Expect header and 417 status code.
	Clean up confusion between 403 and 404 responses. (Section 9.4.4,		Clean up confusion between 403 and 404 responses. (Section 9.4.4,
	9.4.5, and 9.4.11)		9.4.5, and 9.4.11)
	The PATCH, LINK, UNLINK methods were defined but not commonly		The PATCH, LINK, UNLINK methods were defined but not commonly
	implemented in previous versions of this specification. See		implemented in previous versions of this specification. See Section
	[RFC2068].		19.6.1 of [RFC2068].
	A.2. Changes from RFC 2616		A.2. Changes from RFC 2616
			This document takes over the Status Code Registry, previously defined
			in Section 7.1 of [RFC2817]. (Section 5.1)
	Clarify definition of POST. (Section 8.5)		Clarify definition of POST. (Section 8.5)
	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. (Sections 9.3.2, 9.3.3 and 9.3.8 )		semantics. (Sections 9.3.2, 9.3.3 and 9.3.8 )
			Deprecate 305 Use Proxy status code, because user agents did not
			implement it. It used to indicate that the requested resource must
			be accessed through the proxy given by the Location field. The
			Location field gave the URI of the proxy. The recipient was expected
			to repeat this single request via the proxy. (Section 9.3.6)
			Reclassify Allow header as response header, removing the option to
			specify it in a PUT request. Relax the server requirement on the
			contents of the Allow header and remove requirement on clients to
			always trust the header value. (Section 10.1)
	Correct syntax of Location header to allow fragment, as referred		Correct syntax of Location header to allow fragment, as referred
	symbol wasn't what was expected, and add some clarifications as to		symbol wasn't what was expected, and add some clarifications as to
	when it would not be appropriate. (Section 10.4)		when it would not be appropriate. (Section 10.4)
	In the description of the Server header, the Via field was described		In the description of the Server header, the Via field was described
	as a SHOULD. The requirement was and is stated correctly in the		as a SHOULD. The requirement was and is stated correctly in the
	description of the Via header in Section 8.9 of [Part1].		description of the Via header in Section 8.9 of [Part1].
	(Section 10.8)		(Section 10.8)
	Appendix B. Change Log (to be removed by RFC Editor before publication)		Appendix B. Change Log (to be removed by RFC Editor before publication)
	B.1. Since RFC2616		B.1. Since RFC2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	B.2. Since draft-ietf-httpbis-p2-semantics-00		B.2. Since draft-ietf-httpbis-p2-semantics-00
	skipping to change at page 41, line 27		skipping to change at page 43, line 39
	o Move "Product Tokens" section (back) into Part 1, as "token" is		o Move "Product Tokens" section (back) into Part 1, as "token" is
	used in the definition of the Upgrade header.		used in the definition of the Upgrade header.
	o Add explicit references to BNF syntax and rules imported from		o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.		other parts of the specification.
	o Copy definition of delta-seconds from Part6 instead of referencing		o Copy definition of delta-seconds from Part6 instead of referencing
	it.		it.
			B.4. Since draft-ietf-httpbis-p2-semantics-02
			Closed issues:
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
			Allow in 405 responses"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status
			Code Registry"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61>:
			"Redirection vs. Location"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/70>:
			"Cacheability of 303 response"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use
			Proxy"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/105>:
			"Classification for Allow header"
			o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT -
			'store under' vs 'store at'"
			Ongoing work on IANA Message Header Registration
			(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):
			o Reference RFC 3984, and update header registrations for headers
			defined in this document.
			Ongoing work on ABNF conversion
			(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
			o Replace string literals when the string really is case-sensitive
			(method).
	Index		Index
	1		1
	100 Continue (status code) 18		100 Continue (status code) 19
	101 Switching Protocols (status code) 19		101 Switching Protocols (status code) 19
	2		2
	200 OK (status code) 19		200 OK (status code) 19
	201 Created (status code) 19		201 Created (status code) 20
	202 Accepted (status code) 20		202 Accepted (status code) 20
	203 Non-Authoritative Information (status code) 20		203 Non-Authoritative Information (status code) 20
	204 No Content (status code) 20		204 No Content (status code) 21
	205 Reset Content (status code) 21		205 Reset Content (status code) 21
	206 Partial Content (status code) 21		206 Partial Content (status code) 21
	3		3
	300 Multiple Choices (status code) 21		300 Multiple Choices (status code) 22
	301 Moved Permanently (status code) 22		301 Moved Permanently (status code) 22
	302 Found (status code) 22		302 Found (status code) 23
	303 See Other (status code) 23		303 See Other (status code) 23
	304 Not Modified (status code) 23		304 Not Modified (status code) 24
	305 Use Proxy (status code) 23		305 Use Proxy (status code) 24
	306 (Unused) (status code) 24		306 (Unused) (status code) 24
	307 Temporary Redirect (status code) 24		307 Temporary Redirect (status code) 24
	4		4
	400 Bad Request (status code) 25		400 Bad Request (status code) 25
	401 Unauthorized (status code) 25		401 Unauthorized (status code) 25
	402 Payment Required (status code) 25		402 Payment Required (status code) 25
	403 Forbidden (status code) 25		403 Forbidden (status code) 25
	404 Not Found (status code) 25		404 Not Found (status code) 26
	405 Method Not Allowed (status code) 25		405 Method Not Allowed (status code) 26
	406 Not Acceptable (status code) 25		406 Not Acceptable (status code) 26
	407 Proxy Authentication Required (status code) 26		407 Proxy Authentication Required (status code) 26
	408 Request Timeout (status code) 26		408 Request Timeout (status code) 27
	409 Conflict (status code) 26		409 Conflict (status code) 27
	410 Gone (status code) 27		410 Gone (status code) 27
	411 Length Required (status code) 27		411 Length Required (status code) 28
	412 Precondition Failed (status code) 27		412 Precondition Failed (status code) 28
	413 Request Entity Too Large (status code) 27		413 Request Entity Too Large (status code) 28
	414 Request-URI Too Long (status code) 28		414 Request-URI Too Long (status code) 28
	415 Unsupported Media Type (status code) 28		415 Unsupported Media Type (status code) 28
	416 Requested Range Not Satisfiable (status code) 28		416 Requested Range Not Satisfiable (status code) 28
	417 Expectation Failed (status code) 28		417 Expectation Failed (status code) 29
	5		5
	500 Internal Server Error (status code) 28		500 Internal Server Error (status code) 29
	501 Not Implemented (status code) 29		501 Not Implemented (status code) 29
	502 Bad Gateway (status code) 29		502 Bad Gateway (status code) 29
	503 Service Unavailable (status code) 29		503 Service Unavailable (status code) 29
	504 Gateway Timeout (status code) 29		504 Gateway Timeout (status code) 30
	505 HTTP Version Not Supported (status code) 29		505 HTTP Version Not Supported (status code) 30
	A		A
	Allow header 30		Allow header 30
	C		C
	CONNECT method 18		CONNECT method 18
	D		D
	DELETE method 17		DELETE method 17
	E		E
	Expect header 30		Expect header 31
	F		F
	From header 31		From header 31
	G		G
	GET method 14		GET method 14
	Grammar		Grammar
	Allow 30		Allow 30
	delta-seconds 34		delta-seconds 34
	Expect 30		Expect 31
	expect-params 30		expect-params 31
	expectation 30		expectation 31
	expectation-extension 30		expectation-extension 31
	extension-code 10		extension-code 10
	extension-method 8		extension-method 8
	From 31		From 32
	Location 32		Location 32
	Max-Forwards 33		Max-Forwards 33
	Method 8		Method 8
	Reason-Phrase 10		Reason-Phrase 10
	Referer 33		Referer 34
	request-header 9		request-header 9
	response-header 11		response-header 11
	Retry-After 34		Retry-After 34
	Server 34		Server 35
	Status-Code 10		Status-Code 10
	User-Agent 35		User-Agent 35
	H		H
	HEAD method 14		HEAD method 15
	Headers		Headers
	Allow 30		Allow 30
	Expect 30		Expect 31
	From 31		From 31
	Location 32		Location 32
	Max-Forwards 33		Max-Forwards 33
	Referer 33		Referer 33
	Retry-After 34		Retry-After 34
	Server 34		Server 34
	User-Agent 35		User-Agent 35
	L		L
	LINK method 39		LINK method 41
	Location header 32		Location header 32
	M		M
	Max-Forwards header 33		Max-Forwards header 33
	Methods		Methods
	CONNECT 18		CONNECT 18
	DELETE 17		DELETE 17
	GET 14		GET 14
	HEAD 14		HEAD 15
	LINK 39		LINK 41
	OPTIONS 13		OPTIONS 13
	PATCH 39		PATCH 41
	POST 15		POST 15
	PUT 16		PUT 16
	TRACE 17		TRACE 17
	UNLINK 39		UNLINK 41
	O		O
	OPTIONS method 13		OPTIONS method 13
	P		P
	PATCH method 39		PATCH method 41
	POST method 15		POST method 15
	PUT method 16		PUT method 16
	R		R
	Referer header 33		Referer header 33
	Retry-After header 34		Retry-After header 34
	S		S
	Server header 34		Server header 34
	Status Codes		Status Codes
	100 Continue 18		100 Continue 19
	101 Switching Protocols 19		101 Switching Protocols 19
	200 OK 19		200 OK 19
	201 Created 19		201 Created 20
	202 Accepted 20		202 Accepted 20
	203 Non-Authoritative Information 20		203 Non-Authoritative Information 20
	204 No Content 20		204 No Content 21
	205 Reset Content 21		205 Reset Content 21
	206 Partial Content 21		206 Partial Content 21
	300 Multiple Choices 21		300 Multiple Choices 22
	301 Moved Permanently 22		301 Moved Permanently 22
	302 Found 22		302 Found 23
	303 See Other 23		303 See Other 23
	304 Not Modified 23		304 Not Modified 24
	305 Use Proxy 23		305 Use Proxy 24
	306 (Unused) 24		306 (Unused) 24
	307 Temporary Redirect 24		307 Temporary Redirect 24
	400 Bad Request 25		400 Bad Request 25
	401 Unauthorized 25		401 Unauthorized 25
	402 Payment Required 25		402 Payment Required 25
	403 Forbidden 25		403 Forbidden 25
	404 Not Found 25		404 Not Found 26
	405 Method Not Allowed 25		405 Method Not Allowed 26
	406 Not Acceptable 25		406 Not Acceptable 26
	407 Proxy Authentication Required 26		407 Proxy Authentication Required 26
	408 Request Timeout 26		408 Request Timeout 27
	409 Conflict 26		409 Conflict 27
	410 Gone 27		410 Gone 27
	411 Length Required 27		411 Length Required 28
	412 Precondition Failed 27		412 Precondition Failed 28
	413 Request Entity Too Large 27		413 Request Entity Too Large 28
	414 Request-URI Too Long 28		414 Request-URI Too Long 28
	415 Unsupported Media Type 28		415 Unsupported Media Type 28
	416 Requested Range Not Satisfiable 28		416 Requested Range Not Satisfiable 28
	417 Expectation Failed 28		417 Expectation Failed 29
	500 Internal Server Error 28		500 Internal Server Error 29
	501 Not Implemented 29		501 Not Implemented 29
	502 Bad Gateway 29		502 Bad Gateway 29
	503 Service Unavailable 29		503 Service Unavailable 29
	504 Gateway Timeout 29		504 Gateway Timeout 30
	505 HTTP Version Not Supported 29		505 HTTP Version Not Supported 30
	T		T
	TRACE method 17		TRACE method 17
	U		U
	UNLINK method 39		UNLINK method 41
	User-Agent header 35		User-Agent header 35
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	skipping to change at page 48, line 44		skipping to change at line 2290
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 88 change blocks.
	180 lines changed or deleted		326 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/