draft-ietf-httpbis-p1-messaging-08.txt		draft-ietf-httpbis-p1-messaging-09.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: September 9, 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		March 8, 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-09
	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 September 9, 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
	7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38		7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 38
	7.1.4. Practical Considerations . . . . . . . . . . . . . . . 39		7.1.4. Practical Considerations . . . . . . . . . . . . . . . 41
	7.2. Message Transmission Requirements . . . . . . . . . . . . 40		7.2. Message Transmission Requirements . . . . . . . . . . . . 42
	7.2.1. Persistent Connections and Flow Control . . . . . . . 40		7.2.1. Persistent Connections and Flow Control . . . . . . . 42
	7.2.2. Monitoring Connections for Error Status Messages . . . 40		7.2.2. Monitoring Connections for Error Status Messages . . . 42
	7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 40		7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 42
	7.2.4. Client Behavior if Server Prematurely Closes		7.2.4. Client Behavior if Server Prematurely Closes
	Connection . . . . . . . . . . . . . . . . . . . . . . 42		Connection . . . . . . . . . . . . . . . . . . . . . . 44
	8. Miscellaneous notes that may disappear . . . . . . . . . . . . 43		8. Miscellaneous notes that may disappear . . . . . . . . . . . . 45
	8.1. Scheme aliases considered harmful . . . . . . . . . . . . 43		8.1. Scheme aliases considered harmful . . . . . . . . . . . . 45
	8.2. Use of HTTP for proxy communication . . . . . . . . . . . 43		8.2. Use of HTTP for proxy communication . . . . . . . . . . . 45
	8.3. Interception of HTTP for access control . . . . . . . . . 43		8.3. Interception of HTTP for access control . . . . . . . . . 46
	8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 44		8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 46
	8.5. Use of HTTP by media type specification . . . . . . . . . 44		8.5. Use of HTTP by media type specification . . . . . . . . . 46
	9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 44		9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 46
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 44		9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 46
	9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 45		9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 47
	9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 46		9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
	9.3.1. Clockless Origin Server Operation . . . . . . . . . . 47		9.3.1. Clockless Origin Server Operation . . . . . . . . . . 49
	9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 47		9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
	9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48		9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
	9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 49		9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 51
	9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 49		9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 52
	9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 50		9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 52
	9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 51		9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 53
	9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 52		9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
	10.1. Message Header Registration . . . . . . . . . . . . . . . 53		10.1. Message Header Registration . . . . . . . . . . . . . . . 56
	10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 54		10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 56
	10.3. Internet Media Type Registrations . . . . . . . . . . . . 54		10.3. Internet Media Type Registrations . . . . . . . . . . . . 56
	10.3.1. Internet Media Type message/http . . . . . . . . . . . 54		10.3.1. Internet Media Type message/http . . . . . . . . . . . 56
	10.3.2. Internet Media Type application/http . . . . . . . . . 55		10.3.2. Internet Media Type application/http . . . . . . . . . 58
	10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 56		10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 59
	10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 57		10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 59
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 57		11. Security Considerations . . . . . . . . . . . . . . . . . . . 59
	11.1. Personal Information . . . . . . . . . . . . . . . . . . . 57		11.1. Personal Information . . . . . . . . . . . . . . . . . . . 60
	11.2. Abuse of Server Log Information . . . . . . . . . . . . . 58		11.2. Abuse of Server Log Information . . . . . . . . . . . . . 60
	11.3. Attacks Based On File and Path Names . . . . . . . . . . . 58		11.3. Attacks Based On File and Path Names . . . . . . . . . . . 60
	11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 58		11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 60
	11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 59		11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 61
	11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 60		11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 62
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 62
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 61		13.1. Normative References . . . . . . . . . . . . . . . . . . . 63
	13.2. Informative References . . . . . . . . . . . . . . . . . . 62		13.2. Informative References . . . . . . . . . . . . . . . . . . 65
	Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 64		Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 67
	Appendix B. Compatibility with Previous Versions . . . . . . . . 65		Appendix B. Compatibility with Previous Versions . . . . . . . . 67
	B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 66		B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 68
	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 . . . . . . . . . . . . . . . . 68
	B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 67		B.2. Compatibility with HTTP/1.0 Persistent Connections . . . . 69
	B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 67		B.3. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 70
	B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 68		B.4. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 70
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 69		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 71
	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) . . . . . . . . . . . . . . . . . . . . 76
	D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 73		D.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 76
	D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 73		D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 76
	D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 75		D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 77
	D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 76		D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 78
	D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 76		D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 79
	D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 77		D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 79
	D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 77		D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 80
	D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 78		D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 81
	D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 79		D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 81
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79		D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 82
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86
	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
	similar to that used by Internet mail [RFC5322] and the Multipurpose		similar to that used by Internet mail [RFC5322] and the Multipurpose
	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:
	skipping to change at page 8, line 17		skipping to change at page 8, line 21
	<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].
	This specification uses three rules to denote the use of linear		This specification uses three rules to denote the use of linear
	whitespace: OWS (optional whitespace), RWS (required whitespace), and		whitespace: OWS (optional whitespace), RWS (required whitespace), and
	BWS ("bad" whitespace).		BWS ("bad" whitespace).
	The OWS rule is used where zero or more linear whitespace characters		The OWS rule is used where zero or more linear whitespace characters
	may appear. OWS SHOULD either not be produced or be produced as a		may appear. OWS SHOULD either not be produced or be produced as a
	single SP character. Multiple OWS characters that occur within		single SP character. Multiple OWS characters that occur within
	field-content SHOULD be replaced with a single SP before interpreting		field-content SHOULD be replaced with a single SP before interpreting
	skipping to change at page 9, line 14		skipping to change at page 9, line 38
	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 18, line 11		skipping to change at page 18, line 45
	than those in the "reserved" set are equivalent to their percent-		than those in the "reserved" set are equivalent to their percent-
	encoded octets (see [RFC3986], Section 2.1): the normal form is to		encoded octets (see [RFC3986], Section 2.1): the normal form is to
	not encode them.		not encode them.
	For example, the following three URIs are equivalent:		For example, the following three URIs are equivalent:
	http://example.com:80/~smith/home.html		http://example.com:80/~smith/home.html
	http://EXAMPLE.com/%7Esmith/home.html		http://EXAMPLE.com/%7Esmith/home.html
	http://EXAMPLE.com:/%7esmith/home.html		http://EXAMPLE.com:/%7esmith/home.html
	[[anchor1: [[This paragraph does not belong here. --Roy]]]] If path-		[[TODO-not-here: This paragraph does not belong here. --roy]] If
	abempty is the empty string (i.e., there is no slash "/" path		path-abempty is the empty string (i.e., there is no slash "/" path
	separator following the authority), then the "http" URI MUST be given		separator following the authority), then the "http" URI MUST be given
	as "/" when used as a request-target (Section 4.1.2). If a proxy		as "/" when used as a request-target (Section 4.1.2). If a proxy
	receives a host name which is not a fully qualified domain name, it		receives a host name which is not a fully qualified domain name, it
	MAY add its domain to the host name it received. If a proxy receives		MAY add its domain to the host name it received. If a proxy receives
	a fully qualified domain name, the proxy MUST NOT change the host		a fully qualified domain name, the proxy MUST NOT change the host
	name.		name.
	3. HTTP Message		3. HTTP Message
	All HTTP/1.1 messages consist of a start-line followed by a sequence		All HTTP/1.1 messages consist of a start-line followed by a sequence
	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 50
	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 22, line 50		skipping to change at page 23, line 39
	sent if these two lengths are different (i.e., if a Transfer-		sent if these two lengths are different (i.e., if a Transfer-
	Encoding header field is present). If a message is received with		Encoding header field is present). If a message is received with
	both a Transfer-Encoding header field and a Content-Length header		both a Transfer-Encoding header field and a Content-Length header
	field, the latter MUST be ignored.		field, the latter MUST be ignored.
	4. If the message uses the media type "multipart/byteranges", and		4. If the message uses the media type "multipart/byteranges", and
	the transfer-length is not otherwise specified, then this self-		the transfer-length is not otherwise specified, then this self-
	delimiting media type defines the transfer-length. This media		delimiting media type defines the transfer-length. This media
	type MUST NOT be used unless the sender knows that the recipient		type MUST NOT be used unless the sender knows that the recipient
	can parse it; the presence in a request of a Range header with		can parse it; the presence in a request of a Range header with
	multiple byte-range specifiers from a 1.1 client implies that the		multiple byte-range specifiers from a HTTP/1.1 client implies
	client can parse multipart/byteranges responses.		that the client can parse multipart/byteranges responses.
	A range header might be forwarded by a 1.0 proxy that does not		A range header might be forwarded by a HTTP/1.0 proxy that
	understand multipart/byteranges; in this case the server MUST		does not understand multipart/byteranges; in this case the
	delimit the message using methods defined in items 1, 3 or 5		server MUST delimit the message using methods defined in items
	of this section.		1, 3 or 5 of this section.
	5. By the server closing the connection. (Closing the connection		5. By the server closing the connection. (Closing the connection
	cannot be used to indicate the end of a request body, since that		cannot be used to indicate the end of a request body, since that
	would leave no possibility for the server to send back a		would leave no possibility for the server to send back a
	response.)		response.)
	For compatibility with HTTP/1.0 applications, HTTP/1.1 requests		For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
	containing a message-body MUST include a valid Content-Length header		containing a message-body MUST include a valid Content-Length header
	field unless the server is known to be HTTP/1.1 compliant. If a		field unless the server is known to be HTTP/1.1 compliant. If a
	request contains a message-body and a Content-Length is not given,		request contains a message-body and a Content-Length is not given,
	skipping to change at page 36, line 20		skipping to change at page 36, line 20
	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
	7.1. Persistent Connections		7.1. Persistent Connections
	7.1.1. Purpose		7.1.1. Purpose
	Prior to persistent connections, a separate TCP connection was		Prior to persistent connections, a separate TCP connection was
	established to fetch each URL, increasing the load on HTTP servers		established to fetch each URL, increasing the load on HTTP servers
	and causing congestion on the Internet. The use of inline images and		and causing congestion on the Internet. The use of inline images and
	other associated data often require a client to make multiple		other associated data often requires a client to make multiple
	requests of the same server in a short amount of time. Analysis of		requests of the same server in a short amount of time. Analysis of
	these performance problems and results from a prototype		these performance problems and results from a prototype
	implementation are available [Pad1995] [Spe]. Implementation		implementation are available [Pad1995] [Spe]. Implementation
	experience and measurements of actual HTTP/1.1 implementations show		experience and measurements of actual HTTP/1.1 implementations show
	good results [Nie1997]. Alternatives have also been explored, for		good results [Nie1997]. Alternatives have also been explored, for
	example, T/TCP [Tou1998].		example, T/TCP [Tou1998].
	Persistent HTTP connections have a number of advantages:		Persistent HTTP connections have a number of advantages:
	o By opening and closing fewer TCP connections, CPU time is saved in		o By opening and closing fewer TCP connections, CPU time is saved in
	skipping to change at page 37, line 47		skipping to change at page 37, line 47
	close has been signaled, the client MUST NOT send any more requests		close has been signaled, the client MUST NOT send any more requests
	on that connection.		on that connection.
	7.1.2.1. Negotiation		7.1.2.1. Negotiation
	An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to		An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
	maintain a persistent connection unless a Connection header including		maintain a persistent connection unless a Connection header including
	the connection-token "close" was sent in the request. If the server		the connection-token "close" was sent in the request. If the server
	chooses to close the connection immediately after sending the		chooses to close the connection immediately after sending the
	response, it SHOULD send a Connection header including the		response, it SHOULD send a Connection header including the
	connection-token close.		connection-token "close".
	An HTTP/1.1 client MAY expect a connection to remain open, but would		An HTTP/1.1 client MAY expect a connection to remain open, but would
	decide to keep it open based on whether the response from a server		decide to keep it open based on whether the response from a server
	contains a Connection header with the connection-token close. In		contains a Connection header with the connection-token close. In
	case the client does not want to maintain a connection for more than		case the client does not want to maintain a connection for more than
	that request, it SHOULD send a Connection header including the		that request, it SHOULD send a Connection header including the
	connection-token close.		connection-token close.
	If either the client or the server sends the close token in the		If either the client or the server sends the close token in the
	Connection header, that request becomes the last one for the		Connection header, that request becomes the last one for the
	skipping to change at page 39, line 11		skipping to change at page 39, line 11
	The proxy server MUST signal persistent connections separately with		The proxy server MUST signal persistent connections separately with
	its clients and the origin servers (or other proxy servers) that it		its clients and the origin servers (or other proxy servers) that it
	connects to. Each persistent connection applies to only one		connects to. Each persistent connection applies to only one
	transport link.		transport link.
	A proxy server MUST NOT establish a HTTP/1.1 persistent connection		A proxy server MUST NOT establish a HTTP/1.1 persistent connection
	with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for		with an HTTP/1.0 client (but see Section 19.7.1 of [RFC2068] for
	information and discussion of the problems with the Keep-Alive header		information and discussion of the problems with the Keep-Alive header
	implemented by many HTTP/1.0 clients).		implemented by many HTTP/1.0 clients).
			7.1.3.1. End-to-end and Hop-by-hop Headers
			[[TODO-end-to-end: Restored from <http://tools.ietf.org/html/
			draft-ietf-httpbis-p6-cache-05#section-7.1>. See also
			<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60>. --jre]]
			For the purpose of defining the behavior of caches and non-caching
			proxies, we divide HTTP headers into two categories:
			o End-to-end headers, which are transmitted to the ultimate
			recipient of a request or response. End-to-end headers in
			responses MUST be stored as part of a cache entry and MUST be
			transmitted in any response formed from a cache entry.
			o Hop-by-hop headers, which are meaningful only for a single
			transport-level connection, and are not stored by caches or
			forwarded by proxies.
			The following HTTP/1.1 headers are hop-by-hop headers:
			o Connection
			o Keep-Alive
			o Proxy-Authenticate
			o Proxy-Authorization
			o TE
			o Trailer
			o Transfer-Encoding
			o Upgrade
			All other headers defined by HTTP/1.1 are end-to-end headers.
			Other hop-by-hop headers MUST be listed in a Connection header
			(Section 9.1).
			7.1.3.2. Non-modifiable Headers
			[[TODO-non-mod-headers: Restored from <http://tools.ietf.org/html/
			draft-ietf-httpbis-p6-cache-05#section-7.2>. See also
			<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/60>. --jre]]
			Some features of HTTP/1.1, such as Digest Authentication, depend on
			the value of certain end-to-end headers. A transparent proxy SHOULD
			NOT modify an end-to-end header unless the definition of that header
			requires or specifically allows that.
			A transparent proxy MUST NOT modify any of the following fields in a
			request or response, and it MUST NOT add any of these fields if not
			already present:
			o Content-Location
			o Content-MD5
			o ETag
			o Last-Modified
			A transparent proxy MUST NOT modify any of the following fields in a
			response:
			o Expires
			but it MAY add any of these fields if not already present. If an
			Expires header is added, it MUST be given a field-value identical to
			that of the Date header in that response.
			A proxy MUST NOT modify or add any of the following fields in a
			message that contains the no-transform cache-control directive, or in
			any request:
			o Content-Encoding
			o Content-Range
			o Content-Type
			A non-transparent proxy MAY modify or add these fields to a message
			that does not include no-transform, but if it does so, it MUST add a
			Warning 214 (Transformation applied) if one does not already appear
			in the message (see Section 3.6 of [Part6]).
			Warning: Unnecessary modification of end-to-end headers might
			cause authentication failures if stronger authentication
			mechanisms are introduced in later versions of HTTP. Such
			authentication mechanisms MAY rely on the values of header fields
			not listed here.
			The Content-Length field of a request or response is added or deleted
			according to the rules in Section 3.4. A transparent proxy MUST
			preserve the entity-length (Section 3.2.2 of [Part3]) of the entity-
			body, although it MAY change the transfer-length (Section 3.4).
	7.1.4. Practical Considerations		7.1.4. Practical Considerations
	Servers will usually have some time-out value beyond which they will		Servers will usually have some time-out value beyond which they will
	no longer maintain an inactive connection. Proxy servers might make		no longer maintain an inactive connection. Proxy servers might make
	this a higher value since it is likely that the client will be making		this a higher value since it is likely that the client will be making
	more connections through the same server. The use of persistent		more connections through the same server. The use of persistent
	connections places no requirements on the length (or existence) of		connections places no requirements on the length (or existence) of
	this time-out for either the client or the server.		this time-out for either the client or the server.
	When a client or server wishes to time-out it SHOULD issue a graceful		When a client or server wishes to time-out it SHOULD issue a graceful
	skipping to change at page 43, line 39		skipping to change at page 45, line 43
	o SHOULD NOT continue and		o SHOULD NOT continue and
	o SHOULD close the connection if it has not completed sending the		o SHOULD close the connection if it has not completed sending the
	request message.		request message.
	8. Miscellaneous notes that may disappear		8. Miscellaneous notes that may disappear
	8.1. Scheme aliases considered harmful		8.1. Scheme aliases considered harmful
	[[anchor2: TBS: describe why aliases like webcal are harmful.]]		[[TBD-aliases-harmful: describe why aliases like webcal are
			harmful.]]
	8.2. Use of HTTP for proxy communication		8.2. Use of HTTP for proxy communication
	[[anchor3: TBD: Configured to use HTTP to proxy HTTP or other		[[TBD-proxy-other: Configured to use HTTP to proxy HTTP or other
	protocols.]]		protocols.]]
	8.3. Interception of HTTP for access control		8.3. Interception of HTTP for access control
	[[anchor4: TBD: Interception of HTTP traffic for initiating access		[[TBD-intercept: Interception of HTTP traffic for initiating access
	control.]]		control.]]
	8.4. Use of HTTP by other protocols		8.4. Use of HTTP by other protocols
	[[anchor5: TBD: Profiles of HTTP defined by other protocol.		[[TBD-profiles: Profiles of HTTP defined by other protocol.
	Extensions of HTTP like WebDAV.]]		Extensions of HTTP like WebDAV.]]
	8.5. Use of HTTP by media type specification		8.5. Use of HTTP by media type specification
	[[anchor6: TBD: Instructions on composing HTTP requests via hypertext		[[TBD-hypertext: Instructions on composing HTTP requests via
	formats.]]		hypertext formats.]]
	9. Header Field Definitions		9. Header Field Definitions
	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 message framing and transport protocols.		fields related to message framing and transport protocols.
	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.
	skipping to change at page 45, line 4		skipping to change at page 47, line 8
	corresponding additional header field(s), since the additional header		corresponding additional header field(s), since the additional header
	field may not be sent if there are no parameters associated with that		field may not be sent if there are no parameters associated with that
	connection option.		connection option.
	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 48, line 12
	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:
	1. If the response status code is 100 (Continue) or 101 (Switching		1. If the response status code is 100 (Continue) or 101 (Switching
	Protocols), the response MAY include a Date header field, at the		Protocols), the response MAY include a Date header field, at the
	server's option.		server's option.
	2. If the response status code conveys a server error, e.g. 500		2. If the response status code conveys a server error, e.g., 500
	(Internal Server Error) or 503 (Service Unavailable), and it is		(Internal Server Error) or 503 (Service Unavailable), and it is
	inconvenient or impossible to generate a valid Date.		inconvenient or impossible to generate a valid Date.
	3. If the server does not have a clock that can provide a reasonable		3. If the server does not have a clock that can provide a reasonable
	approximation of the current time, its responses MUST NOT include		approximation of the current time, its responses MUST NOT include
	a Date header field. In this case, the rules in Section 9.3.1		a Date header field. In this case, the rules in Section 9.3.1
	MUST be followed.		MUST be followed.
	A received message that does not have a Date header field MUST be		A received message that does not have a Date header field MUST be
	assigned one by the recipient if the message will be cached by that		assigned one by the recipient if the message will be cached by that
	skipping to change at page 52, line 51		skipping to change at page 55, line 6
	the protocol capabilities of upstream applications remains visible to		the protocol capabilities of upstream applications remains visible to
	all recipients.		all recipients.
	The protocol-name is optional if and only if it would be "HTTP". The		The protocol-name is optional if and only if it would be "HTTP". The
	received-by field is normally the host and optional port number of a		received-by field is normally the host and optional port number of a
	recipient server or client that subsequently forwarded the message.		recipient server or client that subsequently forwarded the message.
	However, if the real host is considered to be sensitive information,		However, if the real host is considered to be sensitive information,
	it MAY be replaced by a pseudonym. If the port is not given, it MAY		it MAY be replaced by a pseudonym. If the port is not given, it MAY
	be assumed to be the default port of the received-protocol.		be assumed to be the default port of the received-protocol.
	Multiple Via field values represents each proxy or gateway that has		Multiple Via field values represent each proxy or gateway that has
	forwarded the message. Each recipient MUST append its information		forwarded the message. Each recipient MUST append its information
	such that the end result is ordered according to the sequence of		such that the end result is ordered according to the sequence of
	forwarding applications.		forwarding applications.
	Comments MAY be used in the Via header field to identify the software		Comments MAY be used in the Via header field to identify the software
	of the recipient proxy or gateway, analogous to the User-Agent and		of the recipient proxy or gateway, analogous to the User-Agent and
	Server header fields. However, all comments in the Via field are		Server header fields. However, all comments in the Via field are
	optional and MAY be removed by any recipient prior to forwarding the		optional and MAY be removed by any recipient prior to forwarding the
	message.		message.
	skipping to change at page 57, line 44		skipping to change at page 60, line 8
	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.
	11.1. Personal Information		11.1. Personal Information
	HTTP clients are often privy to large amounts of personal information		HTTP clients are often privy to large amounts of personal information
	(e.g. the user's name, location, mail address, passwords, encryption		(e.g., the user's name, location, mail address, passwords, encryption
	keys, etc.), and SHOULD be very careful to prevent unintentional		keys, etc.), and SHOULD be very careful to prevent unintentional
	leakage of this information. We very strongly recommend that a		leakage of this information. We very strongly recommend that a
	convenient interface be provided for the user to control		convenient interface be provided for the user to control
	dissemination of such information, and that designers and		dissemination of such information, and that designers and
	implementors be particularly careful in this area. History shows		implementors be particularly careful in this area. History shows
	that errors in this area often create serious security and/or privacy		that errors in this area often create serious security and/or privacy
	problems and generate highly adverse publicity for the implementor's		problems and generate highly adverse publicity for the implementor's
	company.		company.
	11.2. Abuse of Server Log Information		11.2. Abuse of Server Log Information
	skipping to change at page 59, line 37		skipping to change at page 61, line 47
	organizations, and proprietary information belonging to users and		organizations, and proprietary information belonging to users and
	content providers. A compromised proxy, or a proxy implemented or		content providers. A compromised proxy, or a proxy implemented or
	configured without regard to security and privacy considerations,		configured without regard to security and privacy considerations,
	might be used in the commission of a wide range of potential attacks.		might be used in the commission of a wide range of potential attacks.
	Proxy operators should protect the systems on which proxies run as		Proxy operators should protect the systems on which proxies run as
	they would protect any system that contains or transports sensitive		they would protect any system that contains or transports sensitive
	information. In particular, log information gathered at proxies		information. In particular, log information gathered at proxies
	often contains highly sensitive personal information, and/or		often contains highly sensitive personal information, and/or
	information about organizations. Log information should be carefully		information about organizations. Log information should be carefully
	guarded, and appropriate guidelines for use developed and followed.		guarded, and appropriate guidelines for use should be developed and
	(Section 11.2).		followed. (Section 11.2).
	Proxy implementors should consider the privacy and security		Proxy implementors should consider the privacy and security
	implications of their design and coding decisions, and of the		implications of their design and coding decisions, and of the
	configuration options they provide to proxy operators (especially the		configuration options they provide to proxy operators (especially the
	default configuration).		default configuration).
	Users of a proxy need to be aware that they are no trustworthier than		Users of a proxy need to be aware that proxies are no trustworthier
	the people who run the proxy; HTTP itself cannot solve this problem.		than the people who run them; HTTP itself cannot solve this problem.
	The judicious use of cryptography, when appropriate, may suffice to		The judicious use of cryptography, when appropriate, may suffice to
	protect against a broad range of security and privacy attacks. Such		protect against a broad range of security and privacy attacks. Such
	cryptography is beyond the scope of the HTTP/1.1 specification.		cryptography is beyond the scope of the HTTP/1.1 specification.
	11.6. Denial of Service Attacks on Proxies		11.6. Denial of Service Attacks on Proxies
	They exist. They are hard to defend against. Research continues.		They exist. They are hard to defend against. Research continues.
	Beware.		Beware.
	skipping to change at page 61, line 27		skipping to change at page 63, 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-09 (work in
	progress), October 2009.		progress), March 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", draft-ietf-httpbis-p3-payload-09
	(work in progress), October 2009.		(work in progress), March 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-09 (work
	in progress), October 2009.		in progress), March 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-09 (work in
	progress), October 2009.		progress), March 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 64, line 49		skipping to change at page 67, line 14
	Appendix A. Tolerant Applications		Appendix A. Tolerant Applications
	Although this document specifies the requirements for the generation		Although this document specifies the requirements for the generation
	of HTTP/1.1 messages, not all applications will be correct in their		of HTTP/1.1 messages, not all applications will be correct in their
	implementation. We therefore recommend that operational applications		implementation. We therefore recommend that operational applications
	be tolerant of deviations whenever those deviations can be		be tolerant of deviations whenever those deviations can be
	interpreted unambiguously.		interpreted unambiguously.
	Clients SHOULD be tolerant in parsing the Status-Line and servers		Clients SHOULD be tolerant in parsing the Status-Line and servers
	tolerant when parsing the Request-Line. In particular, they SHOULD		SHOULD be tolerant when parsing the Request-Line. In particular,
	accept any amount of WSP characters between fields, even though only		they SHOULD accept any amount of WSP characters between fields, even
	a single SP is required.		though only a single SP is required.
	The line terminator for header fields is the sequence CRLF. However,		The line terminator for header fields is the sequence CRLF. However,
	we recommend that applications, when parsing such headers, recognize		we recommend that applications, when parsing such headers, recognize
	a single LF as a line terminator and ignore the leading CR.		a single LF as a line terminator and ignore the leading CR.
	The character set of an entity-body SHOULD be labeled as the lowest		The character set of an entity-body SHOULD be labeled as the lowest
	common denominator of the character codes used within that body, with		common denominator of the character codes used within that body, with
	the exception that not labeling the entity is preferred over labeling		the exception that not labeling the entity is preferred over labeling
	the entity with the labels US-ASCII or ISO-8859-1. See [Part3].		the entity with the labels US-ASCII or ISO-8859-1. See [Part3].
	skipping to change at page 67, line 28		skipping to change at page 69, line 41
	o Servers MUST accept absolute URIs.		o Servers MUST accept absolute URIs.
	B.2. Compatibility with HTTP/1.0 Persistent Connections		B.2. Compatibility with HTTP/1.0 Persistent Connections
	Some clients and servers might wish to be compatible with some		Some clients and servers might wish to be compatible with some
	previous implementations of persistent connections in HTTP/1.0		previous implementations of persistent connections in HTTP/1.0
	clients and servers. Persistent connections in HTTP/1.0 are		clients and servers. Persistent connections in HTTP/1.0 are
	explicitly negotiated as they are not the default behavior. HTTP/1.0		explicitly negotiated as they are not the default behavior. HTTP/1.0
	experimental implementations of persistent connections are faulty,		experimental implementations of persistent connections are faulty,
	and the new facilities in HTTP/1.1 are designed to rectify these		and the new facilities in HTTP/1.1 are designed to rectify these
	problems. The problem was that some existing 1.0 clients may be		problems. The problem was that some existing HTTP/1.0 clients may be
	sending Keep-Alive to a proxy server that doesn't understand		sending Keep-Alive to a proxy server that doesn't understand
	Connection, which would then erroneously forward it to the next		Connection, which would then erroneously forward it to the next
	inbound server, which would establish the Keep-Alive connection and		inbound server, which would establish the Keep-Alive connection and
	result in a hung HTTP/1.0 proxy waiting for the close on the		result in a hung HTTP/1.0 proxy waiting for the close on the
	response. The result is that HTTP/1.0 clients must be prevented from		response. The result is that HTTP/1.0 clients must be prevented from
	using Keep-Alive when talking to proxies.		using Keep-Alive when talking to proxies.
	However, talking to proxies is the most important use of persistent		However, talking to proxies is the most important use of persistent
	connections, so that prohibition is clearly unacceptable. Therefore,		connections, so that prohibition is clearly unacceptable. Therefore,
	we need some other mechanism for indicating a persistent connection		we need some other mechanism for indicating a persistent connection
	skipping to change at page 68, line 29		skipping to change at page 70, line 42
	Transfer-coding had significant problems, particularly with		Transfer-coding had significant problems, particularly with
	interactions with chunked encoding. The solution is that transfer-		interactions with chunked encoding. The solution is that transfer-
	codings become as full fledged as content-codings. This involves		codings become as full fledged as content-codings. This involves
	adding an IANA registry for transfer-codings (separate from content		adding an IANA registry for transfer-codings (separate from content
	codings), a new header field (TE) and enabling trailer headers in the		codings), a new header field (TE) and enabling trailer headers in the
	future. Transfer encoding is a major performance benefit, so it was		future. Transfer encoding is a major performance benefit, so it was
	worth fixing [Nie1997]. TE also solves another, obscure, downward		worth fixing [Nie1997]. TE also solves another, obscure, downward
	interoperability problem that could have occurred due to interactions		interoperability problem that could have occurred due to interactions
	between authentication trailers, chunked encoding and HTTP/1.0		between authentication trailers, chunked encoding and HTTP/1.0
	clients.(Section 6.2, 6.2.1, and 9.5)		clients.(Section 6.2, 6.2.1, 7.1.3.2, and 9.5)
			Proxies should be able to add Content-Length when appropriate.
			(Section 7.1.3.2)
	B.4. Changes from RFC 2616		B.4. Changes from RFC 2616
	Empty list elements in list productions have been deprecated.		Empty list elements in list productions have been deprecated.
	(Section 1.2.1)		(Section 1.2.1)
	Rules about implicit linear whitespace between certain grammar		Rules about implicit linear whitespace between certain grammar
	productions have been removed; now it's only allowed when		productions have been removed; now it's only allowed when
	specifically pointed out in the ABNF. The NUL character is no longer		specifically pointed out in the ABNF. The NUL character is no longer
	allowed in comment and quoted-string text. The quoted-pair rule no		allowed in comment and quoted-string text. The quoted-pair rule no
	longer allows escaping control characters other than HTAB. Non-ASCII		longer allows escaping control characters other than HTAB. Non-ASCII
	content in header fields and reason phrase has been obsoleted and		content in header fields and reason phrase has been obsoleted and
	made opaque (the TEXT rule was removed) (Section 1.2.2)		made opaque (the TEXT rule was removed) (Section 1.2.2)
	Clarify that HTTP-Version is case sensitive. (Section 2.5)		Clarify that HTTP-Version is case sensitive. (Section 2.5)
	skipping to change at page 68, line 46		skipping to change at page 71, line 14
	Rules about implicit linear whitespace between certain grammar		Rules about implicit linear whitespace between certain grammar
	productions have been removed; now it's only allowed when		productions have been removed; now it's only allowed when
	specifically pointed out in the ABNF. The NUL character is no longer		specifically pointed out in the ABNF. The NUL character is no longer
	allowed in comment and quoted-string text. The quoted-pair rule no		allowed in comment and quoted-string text. The quoted-pair rule no
	longer allows escaping control characters other than HTAB. Non-ASCII		longer allows escaping control characters other than HTAB. Non-ASCII
	content in header fields and reason phrase has been obsoleted and		content in header fields and reason phrase has been obsoleted and
	made opaque (the TEXT rule was removed) (Section 1.2.2)		made opaque (the TEXT rule was removed) (Section 1.2.2)
	Clarify that HTTP-Version is case sensitive. (Section 2.5)		Clarify that HTTP-Version is case sensitive. (Section 2.5)
	Remove reference to non-existant identity transfer-coding value		Remove reference to non-existent identity transfer-coding value
	tokens. (Sections 6.2 and 3.4)		tokens. (Sections 6.2 and 3.4)
	Require that invalid whitespace around field-names be rejected.		Require that invalid whitespace around field-names be rejected.
	(Section 3.2)		(Section 3.2)
	Update use of abs_path production from RFC1808 to the path-absolute +		Update use of abs_path production from RFC1808 to the path-absolute +
	query components of RFC3986. (Section 4.1.2)		query components of RFC3986. (Section 4.1.2)
	Clarification that the chunk length does not include the count of the		Clarification that the chunk length does not include the count of the
	octets in the chunk header and trailer. Furthermore disallowed line		octets in the chunk header and trailer. Furthermore disallowed line
	folding in chunk extensions. (Section 6.2.1)		folding in chunk extensions. (Section 6.2.1)
	Remove hard limit of two connections per server. (Section 7.1.4)		Remove hard limit of two connections per server. (Section 7.1.4)
	Clarify exactly when close connection options must be sent.		Clarify exactly when close connection options must be sent.
	skipping to change at page 72, line 43		skipping to change at page 75, line 11
	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 75, line 48
	; 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 45		skipping to change at page 82, line 17
	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/60>: "Placement of
			13.5.1 and 13.5.2"
			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 58
	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 46
	Content-Length header 45		Content-Length header 47
	D		D
	Date header 46		Date header 48
	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 46
	connection-token 44		connection-token 46
	Connection-v 44		Connection-v 46
	Content-Length 45		Content-Length 47
	Content-Length-v 45		Content-Length-v 47
	CR 7		CR 7
	CRLF 7		CRLF 7
	ctext 21		ctext 21
	CTL 7		CTL 7
	Date 46		Date 48
	Date-v 46		Date-v 48
	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 49
	Host-v 47		Host-v 49
	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 54
	protocol-version 52		protocol-version 54
	pseudonym 52		pseudonym 54
	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 54
	received-protocol 52		received-protocol 54
	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
	t-codings 48		Status-Line 28
			t-codings 50
	tchar 9		tchar 9
	TE 48		TE 50
	te-ext 48		te-ext 50
	te-params 48		te-params 50
	TE-v 48		TE-v 50
	time-of-day 30		time-of-day 30
	token 9		token 9
	Trailer 49		Trailer 51
	trailer-part 33		trailer-part 33
	Trailer-v 49		Trailer-v 51
	transfer-coding 31		transfer-coding 31
	Transfer-Encoding 50		Transfer-Encoding 52
	Transfer-Encoding-v 50		Transfer-Encoding-v 52
	transfer-extension 31		transfer-extension 31
	transfer-parameter 31		transfer-parameter 32
	Upgrade 50		Upgrade 52
	Upgrade-v 50		Upgrade-v 52
	uri-host 15		uri-host 16
	URI-reference 15		URI-reference 16
	value 31		value 32
	VCHAR 7		VCHAR 7
	Via 52		Via 54
	Via-v 52		Via-v 54
	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 46
	Content-Length 45		Content-Length 47
	Date 46		Date 48
	Host 47		Host 49
	TE 48		TE 50
	Trailer 49		Trailer 51
	Transfer-Encoding 49		Transfer-Encoding 52
	Upgrade 50		Upgrade 52
	Via 52		Via 54
	headers 18		headers 19
	Host header 47		Host header 49
	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 58
	message/http 54		message/http 56
	message 10		message 11
	message/http Media Type 54		message/http Media Type 56
	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 50
	Trailer header 49		Trailer header 51
	Transfer-Encoding header 49		Transfer-Encoding header 52
	tunnel 12		tunnel 13
	U		U
	Upgrade header 50		Upgrade header 52
	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 54
	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
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
End of changes. 104 change blocks.
	286 lines changed or deleted		450 lines changed or added
This html diff was produced by rfcdiff 1.36. The latest version is available from http://tools.ietf.org/tools/rfcdiff/