draft-ietf-httpbis-p1-messaging-08.txt		draft-ietf-httpbis-p1-messaging-latest.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Updates: 2817 (if approved) One Laptop per Child		Updates: 2817 (if approved) One Laptop per Child
	Intended status: Standards Track J. Mogul		Intended status: Standards Track J. Mogul
	Expires: April 29, 2010 HP		Expires: August 6, 2010 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
	October 26, 2009		February 2, 2010
	HTTP/1.1, part 1: URIs, Connections, and Message Parsing		HTTP/1.1, part 1: URIs, Connections, and Message Parsing
	draft-ietf-httpbis-p1-messaging-08		draft-ietf-httpbis-p1-messaging-latest
	Status of this Memo		Abstract
			The Hypertext Transfer Protocol (HTTP) is an application-level
			protocol for distributed, collaborative, hypertext information
			systems. HTTP has been in use by the World Wide Web global
			information initiative since 1990. This document is Part 1 of the
			seven-part specification that defines the protocol referred to as
			"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
			an overview of HTTP and its associated terminology, defines the
			"http" and "https" Uniform Resource Identifier (URI) schemes, defines
			the generic message syntax and parsing requirements for HTTP message
			frames, and describes general security concerns for implementations.
			Editorial Note (To be removed by RFC Editor)
			Discussion of this draft should take place on the HTTPBIS working
			group mailing list (ietf-http-wg@w3.org). The current issues list is
			at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
			documents (including fancy diffs) can be found at
			<http://tools.ietf.org/wg/httpbis/>.
			The changes in this draft are summarized in Appendix D.10.
			Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79.
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	skipping to change at page 2, line 4		skipping to change at page 2, line 16
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	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 April 29, 2010.		This Internet-Draft will expire on August 6, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	The Hypertext Transfer Protocol (HTTP) is an application-level		described in the BSD License.
	protocol for distributed, collaborative, hypertext information
	systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 1 of the
	seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
	an overview of HTTP and its associated terminology, defines the
	"http" and "https" Uniform Resource Identifier (URI) schemes, defines
	the generic message syntax and parsing requirements for HTTP message
	frames, and describes general security concerns for implementations.
	Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.9.		This document may contain material from IETF Documents or IETF
			Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 7
	1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7		1.2.1. ABNF Extension: #rule . . . . . . . . . . . . . . . . 7
	1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8		1.2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . 8
	1.2.3. ABNF Rules defined in other Parts of the		1.2.3. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 9		Specification . . . . . . . . . . . . . . . . . . . . 10
	2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10		2. HTTP architecture . . . . . . . . . . . . . . . . . . . . . . 10
	2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10		2.1. Client/Server Operation . . . . . . . . . . . . . . . . . 10
	2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 11		2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 12
	2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 12		2.3. Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	2.4. Transport Independence . . . . . . . . . . . . . . . . . . 13		2.4. Transport Independence . . . . . . . . . . . . . . . . . . 14
	2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14		2.5. HTTP Version . . . . . . . . . . . . . . . . . . . . . . . 14
	2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 15		2.6. Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
	2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16		2.6.1. http URI scheme . . . . . . . . . . . . . . . . . . . 16
	2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17		2.6.2. https URI scheme . . . . . . . . . . . . . . . . . . . 17
	2.6.3. http and https URI Normalization and Comparison . . . 17		2.6.3. http and https URI Normalization and Comparison . . . 18
	3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 18		3. HTTP Message . . . . . . . . . . . . . . . . . . . . . . . . . 19
	3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19		3.1. Message Parsing Robustness . . . . . . . . . . . . . . . . 19
	3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 19		3.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 20
	3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 21		3.3. Message Body . . . . . . . . . . . . . . . . . . . . . . . 22
	3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 22		3.4. Message Length . . . . . . . . . . . . . . . . . . . . . . 23
	3.5. General Header Fields . . . . . . . . . . . . . . . . . . 23		3.5. General Header Fields . . . . . . . . . . . . . . . . . . 24
	4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 24		4. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 24		4.1. Request-Line . . . . . . . . . . . . . . . . . . . . . . . 25
	4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 24		4.1.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 25
	4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 24		4.1.2. request-target . . . . . . . . . . . . . . . . . . . . 25
	4.2. The Resource Identified by a Request . . . . . . . . . . . 26		4.2. The Resource Identified by a Request . . . . . . . . . . . 27
	5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		5. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 27		5.1. Status-Line . . . . . . . . . . . . . . . . . . . . . . . 28
	5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28		5.1.1. Status Code and Reason Phrase . . . . . . . . . . . . 28
	6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28		6. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 29
	6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 28		6.1. Date/Time Formats: Full Date . . . . . . . . . . . . . . . 29
	6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31		6.2. Transfer Codings . . . . . . . . . . . . . . . . . . . . . 31
	6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32		6.2.1. Chunked Transfer Coding . . . . . . . . . . . . . . . 32
	6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34		6.2.2. Compression Codings . . . . . . . . . . . . . . . . . 34
	6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35		6.2.3. Transfer Coding Registry . . . . . . . . . . . . . . . 35
	6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35		6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 35
	6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36		6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 36
	7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36		7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 36
	7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36		7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 36
	7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36		7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 36
	7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37		7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 37
	skipping to change at page 4, line 23		skipping to change at page 4, line 23
	8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 44		8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 44
	8.5. Use of HTTP by media type specification . . . . . . . . . 44		8.5. Use of HTTP by media type specification . . . . . . . . . 44
	9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 44		9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 44
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 44		9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 44
	9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 45		9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 45
	9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 46		9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
	9.3.1. Clockless Origin Server Operation . . . . . . . . . . 47		9.3.1. Clockless Origin Server Operation . . . . . . . . . . 47
	9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 47		9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
	9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48		9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
	9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 49		9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 49
	9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 49		9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 50
	9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 50		9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 50
	9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 51		9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 51
	9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 52		9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
	10.1. Message Header Registration . . . . . . . . . . . . . . . 53		10.1. Message Header Registration . . . . . . . . . . . . . . . 54
	10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 54		10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 54
	10.3. Internet Media Type Registrations . . . . . . . . . . . . 54		10.3. Internet Media Type Registrations . . . . . . . . . . . . 54
	10.3.1. Internet Media Type message/http . . . . . . . . . . . 54		10.3.1. Internet Media Type message/http . . . . . . . . . . . 54
	10.3.2. Internet Media Type application/http . . . . . . . . . 55		10.3.2. Internet Media Type application/http . . . . . . . . . 56
	10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 56		10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 57
	10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 57		10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 57
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 57		11. Security Considerations . . . . . . . . . . . . . . . . . . . 57
	11.1. Personal Information . . . . . . . . . . . . . . . . . . . 57		11.1. Personal Information . . . . . . . . . . . . . . . . . . . 58
	11.2. Abuse of Server Log Information . . . . . . . . . . . . . 58		11.2. Abuse of Server Log Information . . . . . . . . . . . . . 58
	11.3. Attacks Based On File and Path Names . . . . . . . . . . . 58		11.3. Attacks Based On File and Path Names . . . . . . . . . . . 58
	11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 58		11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 58
	11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 59		11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 59
	11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 60		11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 60
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 61		13.1. Normative References . . . . . . . . . . . . . . . . . . . 61
	13.2. Informative References . . . . . . . . . . . . . . . . . . 62		13.2. Informative References . . . . . . . . . . . . . . . . . . 63
	Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 64		Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 65
	Appendix B. Compatibility with Previous Versions . . . . . . . . 65		Appendix B. Compatibility with Previous Versions . . . . . . . . 65
	B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 66		B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 66
	B.1.1. Changes to Simplify Multi-homed Web Servers and		B.1.1. Changes to Simplify Multi-homed Web Servers and
	Conserve IP Addresses . . . . . . . . . . . . . . . . 66		Conserve IP Addresses . . . . . . . . . . . . . . . . 66
	B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 67		B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 67
	B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 67		B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 68
	B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 68		B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 68
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 69		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 69
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 73		publication) . . . . . . . . . . . . . . . . . . . . 73
	D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 73		D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 74
	D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 73		D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 74
	D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75		D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75
	D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76		D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76
	D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 76		D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 77
	D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77		D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77
	D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 77		D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 78
	D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 78		D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 79
	D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79		D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79		D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 80
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	request/response protocol that uses extensible semantics and MIME-		request/response protocol that uses extensible semantics and MIME-
	like message payloads for flexible interaction with network-based		like message payloads for flexible interaction with network-based
	hypertext information systems. HTTP relies upon the Uniform Resource		hypertext information systems. HTTP relies upon the Uniform Resource
	Identifier (URI) standard [RFC3986] to indicate request targets and		Identifier (URI) standard [RFC3986] to indicate request targets and
	relationships between resources. Messages are passed in a format		relationships between resources. Messages are passed in a format
	skipping to change at page 7, line 33		skipping to change at page 7, line 33
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234].		notation of [RFC5234].
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), VCHAR (any visible [USASCII]		sequence of data), SP (space), VCHAR (any visible [USASCII]
	character), and WSP (whitespace).		character), and WSP (whitespace).
			As a syntactical convention, ABNF rule names prefixed with "obs-"
			denote "obsolete" grammar rules that appear for historical reasons.
	1.2.1. ABNF Extension: #rule		1.2.1. ABNF Extension: #rule
	One extension to the ABNF rules of [RFC5234] is used to improve		The #rule extension to the ABNF rules of [RFC5234] is used to improve
	readability.		readability.
	A construct "#" is defined, similar to "*", for defining lists of		A construct "#" is defined, similar to "*", for defining comma-
	elements. The full form is "<n>#<m>element" indicating at least <n>		delimited lists of elements. The full form is "<n>#<m>element"
	and at most <m> elements, each separated by a single comma (",") and		indicating at least <n> and at most <m> elements, each separated by a
	optional whitespace (OWS).		single comma (",") and optional whitespace (OWS, Section 1.2.2).
	Thus,		Thus,
	1#element => element *( OWS "," OWS element )		1#element => element *( OWS "," OWS element )
	and:		and:
	#element => [ 1#element ]		#element => [ 1#element ]
	and for n >= 1 and m > 1:		and for n >= 1 and m > 1:
	<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )		<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
	For compatibility with legacy list rules, recipients SHOULD accept		For compatibility with legacy list rules, recipients SHOULD accept
	empty list elements. In other words, consumers would follow the list		empty list elements. In other words, consumers would follow the list
	productions:		productions:
	#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]		#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
	skipping to change at page 8, line 16		skipping to change at page 8, line 20
	<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )		<n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )
	For compatibility with legacy list rules, recipients SHOULD accept		For compatibility with legacy list rules, recipients SHOULD accept
	empty list elements. In other words, consumers would follow the list		empty list elements. In other words, consumers would follow the list
	productions:		productions:
	#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]		#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
	1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )		1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
			Note that empty elements do not contribute to the count of elements
			present, though.
			For example, given these ABNF productions:
			example-list = 1#example-list-elmt
			example-list-elmt = token ; see Section 1.2.2
			Then these are valid values for example-list (not including the
			double quotes, which are present for delimitation only):
			"foo,bar"
			" foo ,bar,"
			" foo , ,bar,charlie "
			"foo ,bar, charlie "
			But these values would be invalid, as at least one non-empty element
			is required:
			""
			","
			", ,"
	Appendix C shows the collected ABNF, with the list rules expanded as		Appendix C shows the collected ABNF, with the list rules expanded as
	explained above.		explained above.
	1.2.2. Basic Rules		1.2.2. Basic Rules
	HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all		HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
	protocol elements except the entity-body (see Appendix A for tolerant		protocol elements except the entity-body (see Appendix A for tolerant
	applications). The end-of-line marker within an entity-body is		applications). The end-of-line marker within an entity-body is
	defined by its associated media type, as described in Section 2.3 of		defined by its associated media type, as described in Section 2.3 of
	[Part3].		[Part3].
	skipping to change at page 9, line 14		skipping to change at page 9, line 37
	OWS = *( [ obs-fold ] WSP )		OWS = *( [ obs-fold ] WSP )
	; "optional" whitespace		; "optional" whitespace
	RWS = 1*( [ obs-fold ] WSP )		RWS = 1*( [ obs-fold ] WSP )
	; "required" whitespace		; "required" whitespace
	BWS = OWS		BWS = OWS
	; "bad" whitespace		; "bad" whitespace
	obs-fold = CRLF		obs-fold = CRLF
	; see Section 3.2		; see Section 3.2
	Many HTTP/1.1 header field values consist of words separated by		Many HTTP/1.1 header field values consist of words (token or quoted-
	whitespace or special characters. These special characters MUST be		string) separated by whitespace or special characters. These special
	in a quoted string to be used within a parameter value (as defined in		characters MUST be in a quoted string to be used within a parameter
	Section 6.2).		value (as defined in Section 6.2).
			token = 1*tchar
	tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"		tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
	/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"		/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
	/ DIGIT / ALPHA		/ DIGIT / ALPHA
			; any VCHAR, except special
	token = 1*tchar		special = "(" / ")" / "<" / ">" / "@" / ","
			/ ";" / ":" / "\" / DQUOTE / "/" / "["
			/ "]" / "?" / "=" / "{" / "}"
	A string of text is parsed as a single word if it is quoted using		A string of text is parsed as a single word if it is quoted using
	double-quote marks.		double-quote marks.
	quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE		quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
	qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text		qdtext = OWS / %x21 / %x23-5B / %x5D-7E / obs-text
	; OWS / <VCHAR except DQUOTE and "\"> / obs-text		; OWS / <VCHAR except DQUOTE and "\"> / obs-text
	obs-text = %x80-FF		obs-text = %x80-FF
	The backslash character ("\") can be used as a single-character		The backslash character ("\") can be used as a single-character
	skipping to change at page 20, line 4		skipping to change at page 20, line 40
	No whitespace is allowed between the header field name and colon.		No whitespace is allowed between the header field name and colon.
	For security reasons, any request message received containing such		For security reasons, any request message received containing such
	whitespace MUST be rejected with a response code of 400 (Bad		whitespace MUST be rejected with a response code of 400 (Bad
	Request). A proxy MUST remove any such whitespace from a response		Request). A proxy MUST remove any such whitespace from a response
	message before forwarding the message downstream.		message before forwarding the message downstream.
	A field value MAY be preceded by optional whitespace (OWS); a single		A field value MAY be preceded by optional whitespace (OWS); a single
	SP is preferred. The field value does not include any leading or		SP is preferred. The field value does not include any leading or
	trailing white space: OWS occurring before the first non-whitespace		trailing white space: OWS occurring before the first non-whitespace
	character of the field value or after the last non-whitespace		character of the field value or after the last non-whitespace
	character of the field value is ignored and SHOULD be removed without		character of the field value is ignored and SHOULD be removed before
	changing the meaning of the header field.		further processing (as this does not change the meaning of the header
			field).
	The order in which header fields with differing field names are		The order in which header fields with differing field names are
	received is not significant. However, it is "good practice" to send		received is not significant. However, it is "good practice" to send
	header fields that contain control data first, such as Host on		header fields that contain control data first, such as Host on
	requests and Date on responses, so that implementations can decide		requests and Date on responses, so that implementations can decide
	when not to handle a message as early as possible. A server MUST		when not to handle a message as early as possible. A server MUST
	wait until the entire header section is received before interpreting		wait until the entire header section is received before interpreting
	a request message, since later header fields might include		a request message, since later header fields might include
	conditionals, authentication credentials, or deliberately misleading		conditionals, authentication credentials, or deliberately misleading
	duplicate header fields that would impact request processing.		duplicate header fields that would impact request processing.
	skipping to change at page 20, line 28		skipping to change at page 21, line 17
	message unless the entire field value for that header field is		message unless the entire field value for that header field is
	defined as a comma-separated list [i.e., #(values)]. Multiple header		defined as a comma-separated list [i.e., #(values)]. Multiple header
	fields with the same field name can be combined into one "field-name:		fields with the same field name can be combined into one "field-name:
	field-value" pair, without changing the semantics of the message, by		field-value" pair, without changing the semantics of the message, by
	appending each subsequent field value to the combined field value in		appending each subsequent field value to the combined field value in
	order, separated by a comma. The order in which header fields with		order, separated by a comma. The order in which header fields with
	the same field name are received is therefore significant to the		the same field name are received is therefore significant to the
	interpretation of the combined field value; a proxy MUST NOT change		interpretation of the combined field value; a proxy MUST NOT change
	the order of these field values when forwarding a message.		the order of these field values when forwarding a message.
	Note: the "Set-Cookie" header as implemented in practice (as		Note: The "Set-Cookie" header as implemented in practice (as
	opposed to how it is specified in [RFC2109]) can occur multiple		opposed to how it is specified in [RFC2109]) can occur multiple
	times, but does not use the list syntax, and thus cannot be		times, but does not use the list syntax, and thus cannot be
	combined into a single line. (See Appendix A.2.3 of [Kri2001] for		combined into a single line. (See Appendix A.2.3 of [Kri2001] for
	details.) Also note that the Set-Cookie2 header specified in		details.) Also note that the Set-Cookie2 header specified in
	[RFC2965] does not share this problem.		[RFC2965] does not share this problem.
	Historically, HTTP header field values could be extended over		Historically, HTTP header field values could be extended over
	multiple lines by preceding each extra line with at least one space		multiple lines by preceding each extra line with at least one space
	or horizontal tab character (line folding). This specification		or horizontal tab character (line folding). This specification
	deprecates such line folding except within the message/http media		deprecates such line folding except within the message/http media
	skipping to change at page 22, line 12		skipping to change at page 22, line 49
	either ignore the message-body or respond with an appropriate error		either ignore the message-body or respond with an appropriate error
	message (e.g., 413). A proxy or gateway, when presented the same		message (e.g., 413). A proxy or gateway, when presented the same
	request, SHOULD either forward the request inbound with the message-		request, SHOULD either forward the request inbound with the message-
	body or ignore the message-body when determining a response.		body or ignore the message-body when determining a response.
	For response messages, whether or not a message-body is included with		For response messages, whether or not a message-body is included with
	a message is dependent on both the request method and the response		a message is dependent on both the request method and the response
	status code (Section 5.1.1). All responses to the HEAD request		status code (Section 5.1.1). All responses to the HEAD request
	method MUST NOT include a message-body, even though the presence of		method MUST NOT include a message-body, even though the presence of
	entity-header fields might lead one to believe they do. All 1xx		entity-header fields might lead one to believe they do. All 1xx
	(informational), 204 (No Content), and 304 (Not Modified) responses		(Informational), 204 (No Content), and 304 (Not Modified) responses
	MUST NOT include a message-body. All other responses do include a		MUST NOT include a message-body. All other responses do include a
	message-body, although it MAY be of zero length.		message-body, although it MAY be of zero length.
	3.4. Message Length		3.4. Message Length
	The transfer-length of a message is the length of the message-body as		The transfer-length of a message is the length of the message-body as
	it appears in the message; that is, after any transfer-codings have		it appears in the message; that is, after any transfer-codings have
	been applied. When a message-body is included with a message, the		been applied. When a message-body is included with a message, the
	transfer-length of that body is determined by one of the following		transfer-length of that body is determined by one of the following
	(in order of precedence):		(in order of precedence):
	skipping to change at page 36, line 19		skipping to change at page 36, line 19
	version portion of the product value).		version portion of the product value).
	6.4. Quality Values		6.4. Quality Values
	Both transfer codings (TE request header, Section 9.5) and content		Both transfer codings (TE request header, Section 9.5) and content
	negotiation (Section 4 of [Part3]) use short "floating point" numbers		negotiation (Section 4 of [Part3]) use short "floating point" numbers
	to indicate the relative importance ("weight") of various negotiable		to indicate the relative importance ("weight") of various negotiable
	parameters. A weight is normalized to a real number in the range 0		parameters. A weight is normalized to a real number in the range 0
	through 1, where 0 is the minimum and 1 the maximum value. If a		through 1, where 0 is the minimum and 1 the maximum value. If a
	parameter has a quality value of 0, then content with this parameter		parameter has a quality value of 0, then content with this parameter
	is `not acceptable' for the client. HTTP/1.1 applications MUST NOT		is "not acceptable" for the client. HTTP/1.1 applications MUST NOT
	generate more than three digits after the decimal point. User		generate more than three digits after the decimal point. User
	configuration of these values SHOULD also be limited in this fashion.		configuration of these values SHOULD also be limited in this fashion.
	qvalue = ( "0" [ "." 0*3DIGIT ] )		qvalue = ( "0" [ "." 0*3DIGIT ] )
	/ ( "1" [ "." 0*3("0") ] )		/ ( "1" [ "." 0*3("0") ] )
	Note: "Quality values" is a misnomer, since these values merely		Note: "Quality values" is a misnomer, since these values merely
	represent relative degradation in desired quality.		represent relative degradation in desired quality.
	7. Connections		7. Connections
	skipping to change at page 45, line 7		skipping to change at page 45, line 7
	Message headers listed in the Connection header MUST NOT include end-		Message headers listed in the Connection header MUST NOT include end-
	to-end headers, such as Cache-Control.		to-end headers, such as Cache-Control.
	HTTP/1.1 defines the "close" connection option for the sender to		HTTP/1.1 defines the "close" connection option for the sender to
	signal that the connection will be closed after completion of the		signal that the connection will be closed after completion of the
	response. For example,		response. For example,
	Connection: close		Connection: close
	in either the request or the response header fields indicates that		in either the request or the response header fields indicates that
	the connection SHOULD NOT be considered `persistent' (Section 7.1)		the connection SHOULD NOT be considered "persistent" (Section 7.1)
	after the current request/response is complete.		after the current request/response is complete.
	An HTTP/1.1 client that does not support persistent connections MUST		An HTTP/1.1 client that does not support persistent connections MUST
	include the "close" connection option in every request message.		include the "close" connection option in every request message.
	An HTTP/1.1 server that does not support persistent connections MUST		An HTTP/1.1 server that does not support persistent connections MUST
	include the "close" connection option in every response message that		include the "close" connection option in every response message that
	does not have a 1xx (informational) status code.		does not have a 1xx (Informational) status code.
	A system receiving an HTTP/1.0 (or lower-version) message that		A system receiving an HTTP/1.0 (or lower-version) message that
	includes a Connection header MUST, for each connection-token in this		includes a Connection header MUST, for each connection-token in this
	field, remove and ignore any header field(s) from the message with		field, remove and ignore any header field(s) from the message with
	the same name as the connection-token. This protects against		the same name as the connection-token. This protects against
	mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.		mistaken forwarding of such header fields by pre-HTTP/1.1 proxies.
	See Appendix B.2.		See Appendix B.2.
	9.2. Content-Length		9.2. Content-Length
	skipping to change at page 46, line 8		skipping to change at page 46, line 8
	Note that the meaning of this field is significantly different from		Note that the meaning of this field is significantly different from
	the corresponding definition in MIME, where it is an optional field		the corresponding definition in MIME, where it is an optional field
	used within the "message/external-body" content-type. In HTTP, it		used within the "message/external-body" content-type. In HTTP, it
	SHOULD be sent whenever the message's length can be determined prior		SHOULD be sent whenever the message's length can be determined prior
	to being transferred, unless this is prohibited by the rules in		to being transferred, unless this is prohibited by the rules in
	Section 3.4.		Section 3.4.
	9.3. Date		9.3. Date
	The "Date" general-header field represents the date and time at which		The "Date" general-header field represents the date and time at which
	the message was originated, having the same semantics as orig-date in		the message was originated, having the same semantics as the
	Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as		Origination Date Field (orig-date) defined in Section 3.6.1 of
	described in Section 6.1; it MUST be sent in rfc1123-date format.		[RFC5322]. The field value is an HTTP-date, as described in
			Section 6.1; it MUST be sent in rfc1123-date format.
	Date = "Date" ":" OWS Date-v		Date = "Date" ":" OWS Date-v
	Date-v = HTTP-date		Date-v = HTTP-date
	An example is		An example is
	Date: Tue, 15 Nov 1994 08:12:31 GMT		Date: Tue, 15 Nov 1994 08:12:31 GMT
	Origin servers MUST include a Date header field in all responses,		Origin servers MUST include a Date header field in all responses,
	except in these cases:		except in these cases:
	skipping to change at page 61, line 27		skipping to change at page 61, line 37
	[ISO-8859-1]		[ISO-8859-1]
	International Organization for Standardization,		International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded graphic		"Information technology -- 8-bit single-byte coded graphic
	character sets -- Part 1: Latin alphabet No. 1", ISO/		character sets -- Part 1: Latin alphabet No. 1", ISO/
	IEC 8859-1:1998, 1998.		IEC 8859-1:1998, 1998.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part2] 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 2: Message		and J. Reschke, Ed., "HTTP/1.1, part 2: Message
	Semantics", draft-ietf-httpbis-p2-semantics-08 (work in		Semantics", draft-ietf-httpbis-p2-semantics-latest (work
	progress), October 2009.		in progress), February 2010.
	[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-08		and Content Negotiation",
	(work in progress), October 2009.		draft-ietf-httpbis-p3-payload-latest (work in progress),
			February 2010.
	[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-08 (work		Partial Responses", draft-ietf-httpbis-p5-range-latest
	in progress), October 2009.		(work in progress), February 2010.
	[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-08 (work in		6: Caching", draft-ietf-httpbis-p6-cache-latest (work in
	progress), October 2009.		progress), February 2010.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950, May 1996.		Specification version 3.3", RFC 1950, May 1996.
	RFC 1950 is an Informational RFC, thus it may be less		RFC 1950 is an Informational RFC, thus it may be less
	stable than this specification. On the other hand, this		stable than this specification. On the other hand, this
	downward reference was present since the publication of		downward reference was present since the publication of
	RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to		RFC 2068 in 1997 ([RFC2068]), therefore it is unlikely to
	cause problems in practice. See also [BCP97].		cause problems in practice. See also [BCP97].
	skipping to change at page 72, line 42		skipping to change at page 73, line 8
	received-protocol = [ protocol-name "/" ] protocol-version		received-protocol = [ protocol-name "/" ] protocol-version
	relative-part = <relative-part, defined in [RFC3986], Section 4.2>		relative-part = <relative-part, defined in [RFC3986], Section 4.2>
	request-header = <request-header, defined in [Part2], Section 3>		request-header = <request-header, defined in [Part2], Section 3>
	request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )		request-target = "*" / absolute-URI / ( path-absolute [ "?" query ] )
	/ authority		/ authority
	response-header = <response-header, defined in [Part2], Section 5>		response-header = <response-header, defined in [Part2], Section 5>
	rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT		rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
	rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT		rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
	second = 2DIGIT		second = 2DIGIT
			special = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
			DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}"
	start-line = Request-Line / Status-Line		start-line = Request-Line / Status-Line
	t-codings = "trailers" / ( transfer-extension [ te-params ] )		t-codings = "trailers" / ( transfer-extension [ te-params ] )
	tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /		tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
	"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA		"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
	te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]		te-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
	te-params = OWS ";" OWS "q=" qvalue *te-ext		te-params = OWS ";" OWS "q=" qvalue *te-ext
	time-of-day = hour ":" minute ":" second		time-of-day = hour ":" minute ":" second
	token = 1*tchar		token = 1*tchar
	trailer-part = *( entity-header CRLF )		trailer-part = *( entity-header CRLF )
	skipping to change at page 73, line 29		skipping to change at page 73, line 45
	; HTTP-message defined but not used		; HTTP-message defined but not used
	; Host defined but not used		; Host defined but not used
	; Request defined but not used		; Request defined but not used
	; Response defined but not used		; Response defined but not used
	; TE defined but not used		; TE defined but not used
	; URI defined but not used		; URI defined but not used
	; URI-reference defined but not used		; URI-reference defined but not used
	; http-URI defined but not used		; http-URI defined but not used
	; https-URI defined but not used		; https-URI defined but not used
	; partial-URI defined but not used		; partial-URI defined but not used
			; special defined but not used
	Appendix D. Change Log (to be removed by RFC Editor before publication)		Appendix D. Change Log (to be removed by RFC Editor before publication)
	D.1. Since RFC2616		D.1. Since RFC2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	D.2. Since draft-ietf-httpbis-p1-messaging-00		D.2. Since draft-ietf-httpbis-p1-messaging-00
	Closed issues:		Closed issues:
	skipping to change at page 79, line 44		skipping to change at page 80, line 16
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow		o <http://tools.ietf.org/wg/httpbis/trac/ticket/194>: "disallow
	control characters in quoted-pair"		control characters in quoted-pair"
	Partly resolved issues:		Partly resolved issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
	requirements wrt Transfer-Coding values" (add the IANA		requirements wrt Transfer-Coding values" (add the IANA
	Considerations subsection)		Considerations subsection)
			D.10. Since draft-ietf-httpbis-p1-messaging-08
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/201>: "header
			parsing, treatment of leading and trailing OWS"
			Partly resolved issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
			"word" when talking about header structure"
	Index		Index
	A		A
	application/http Media Type 55		application/http Media Type 56
	C		C
	cache 12		cache 13
	cacheable 13		cacheable 14
	chunked (Coding Format) 32		chunked (Coding Format) 32
	client 10		client 10
	Coding Format		Coding Format
	chunked 32		chunked 32
	compress 34		compress 34
	deflate 35		deflate 35
	gzip 35		gzip 35
	compress (Coding Format) 34		compress (Coding Format) 34
	connection 10		connection 10
	Connection header 44		Connection header 44
	Content-Length header 45		Content-Length header 45
	D		D
	Date header 46		Date header 46
	deflate (Coding Format) 35		deflate (Coding Format) 35
	downstream 12		downstream 12
	G		G
	gateway 12		gateway 13
	Grammar		Grammar
	absolute-URI 15		absolute-URI 16
	ALPHA 7		ALPHA 7
	asctime-date 31		asctime-date 31
	attribute 31		attribute 32
	authority 15		authority 16
	BWS 9		BWS 9
	chunk 33		chunk 33
	chunk-data 33		chunk-data 33
	chunk-ext 33		chunk-ext 33
	chunk-ext-name 33		chunk-ext-name 33
	chunk-ext-val 33		chunk-ext-val 33
	chunk-size 33		chunk-size 33
	Chunked-Body 33		Chunked-Body 33
	comment 21		comment 21
	Connection 44		Connection 44
	skipping to change at page 80, line 51		skipping to change at page 81, line 35
	Connection-v 44		Connection-v 44
	Content-Length 45		Content-Length 45
	Content-Length-v 45		Content-Length-v 45
	CR 7		CR 7
	CRLF 7		CRLF 7
	ctext 21		ctext 21
	CTL 7		CTL 7
	Date 46		Date 46
	Date-v 46		Date-v 46
	date1 30		date1 30
	date2 31		date2 32
	date3 31		date3 32
	day 30		day 30
	day-name 30		day-name 30
	day-name-l 30		day-name-l 30
	DIGIT 7		DIGIT 7
	DQUOTE 7		DQUOTE 7
	extension-code 28		extension-code 29
	extension-method 24		extension-method 25
	field-content 19		field-content 20
	field-name 19		field-name 20
	field-value 19		field-value 20
	general-header 23		general-header 24
	GMT 30		GMT 30
	header-field 19		header-field 20
	HEXDIG 7		HEXDIG 7
	Host 47		Host 47
	Host-v 47		Host-v 47
	hour 30		hour 30
	HTTP-date 29		HTTP-date 30
	HTTP-message 18		HTTP-message 19
	HTTP-Prot-Name 14		HTTP-Prot-Name 15
	http-URI 16		http-URI 16
	HTTP-Version 14		HTTP-Version 15
	https-URI 17		https-URI 18
	last-chunk 33		last-chunk 33
	LF 7		LF 7
	message-body 21		message-body 22
	Method 24		Method 25
	minute 30		minute 30
	month 30		month 30
	obs-date 30		obs-date 31
	obs-text 9		obs-text 10
	OCTET 7		OCTET 7
	OWS 9		OWS 9
	path-absolute 15		path-absolute 16
	port 15		port 16
	product 35		product 35
	product-version 35		product-version 35
	protocol-name 52		protocol-name 52
	protocol-version 52		protocol-version 52
	pseudonym 52		pseudonym 52
	qdtext 9		qdtext 10
	qdtext-nf 33		qdtext-nf 33
	query 15		query 16
	quoted-cpair 21		quoted-cpair 22
	quoted-pair 9		quoted-pair 10
	quoted-str-nf 33		quoted-str-nf 33
	quoted-string 9		quoted-string 10
	qvalue 36		qvalue 36
	Reason-Phrase 28		Reason-Phrase 29
	received-by 52		received-by 52
	received-protocol 52		received-protocol 52
	Request 24		Request 25
	Request-Line 24		Request-Line 25
	request-target 24		request-target 25
	Response 27		Response 28
	rfc850-date 31		rfc850-date 31
	rfc1123-date 30		rfc1123-date 30
	RWS 9		RWS 9
	second 30		second 30
	SP 7		SP 7
	Status-Code 28		special 9
	Status-Line 27		Status-Code 29
			Status-Line 28
	t-codings 48		t-codings 48
	tchar 9		tchar 9
	TE 48		TE 48
	te-ext 48		te-ext 48
	te-params 48		te-params 48
	TE-v 48		TE-v 48
	time-of-day 30		time-of-day 30
	token 9		token 9
	Trailer 49		Trailer 49
	trailer-part 33		trailer-part 33
	Trailer-v 49		Trailer-v 49
	transfer-coding 31		transfer-coding 31
	Transfer-Encoding 50		Transfer-Encoding 50
	Transfer-Encoding-v 50		Transfer-Encoding-v 50
	transfer-extension 31		transfer-extension 31
	transfer-parameter 31		transfer-parameter 32
	Upgrade 50		Upgrade 50
	Upgrade-v 50		Upgrade-v 50
	uri-host 15		uri-host 16
	URI-reference 15		URI-reference 16
	value 31		value 32
	VCHAR 7		VCHAR 7
	Via 52		Via 52
	Via-v 52		Via-v 52
	WSP 7		WSP 7
	year 30		year 30
	gzip (Coding Format) 35		gzip (Coding Format) 35
	H		H
	header field 18		header field 19
	header section 18		header section 19
	Headers		Headers
	Connection 44		Connection 44
	Content-Length 45		Content-Length 45
	Date 46		Date 46
	Host 47		Host 47
	TE 48		TE 48
	Trailer 49		Trailer 49
	Transfer-Encoding 49		Transfer-Encoding 50
	Upgrade 50		Upgrade 50
	Via 52		Via 52
	headers 18		headers 19
	Host header 47		Host header 47
	http URI scheme 16		http URI scheme 16
	https URI scheme 17		https URI scheme 17
	I		I
	inbound 12		inbound 12
	M		M
	Media Type		Media Type
	application/http 55		application/http 56
	message/http 54		message/http 54
	message 10		message 11
	message/http Media Type 54		message/http Media Type 54
	O		O
	origin server 10		origin server 11
	outbound 12		outbound 12
	P		P
	proxy 12		proxy 12
	R		R
	request 10		request 11
	resource 15		resource 16
	response 10		response 11
	reverse proxy 12		reverse proxy 13
	S		S
	server 10		server 10
	T		T
	TE header 48		TE header 48
	Trailer header 49		Trailer header 49
	Transfer-Encoding header 49		Transfer-Encoding header 50
	tunnel 12		tunnel 13
	U		U
	Upgrade header 50		Upgrade header 50
	upstream 12		upstream 12
	URI scheme		URI scheme
	http 16		http 16
	https 17		https 17
	user agent 10		user agent 11
	V		V
	Via header 52		Via header 52
	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
End of changes. 81 change blocks.
	165 lines changed or deleted		221 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/