draft-ietf-httpbis-p1-messaging-13.txt		draft-ietf-httpbis-p1-messaging-14.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2145,2616 J. Gettys		Obsoletes: 2145,2616 (if approved) J. Gettys
	(if approved) Alcatel-Lucent		Updates: 2817 (if approved) Alcatel-Lucent
	Updates: 2817 (if approved) J. Mogul		Intended status: Standards Track J. Mogul
	Intended status: Standards Track HP		Expires: October 20, 2011 HP
	Expires: September 15, 2011 H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 14, 2011		April 18, 2011
	HTTP/1.1, part 1: URIs, Connections, and Message Parsing		HTTP/1.1, part 1: URIs, Connections, and Message Parsing
	draft-ietf-httpbis-p1-messaging-13		draft-ietf-httpbis-p1-messaging-14
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext information		protocol for distributed, collaborative, hypertext information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 1 of the		information initiative since 1990. This document is Part 1 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides
	an overview of HTTP and its associated terminology, defines the		an overview of HTTP and its associated terminology, defines the
	"http" and "https" Uniform Resource Identifier (URI) schemes, defines		"http" and "https" Uniform Resource Identifier (URI) schemes, defines
	the generic message syntax and parsing requirements for HTTP message		the generic message syntax and parsing requirements for HTTP message
	frames, and describes general security concerns for implementations.		frames, and describes general security concerns for implementations.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org), which is archived at
	at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
			The current issues list is at
			<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix D.14.		The changes in this draft are summarized in Appendix D.15.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	skipping to change at page 2, line 17		skipping to change at page 2, line 22
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 15, 2011.		This Internet-Draft will expire on October 20, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 45		skipping to change at page 3, line 49
	6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41		6.3. Product Tokens . . . . . . . . . . . . . . . . . . . . . . 41
	6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41		6.4. Quality Values . . . . . . . . . . . . . . . . . . . . . . 41
	7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41		7. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 41
	7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42		7.1. Persistent Connections . . . . . . . . . . . . . . . . . . 42
	7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42		7.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 42
	7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42		7.1.2. Overall Operation . . . . . . . . . . . . . . . . . . 42
	7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44		7.1.3. Proxy Servers . . . . . . . . . . . . . . . . . . . . 44
	7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46		7.1.4. Practical Considerations . . . . . . . . . . . . . . . 46
	7.2. Message Transmission Requirements . . . . . . . . . . . . 47		7.2. Message Transmission Requirements . . . . . . . . . . . . 47
	7.2.1. Persistent Connections and Flow Control . . . . . . . 47		7.2.1. Persistent Connections and Flow Control . . . . . . . 47
	7.2.2. Monitoring Connections for Error Status Messages . . . 47		7.2.2. Monitoring Connections for Error Status Messages . . . 48
	7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48		7.2.3. Use of the 100 (Continue) Status . . . . . . . . . . . 48
	7.2.4. Client Behavior if Server Prematurely Closes		7.2.4. Client Behavior if Server Prematurely Closes
	Connection . . . . . . . . . . . . . . . . . . . . . . 50		Connection . . . . . . . . . . . . . . . . . . . . . . 50
	8. Miscellaneous notes that might disappear . . . . . . . . . . . 51		8. Miscellaneous notes that might disappear . . . . . . . . . . . 51
	8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51		8.1. Scheme aliases considered harmful . . . . . . . . . . . . 51
	8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51		8.2. Use of HTTP for proxy communication . . . . . . . . . . . 51
	8.3. Interception of HTTP for access control . . . . . . . . . 51		8.3. Interception of HTTP for access control . . . . . . . . . 51
	8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51		8.4. Use of HTTP by other protocols . . . . . . . . . . . . . . 51
	8.5. Use of HTTP by media type specification . . . . . . . . . 51		8.5. Use of HTTP by media type specification . . . . . . . . . 51
	9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51		9. Header Field Definitions . . . . . . . . . . . . . . . . . . . 51
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51		9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 51
	9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53		9.2. Content-Length . . . . . . . . . . . . . . . . . . . . . . 53
	9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53		9.3. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
	9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54		9.3.1. Clockless Origin Server Operation . . . . . . . . . . 54
	9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55		9.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
	9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56		9.5. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
	9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57		9.6. Trailer . . . . . . . . . . . . . . . . . . . . . . . . . 57
	9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 58		9.7. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 57
	9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58		9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 58
	9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59		9.8.1. Upgrade Token Registry . . . . . . . . . . . . . . . . 59
	9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60		9.9. Via . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
	10.1. Header Field Registration . . . . . . . . . . . . . . . . 62		10.1. Header Field Registration . . . . . . . . . . . . . . . . 61
	10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62		10.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 62
	10.3. Internet Media Type Registrations . . . . . . . . . . . . 62		10.3. Internet Media Type Registrations . . . . . . . . . . . . 62
	10.3.1. Internet Media Type message/http . . . . . . . . . . . 62		10.3.1. Internet Media Type message/http . . . . . . . . . . . 62
	10.3.2. Internet Media Type application/http . . . . . . . . . 64		10.3.2. Internet Media Type application/http . . . . . . . . . 63
	10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 65		10.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 64
	10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65		10.5. Upgrade Token Registration . . . . . . . . . . . . . . . . 65
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 65		11. Security Considerations . . . . . . . . . . . . . . . . . . . 65
	11.1. Personal Information . . . . . . . . . . . . . . . . . . . 66		11.1. Personal Information . . . . . . . . . . . . . . . . . . . 65
	11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66		11.2. Abuse of Server Log Information . . . . . . . . . . . . . 66
	11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66		11.3. Attacks Based On File and Path Names . . . . . . . . . . . 66
	11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66		11.4. DNS Spoofing . . . . . . . . . . . . . . . . . . . . . . . 66
	11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67		11.5. Proxies and Caching . . . . . . . . . . . . . . . . . . . 67
	11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68		11.6. Denial of Service Attacks on Proxies . . . . . . . . . . . 68
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 69		13.1. Normative References . . . . . . . . . . . . . . . . . . . 69
	13.2. Informative References . . . . . . . . . . . . . . . . . . 71		13.2. Informative References . . . . . . . . . . . . . . . . . . 71
	Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 74		Appendix A. Tolerant Applications . . . . . . . . . . . . . . . . 73
	Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 75		Appendix B. HTTP Version History . . . . . . . . . . . . . . . . 74
	B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75		B.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 75
	B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 76		B.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 75
	B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76		B.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 76
	B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 77		B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 76
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 77
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 82		publication) . . . . . . . . . . . . . . . . . . . . 81
	D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 82		D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 81
	D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 82		D.2. Since draft-ietf-httpbis-p1-messaging-00 . . . . . . . . . 81
	D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83		D.3. Since draft-ietf-httpbis-p1-messaging-01 . . . . . . . . . 83
	D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84		D.4. Since draft-ietf-httpbis-p1-messaging-02 . . . . . . . . . 84
	D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 85		D.5. Since draft-ietf-httpbis-p1-messaging-03 . . . . . . . . . 84
	D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85		D.6. Since draft-ietf-httpbis-p1-messaging-04 . . . . . . . . . 85
	D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 86		D.7. Since draft-ietf-httpbis-p1-messaging-05 . . . . . . . . . 85
	D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 87		D.8. Since draft-ietf-httpbis-p1-messaging-06 . . . . . . . . . 86
	D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87		D.9. Since draft-ietf-httpbis-p1-messaging-07 . . . . . . . . . 87
	D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 88		D.10. Since draft-ietf-httpbis-p1-messaging-08 . . . . . . . . . 87
	D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88		D.11. Since draft-ietf-httpbis-p1-messaging-09 . . . . . . . . . 88
	D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 89		D.12. Since draft-ietf-httpbis-p1-messaging-10 . . . . . . . . . 88
	D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89		D.13. Since draft-ietf-httpbis-p1-messaging-11 . . . . . . . . . 89
	D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 90		D.14. Since draft-ietf-httpbis-p1-messaging-12 . . . . . . . . . 89
			D.15. Since draft-ietf-httpbis-p1-messaging-13 . . . . . . . . . 90
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
	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 the target resource		Identifier (URI) standard [RFC3986] to indicate the target resource
	and relationships between resources. Messages are passed in a format		and relationships between resources. Messages are passed in a format
	skipping to change at page 10, line 33		skipping to change at page 10, line 33
	HTTP was created for the World Wide Web architecture and has evolved		HTTP was created for the World Wide Web architecture and has evolved
	over time to support the scalability needs of a worldwide hypertext		over time to support the scalability needs of a worldwide hypertext
	system. Much of that architecture is reflected in the terminology		system. Much of that architecture is reflected in the terminology
	and syntax productions used to define HTTP.		and syntax productions used to define HTTP.
	2.1. Client/Server Messaging		2.1. Client/Server Messaging
	HTTP is a stateless request/response protocol that operates by		HTTP is a stateless request/response protocol that operates by
	exchanging messages across a reliable transport or session-layer		exchanging messages across a reliable transport or session-layer
	connection. An HTTP "client" is a program that establishes a		"connection". An HTTP "client" is a program that establishes a
	connection to a server for the purpose of sending one or more HTTP		connection to a server for the purpose of sending one or more HTTP
	requests. An HTTP "server" is a program that accepts connections in		requests. An HTTP "server" is a program that accepts connections in
	order to service HTTP requests by sending HTTP responses.		order to service HTTP requests by sending HTTP responses.
	Note that the terms client and server refer only to the roles that		Note that the terms client and server refer only to the roles that
	these programs perform for a particular connection. The same program		these programs perform for a particular connection. The same program
	might act as a client on some connections and a server on others. We		might act as a client on some connections and a server on others. We
	use the term "user agent" to refer to the program that initiates a		use the term "user agent" to refer to the program that initiates a
	request, such as a WWW browser, editor, or spider (web-traversing		request, such as a WWW browser, editor, or spider (web-traversing
	robot), and the term "origin server" to refer to the program that can		robot), and the term "origin server" to refer to the program that can
	skipping to change at page 12, line 51		skipping to change at page 12, line 51
	chain, or to all connections along the chain. Although the diagram		chain, or to all connections along the chain. Although the diagram
	is linear, each participant might be engaged in multiple,		is linear, each participant might be engaged in multiple,
	simultaneous communications. For example, B might be receiving		simultaneous communications. For example, B might be receiving
	requests from many clients other than A, and/or forwarding requests		requests from many clients other than A, and/or forwarding requests
	to servers other than C, at the same time that it is handling A's		to servers other than C, at the same time that it is handling A's
	request.		request.
	We use the terms "upstream" and "downstream" to describe various		We use the terms "upstream" and "downstream" to describe various
	requirements in relation to the directional flow of a message: all		requirements in relation to the directional flow of a message: all
	messages flow from upstream to downstream. Likewise, we use the		messages flow from upstream to downstream. Likewise, we use the
	terms "inbound" and "outbound" to refer to directions in relation to		terms inbound and outbound to refer to directions in relation to the
	the request path: "inbound" means toward the origin server and		request path: "inbound" means toward the origin server and "outbound"
	"outbound" means toward the user agent.		means toward the user agent.
	A "proxy" is a message forwarding agent that is selected by the		A "proxy" is a message forwarding agent that is selected by the
	client, usually via local configuration rules, to receive requests		client, usually via local configuration rules, to receive requests
	for some type(s) of absolute URI and attempt to satisfy those		for some type(s) of absolute URI and attempt to satisfy those
	requests via translation through the HTTP interface. Some		requests via translation through the HTTP interface. Some
	translations are minimal, such as for proxy requests for "http" URIs,		translations are minimal, such as for proxy requests for "http" URIs,
	whereas other requests might require translation to and from entirely		whereas other requests might require translation to and from entirely
	different application-layer protocols. Proxies are often used to		different application-layer protocols. Proxies are often used to
	group an organization's HTTP requests through a common intermediary		group an organization's HTTP requests through a common intermediary
	for the sake of security, annotation services, or shared caching.		for the sake of security, annotation services, or shared caching.
	skipping to change at page 24, line 40		skipping to change at page 24, line 40
	property of the message, not of the payload, and thus MAY be added or		property of the message, not of the payload, and thus MAY be added or
	removed by any implementation along the request/response chain under		removed by any implementation along the request/response chain under
	the constraints found in Section 6.2.		the constraints found in Section 6.2.
	If a message is received that has multiple Content-Length header		If a message is received that has multiple Content-Length header
	fields (Section 9.2) with field-values consisting of the same decimal		fields (Section 9.2) with field-values consisting of the same decimal
	value, or a single Content-Length header field with a field value		value, or a single Content-Length header field with a field value
	containing a list of identical decimal values (e.g., "Content-Length:		containing a list of identical decimal values (e.g., "Content-Length:
	42, 42"), indicating that duplicate Content-Length header fields have		42, 42"), indicating that duplicate Content-Length header fields have
	been generated or combined by an upstream message processor, then the		been generated or combined by an upstream message processor, then the
	recipient MUST replace the duplicated fields or field-values with a		recipient MUST either reject the message as invalid or replace the
	single valid Content-Length field containing that decimal value prior		duplicated field-values with a single valid Content-Length field
	to determining the message-body length.		containing that decimal value prior to determining the message-body
			length.
	The rules for when a message-body is allowed in a message differ for		The rules for when a message-body is allowed in a message differ for
	requests and responses.		requests and responses.
	The presence of a message-body in a request is signaled by the		The presence of a message-body in a request is signaled by the
	inclusion of a Content-Length or Transfer-Encoding header field in		inclusion of a Content-Length or Transfer-Encoding header field in
	the request's header fields, even if the request method does not		the request's header fields, even if the request method does not
	define any use for a message-body. This allows the request message		define any use for a message-body. This allows the request message
	framing algorithm to be independent of method semantics.		framing algorithm to be independent of method semantics.
	skipping to change at page 45, line 33		skipping to change at page 45, line 33
	Some features of HTTP/1.1, such as Digest Authentication, depend on		Some features of HTTP/1.1, such as Digest Authentication, depend on
	the value of certain end-to-end header fields. A non-transforming		the value of certain end-to-end header fields. A non-transforming
	proxy SHOULD NOT modify an end-to-end header field unless the		proxy SHOULD NOT modify an end-to-end header field unless the
	definition of that header field requires or specifically allows that.		definition of that header field requires or specifically allows that.
	A non-transforming proxy MUST NOT modify any of the following fields		A non-transforming proxy MUST NOT modify any of the following fields
	in a request or response, and it MUST NOT add any of these fields if		in a request or response, and it MUST NOT add any of these fields if
	not already present:		not already present:
			o Allow
	o Content-Location		o Content-Location
	o Content-MD5		o Content-MD5
	o ETag		o ETag
	o Last-Modified		o Last-Modified
			o Server
	A non-transforming proxy MUST NOT modify any of the following fields		A non-transforming proxy MUST NOT modify any of the following fields
	in a response:		in a response:
	o Expires		o Expires
	but it MAY add any of these fields if not already present. If an		but it MAY add any of these fields if not already present. If an
	Expires header field is added, it MUST be given a field-value		Expires header field is added, it MUST be given a field-value
	identical to that of the Date header field in that response.		identical to that of the Date header field in that response.
	A proxy MUST NOT modify or add any of the following fields in a		A proxy MUST NOT modify or add any of the following fields in a
	skipping to change at page 52, line 5		skipping to change at page 52, line 7
	be forwarded downstream by a proxy or gateway. This mechanism also		be forwarded downstream by a proxy or gateway. This mechanism also
	allows the sender to indicate which HTTP header fields used in the		allows the sender to indicate which HTTP header fields used in the
	message are only intended for the immediate recipient ("hop-by-hop"),		message are only intended for the immediate recipient ("hop-by-hop"),
	as opposed to all recipients on the chain ("end-to-end"), enabling		as opposed to all recipients on the chain ("end-to-end"), enabling
	the message to be self-descriptive and allowing future connection-		the message to be self-descriptive and allowing future connection-
	specific extensions to be deployed in HTTP without fear that they		specific extensions to be deployed in HTTP without fear that they
	will be blindly forwarded by previously deployed intermediaries.		will be blindly forwarded by previously deployed intermediaries.
	The Connection header field's value has the following grammar:		The Connection header field's value has the following grammar:
	Connection = "Connection" ":" OWS Connection-v		Connection = 1#connection-token
	Connection-v = 1#connection-token
	connection-token = token		connection-token = token
	A proxy or gateway MUST parse a received Connection header field		A proxy or gateway MUST parse a received Connection header field
	before a message is forwarded and, for each connection-token in this		before a message is forwarded and, for each connection-token in this
	field, remove any header field(s) from the message with the same name		field, remove any header field(s) from the message with the same name
	as the connection-token, and then remove the Connection header field		as the connection-token, and then remove the Connection header field
	itself or replace it with the sender's own connection options for the		itself or replace it with the sender's own connection options for the
	forwarded message.		forwarded message.
	A sender MUST NOT include field-names in the Connection header field-		A sender MUST NOT include field-names in the Connection header field-
	skipping to change at page 53, line 23		skipping to change at page 53, line 25
	body, in decimal number of octets, for any message other than a		body, in decimal number of octets, for any message other than a
	response to a HEAD request or a response with a status code of 304.		response to a HEAD request or a response with a status code of 304.
	In the case of a response to a HEAD request, Content-Length indicates		In the case of a response to a HEAD request, Content-Length indicates
	the size of the payload body (not including any potential transfer-		the size of the payload body (not including any potential transfer-
	coding) that would have been sent had the request been a GET. In the		coding) that would have been sent had the request been a GET. In the
	case of a 304 (Not Modified) response to a GET request, Content-		case of a 304 (Not Modified) response to a GET request, Content-
	Length indicates the size of the payload body (not including any		Length indicates the size of the payload body (not including any
	potential transfer-coding) that would have been sent in a 200 (OK)		potential transfer-coding) that would have been sent in a 200 (OK)
	response.		response.
	Content-Length = "Content-Length" ":" OWS 1*Content-Length-v		Content-Length = 1*DIGIT
	Content-Length-v = 1*DIGIT
	An example is		An example is
	Content-Length: 3495		Content-Length: 3495
	Implementations SHOULD use this field to indicate the message-body		Implementations SHOULD use this field to indicate the message-body
	length when no transfer-coding is being applied and the payload's		length when no transfer-coding is being applied and the payload's
	body length can be determined prior to being transferred.		body length can be determined prior to being transferred.
	Section 3.3 describes how recipients determine the length of a		Section 3.3 describes how recipients determine the length of a
	message-body.		message-body.
	skipping to change at page 53, line 50		skipping to change at page 53, line 51
	field used within the "message/external-body" content-type.		field used within the "message/external-body" content-type.
	9.3. Date		9.3. Date
	The "Date" header field represents the date and time at which the		The "Date" header field represents the date and time at which the
	message was originated, having the same semantics as the Origination		message was originated, having the same semantics as the Origination
	Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The		Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The
	field value is an HTTP-date, as described in Section 6.1; it MUST be		field value is an HTTP-date, as described in Section 6.1; it MUST be
	sent in rfc1123-date format.		sent in rfc1123-date format.
	Date = "Date" ":" OWS Date-v		Date = 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
	skipping to change at page 55, line 14		skipping to change at page 55, line 14
	9.4. Host		9.4. Host
	The "Host" header field in a request provides the host and port		The "Host" header field in a request provides the host and port
	information from the target resource's URI, enabling the origin		information from the target resource's URI, enabling the origin
	server to distinguish between resources while servicing requests for		server to distinguish between resources while servicing requests for
	multiple host names on a single IP address. Since the Host field-		multiple host names on a single IP address. Since the Host field-
	value is critical information for handling a request, it SHOULD be		value is critical information for handling a request, it SHOULD be
	sent as the first header field following the Request-Line.		sent as the first header field following the Request-Line.
	Host = "Host" ":" OWS Host-v		Host = uri-host [ ":" port ] ; Section 2.6.1
	Host-v = uri-host [ ":" port ] ; Section 2.6.1
	A client MUST send a Host header field in all HTTP/1.1 request		A client MUST send a Host header field in all HTTP/1.1 request
	messages. If the target resource's URI includes an authority		messages. If the target resource's URI includes an authority
	component, then the Host field-value MUST be identical to that		component, then the Host field-value MUST be identical to that
	authority component after excluding any userinfo (Section 2.6.1). If		authority component after excluding any userinfo (Section 2.6.1). If
	the authority component is missing or undefined for the target		the authority component is missing or undefined for the target
	resource's URI, then the Host header field MUST be sent with an empty		resource's URI, then the Host header field MUST be sent with an empty
	field-value.		field-value.
	For example, a GET request to the origin server for		For example, a GET request to the origin server for
	skipping to change at page 56, line 20		skipping to change at page 56, line 19
	9.5. TE		9.5. TE
	The "TE" header field indicates what extension transfer-codings it is		The "TE" header field indicates what extension transfer-codings it is
	willing to accept in the response, and whether or not it is willing		willing to accept in the response, and whether or not it is willing
	to accept trailer fields in a chunked transfer-coding.		to accept trailer fields in a chunked transfer-coding.
	Its value consists of the keyword "trailers" and/or a comma-separated		Its value consists of the keyword "trailers" and/or a comma-separated
	list of extension transfer-coding names with optional accept		list of extension transfer-coding names with optional accept
	parameters (as described in Section 6.2).		parameters (as described in Section 6.2).
	TE = "TE" ":" OWS TE-v		TE = #t-codings
	TE-v = #t-codings
	t-codings = "trailers" / ( transfer-extension [ te-params ] )		t-codings = "trailers" / ( transfer-extension [ te-params ] )
	te-params = OWS ";" OWS "q=" qvalue *( te-ext )		te-params = OWS ";" OWS "q=" qvalue *( te-ext )
	te-ext = OWS ";" OWS token [ "=" word ]		te-ext = OWS ";" OWS token [ "=" word ]
	The presence of the keyword "trailers" indicates that the client is		The presence of the keyword "trailers" indicates that the client is
	willing to accept trailer fields in a chunked transfer-coding, as		willing to accept trailer fields in a chunked transfer-coding, as
	defined in Section 6.2.1. This keyword is reserved for use with		defined in Section 6.2.1. This keyword is reserved for use with
	transfer-coding values even though it does not itself represent a		transfer-coding values even though it does not itself represent a
	transfer-coding.		transfer-coding.
	skipping to change at page 57, line 29		skipping to change at page 57, line 28
	If the TE field-value is empty or if no TE field is present, the only		If the TE field-value is empty or if no TE field is present, the only
	transfer-coding is "chunked". A message with no transfer-coding is		transfer-coding is "chunked". A message with no transfer-coding is
	always acceptable.		always acceptable.
	9.6. Trailer		9.6. Trailer
	The "Trailer" header field indicates that the given set of header		The "Trailer" header field indicates that the given set of header
	fields is present in the trailer of a message encoded with chunked		fields is present in the trailer of a message encoded with chunked
	transfer-coding.		transfer-coding.
	Trailer = "Trailer" ":" OWS Trailer-v		Trailer = 1#field-name
	Trailer-v = 1#field-name
	An HTTP/1.1 message SHOULD include a Trailer header field in a		An HTTP/1.1 message SHOULD include a Trailer header field in a
	message using chunked transfer-coding with a non-empty trailer.		message using chunked transfer-coding with a non-empty trailer.
	Doing so allows the recipient to know which header fields to expect		Doing so allows the recipient to know which header fields to expect
	in the trailer.		in the trailer.
	If no Trailer header field is present, the trailer SHOULD NOT include		If no Trailer header field is present, the trailer SHOULD NOT include
	any header fields. See Section 6.2.1 for restrictions on the use of		any header fields. See Section 6.2.1 for restrictions on the use of
	trailer fields in a "chunked" transfer-coding.		trailer fields in a "chunked" transfer-coding.
	skipping to change at page 58, line 13		skipping to change at page 58, line 7
	o Trailer		o Trailer
	9.7. Transfer-Encoding		9.7. Transfer-Encoding
	The "Transfer-Encoding" header field indicates what transfer-codings		The "Transfer-Encoding" header field indicates what transfer-codings
	(if any) have been applied to the message body. It differs from		(if any) have been applied to the message body. It differs from
	Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings		Content-Encoding (Section 2.2 of [Part3]) in that transfer-codings
	are a property of the message (and therefore are removed by		are a property of the message (and therefore are removed by
	intermediaries), whereas content-codings are not.		intermediaries), whereas content-codings are not.
	Transfer-Encoding = "Transfer-Encoding" ":" OWS		Transfer-Encoding = 1#transfer-coding
	Transfer-Encoding-v
	Transfer-Encoding-v = 1#transfer-coding
	Transfer-codings are defined in Section 6.2. An example is:		Transfer-codings are defined in Section 6.2. An example is:
	Transfer-Encoding: chunked		Transfer-Encoding: chunked
	If multiple encodings have been applied to a representation, the		If multiple encodings have been applied to a representation, the
	transfer-codings MUST be listed in the order in which they were		transfer-codings MUST be listed in the order in which they were
	applied. Additional information about the encoding parameters MAY be		applied. Additional information about the encoding parameters MAY be
	provided by other header fields not defined by this specification.		provided by other header fields not defined by this specification.
	Many older HTTP/1.0 applications do not understand the Transfer-		Many older HTTP/1.0 applications do not understand the Transfer-
	Encoding header field.		Encoding header field.
	9.8. Upgrade		9.8. Upgrade
	The "Upgrade" header field allows the client to specify what		The "Upgrade" header field allows the client to specify what
	additional communication protocols it would like to use, if the		additional communication protocols it would like to use, if the
	server chooses to switch protocols. Servers can use it to indicate		server chooses to switch protocols. Servers can use it to indicate
	what protocols they are willing to switch to.		what protocols they are willing to switch to.
	Upgrade = "Upgrade" ":" OWS Upgrade-v		Upgrade = 1#product
	Upgrade-v = 1#product
	For example,		For example,
	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11		Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
	The Upgrade header field is intended to provide a simple mechanism		The Upgrade header field is intended to provide a simple mechanism
	for transition from HTTP/1.1 to some other, incompatible protocol.		for transition from HTTP/1.1 to some other, incompatible protocol.
	It does so by allowing the client to advertise its desire to use		It does so by allowing the client to advertise its desire to use
	another protocol, such as a later version of HTTP with a higher major		another protocol, such as a later version of HTTP with a higher major
	version number, even though the current request has been made using		version number, even though the current request has been made using
	skipping to change at page 60, line 38		skipping to change at page 60, line 28
	The "Via" header field MUST be sent by a proxy or gateway to indicate		The "Via" header field MUST be sent by a proxy or gateway to indicate
	the intermediate protocols and recipients between the user agent and		the intermediate protocols and recipients between the user agent and
	the server on requests, and between the origin server and the client		the server on requests, and between the origin server and the client
	on responses. It is analogous to the "Received" field used by email		on responses. It is analogous to the "Received" field used by email
	systems (Section 3.6.7 of [RFC5322]) and is intended to be used for		systems (Section 3.6.7 of [RFC5322]) and is intended to be used for
	tracking message forwards, avoiding request loops, and identifying		tracking message forwards, avoiding request loops, and identifying
	the protocol capabilities of all senders along the request/response		the protocol capabilities of all senders along the request/response
	chain.		chain.
	Via = "Via" ":" OWS Via-v		Via = 1#( received-protocol RWS received-by
	Via-v = 1#( received-protocol RWS received-by
	[ RWS comment ] )		[ RWS comment ] )
	received-protocol = [ protocol-name "/" ] protocol-version		received-protocol = [ protocol-name "/" ] protocol-version
	protocol-name = token		protocol-name = token
	protocol-version = token		protocol-version = token
	received-by = ( uri-host [ ":" port ] ) / pseudonym		received-by = ( uri-host [ ":" port ] ) / pseudonym
	pseudonym = token		pseudonym = token
	The received-protocol indicates the protocol version of the message		The received-protocol indicates the protocol version of the message
	received by the server or client along each segment of the request/		received by the server or client along each segment of the request/
	response chain. The received-protocol version is appended to the Via		response chain. The received-protocol version is appended to the Via
	skipping to change at page 69, line 40		skipping to change at page 69, line 29
	technology -- 8-bit single-byte coded		technology -- 8-bit single-byte coded
	graphic character sets -- Part 1:		graphic character sets -- Part 1:
	Latin alphabet No. 1", ISO/		Latin alphabet No. 1", ISO/
	IEC 8859-1:1998, 1998.		IEC 8859-1:1998, 1998.
	[Part2] Fielding, R., Ed., Gettys, J., Mogul,		[Part2] Fielding, R., Ed., Gettys, J., Mogul,
	J., Frystyk, H., Masinter, L., Leach,		J., Frystyk, H., Masinter, L., Leach,
	P., Berners-Lee, T., Lafon, Y., Ed.,		P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part		and J. Reschke, Ed., "HTTP/1.1, part
	2: Message Semantics",		2: Message Semantics",
	draft-ietf-httpbis-p2-semantics-13		draft-ietf-httpbis-p2-semantics-14
	(work in progress), March 2011.		(work in progress), April 2011.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul,		[Part3] Fielding, R., Ed., Gettys, J., Mogul,
	J., Frystyk, H., Masinter, L., Leach,		J., Frystyk, H., Masinter, L., Leach,
	P., Berners-Lee, T., Lafon, Y., Ed.,		P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part		and J. Reschke, Ed., "HTTP/1.1, part
	3: Message Payload and Content		3: Message Payload and Content
	Negotiation",		Negotiation",
	draft-ietf-httpbis-p3-payload-13 (work		draft-ietf-httpbis-p3-payload-14 (work
	in progress), March 2011.		in progress), April 2011.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul,		[Part6] Fielding, R., Ed., Gettys, J., Mogul,
	J., Frystyk, H., Masinter, L., Leach,		J., Frystyk, H., Masinter, L., Leach,
	P., Berners-Lee, T., Lafon, Y., Ed.,		P., Berners-Lee, T., Lafon, Y., Ed.,
	Nottingham, M., Ed., and J. Reschke,		Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP/1.1, part 6: Caching",		Ed., "HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-13 (work		draft-ietf-httpbis-p6-cache-14 (work
	in progress), March 2011.		in progress), April 2011.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB
	Compressed Data Format Specification		Compressed Data Format Specification
	version 3.3", RFC 1950, May 1996.		version 3.3", RFC 1950, May 1996.
	RFC 1950 is an Informational RFC, thus		RFC 1950 is an Informational RFC, thus
	it might be less stable than this		it might be less stable than this
	specification. On the other hand,		specification. On the other hand,
	this downward reference was present		this downward reference was present
	since the publication of RFC 2068 in		since the publication of RFC 2068 in
	skipping to change at page 77, line 39		skipping to change at page 77, line 23
	Update use of abs_path production from RFC 1808 to the path-absolute		Update use of abs_path production from RFC 1808 to the path-absolute
	+ query components of RFC 3986. State that the asterisk form is		+ query components of RFC 3986. State that the asterisk form is
	allowed for the OPTIONS request method only. (Section 4.1.2)		allowed for the OPTIONS request method only. (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)
			Change ABNF productions for header fields to only define the field
			value. (Section 9)
	Clarify exactly when close connection options must be sent.		Clarify exactly when close connection options must be sent.
	(Section 9.1)		(Section 9.1)
	Define the semantics of the "Upgrade" header field in responses other		Define the semantics of the "Upgrade" header field in responses other
	than 101 (this was incorporated from [RFC2817]). (Section 9.8)		than 101 (this was incorporated from [RFC2817]). (Section 9.8)
	Appendix C. Collected ABNF		Appendix C. Collected ABNF
	BWS = OWS		BWS = OWS
	Chunked-Body = *chunk last-chunk trailer-part CRLF		Chunked-Body = *chunk last-chunk trailer-part CRLF
	Connection = "Connection:" OWS Connection-v		Connection = *( "," OWS ) connection-token *( OWS "," [ OWS
	Connection-v = *( "," OWS ) connection-token *( OWS "," [ OWS
	connection-token ] )		connection-token ] )
			Content-Length = 1*DIGIT
	Content-Length = "Content-Length:" OWS 1*Content-Length-v		Date = HTTP-date
	Content-Length-v = 1*DIGIT
	Date = "Date:" OWS Date-v
	Date-v = HTTP-date
	GMT = %x47.4D.54 ; GMT		GMT = %x47.4D.54 ; GMT
	HTTP-Prot-Name = %x48.54.54.50 ; HTTP		HTTP-Prot-Name = %x48.54.54.50 ; HTTP
	HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT		HTTP-Version = HTTP-Prot-Name "/" 1*DIGIT "." 1*DIGIT
	HTTP-date = rfc1123-date / obs-date		HTTP-date = rfc1123-date / obs-date
	HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body		HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
	]		]
	Host = "Host:" OWS Host-v		Host = uri-host [ ":" port ]
	Host-v = uri-host [ ":" port ]
	Method = token		Method = token
	OWS = *( [ obs-fold ] WSP )		OWS = *( [ obs-fold ] WSP )
	RWS = 1*( [ obs-fold ] WSP )		RWS = 1*( [ obs-fold ] WSP )
	Reason-Phrase = *( WSP / VCHAR / obs-text )		Reason-Phrase = *( WSP / VCHAR / obs-text )
	Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]		Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
	Request-Line = Method SP request-target SP HTTP-Version CRLF		Request-Line = Method SP request-target SP HTTP-Version CRLF
	Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]		Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
	Status-Code = 3DIGIT		Status-Code = 3DIGIT
	Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF		Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
	skipping to change at page 78, line 34		skipping to change at page 78, line 15
	RWS = 1*( [ obs-fold ] WSP )		RWS = 1*( [ obs-fold ] WSP )
	Reason-Phrase = *( WSP / VCHAR / obs-text )		Reason-Phrase = *( WSP / VCHAR / obs-text )
	Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]		Request = Request-Line *( header-field CRLF ) CRLF [ message-body ]
	Request-Line = Method SP request-target SP HTTP-Version CRLF		Request-Line = Method SP request-target SP HTTP-Version CRLF
	Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]		Response = Status-Line *( header-field CRLF ) CRLF [ message-body ]
	Status-Code = 3DIGIT		Status-Code = 3DIGIT
	Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF		Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
	TE = "TE:" OWS TE-v		TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]
	TE-v = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]		Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
	Trailer = "Trailer:" OWS Trailer-v		Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
	Trailer-v = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
	Transfer-Encoding = "Transfer-Encoding:" OWS Transfer-Encoding-v
	Transfer-Encoding-v = *( "," OWS ) transfer-coding *( OWS "," [ OWS
	transfer-coding ] )		transfer-coding ] )
	URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>		URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
	Upgrade = "Upgrade:" OWS Upgrade-v		Upgrade = *( "," OWS ) product *( OWS "," [ OWS product ] )
	Upgrade-v = *( "," OWS ) product *( OWS "," [ OWS product ] )
	Via = "Via:" OWS Via-v		Via = *( "," OWS ) received-protocol RWS received-by [ RWS comment ]
	Via-v = *( "," OWS ) received-protocol RWS received-by [ RWS comment		*( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ] ]
	] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]		)
	] )
	absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>		absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
	asctime-date = day-name SP date3 SP time-of-day SP year		asctime-date = day-name SP date3 SP time-of-day SP year
	attribute = token		attribute = token
	authority = <authority, defined in [RFC3986], Section 3.2>		authority = <authority, defined in [RFC3986], Section 3.2>
	chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF		chunk = chunk-size *WSP [ chunk-ext ] CRLF chunk-data CRLF
	chunk-data = 1*OCTET		chunk-data = 1*OCTET
	chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )		chunk-ext = *( ";" *WSP chunk-ext-name [ "=" chunk-ext-val ] *WSP )
	chunk-ext-name = token		chunk-ext-name = token
	skipping to change at page 90, line 36		skipping to change at page 90, line 14
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate		o <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
	Upgrade details from RFC2817"		Upgrade details from RFC2817"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle		o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
	ABNFs for header fields"		ABNFs for header fields"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC		o <http://tools.ietf.org/wg/httpbis/trac/ticket/279>: "update RFC
	2109 reference"		2109 reference"
			D.15. Since draft-ietf-httpbis-p1-messaging-13
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/53>: "Allow is not
			in 13.5.2"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
			ABNFs for header fields"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/286>: "Content-
			Length ABNF broken"
	Index		Index
	A		A
	absolute-URI form (of request-target) 29		absolute-URI form (of request-target) 29
	accelerator 13		accelerator 13
	application/http Media Type 64		application/http Media Type 63
	asterisk form (of request-target) 28		asterisk form (of request-target) 28
	authority form (of request-target) 29		authority form (of request-target) 29
	B		B
	browser 10		browser 10
	C		C
	cache 14		cache 14
	cacheable 14		cacheable 14
	captive portal 14		captive portal 14
	skipping to change at page 91, line 42		skipping to change at page 91, line 33
	chunk 37		chunk 37
	chunk-data 37		chunk-data 37
	chunk-ext 37		chunk-ext 37
	chunk-ext-name 37		chunk-ext-name 37
	chunk-ext-val 37		chunk-ext-val 37
	chunk-size 37		chunk-size 37
	Chunked-Body 37		Chunked-Body 37
	comment 23		comment 23
	Connection 52		Connection 52
	connection-token 52		connection-token 52
	Connection-v 52
	Content-Length 53		Content-Length 53
	Content-Length-v 53
	CR 7		CR 7
	CRLF 7		CRLF 7
	ctext 23		ctext 23
	CTL 7		CTL 7
	Date 53		Date 53
	Date-v 53
	date1 35		date1 35
	date2 36		date2 36
	date3 36		date3 36
	day 35		day 35
	day-name 35		day-name 35
	day-name-l 35		day-name-l 35
	DIGIT 7		DIGIT 7
	DQUOTE 7		DQUOTE 7
	field-content 22		field-content 22
	field-name 22		field-name 22
	field-value 22		field-value 22
	GMT 35		GMT 35
	header-field 22		header-field 22
	HEXDIG 7		HEXDIG 7
	Host 55		Host 55
	Host-v 55
	hour 35		hour 35
	HTTP-date 34		HTTP-date 34
	HTTP-message 21		HTTP-message 21
	HTTP-Prot-Name 15		HTTP-Prot-Name 15
	http-URI 18		http-URI 18
	HTTP-Version 15		HTTP-Version 15
	https-URI 19		https-URI 19
	last-chunk 37		last-chunk 37
	LF 7		LF 7
	message-body 24		message-body 24
	skipping to change at page 93, line 23		skipping to change at page 93, line 10
	second 35		second 35
	SP 7		SP 7
	special 9		special 9
	Status-Code 33		Status-Code 33
	Status-Line 33		Status-Line 33
	t-codings 56		t-codings 56
	tchar 9		tchar 9
	TE 56		TE 56
	te-ext 56		te-ext 56
	te-params 56		te-params 56
	TE-v 56
	time-of-day 35		time-of-day 35
	token 9		token 9
	Trailer 57		Trailer 57
	trailer-part 37		trailer-part 37
	Trailer-v 57
	transfer-coding 36		transfer-coding 36
	Transfer-Encoding 58		Transfer-Encoding 58
	Transfer-Encoding-v 58
	transfer-extension 36		transfer-extension 36
	transfer-parameter 36		transfer-parameter 36
	Upgrade 58		Upgrade 58
	Upgrade-v 58
	uri-host 17		uri-host 17
	URI-reference 17		URI-reference 17
	value 36		value 36
	VCHAR 7		VCHAR 7
	Via 60		Via 60
	Via-v 60
	word 9		word 9
	WSP 7		WSP 7
	year 35		year 35
	gzip (Coding Format) 40		gzip (Coding Format) 40
	H		H
	header field 20		header field 20
	Header Fields		Header Fields
	Connection 51		Connection 51
	Content-Length 53		Content-Length 53
	Date 53		Date 53
	Host 55		Host 55
	TE 56		TE 56
	Trailer 57		Trailer 57
	Transfer-Encoding 58		Transfer-Encoding 57
	Upgrade 58		Upgrade 58
	Via 60		Via 60
	header section 20		header section 20
	headers 20		headers 20
	Host header field 55		Host header field 55
	http URI scheme 18		http URI scheme 18
	https URI scheme 19		https URI scheme 19
	I		I
	inbound 12		inbound 12
	interception proxy 14		interception proxy 14
	intermediary 12		intermediary 12
	M		M
	Media Type		Media Type
	application/http 64		application/http 63
	message/http 62		message/http 62
	message 11		message 11
	message/http Media Type 62		message/http Media Type 62
	N		N
	non-transforming proxy 13		non-transforming proxy 13
	O		O
	origin form (of request-target) 29		origin form (of request-target) 29
	origin server 10		origin server 10
	outbound 12		outbound 12
	P		P
	proxy 13		proxy 13
	R		R
			recipient 10
	request 11		request 11
	resource 17		resource 17
	response 11		response 11
	reverse proxy 13		reverse proxy 13
	S		S
			sender 10
	server 10		server 10
	spider 10		spider 10
	T		T
	target resource 31		target resource 31
	TE header field 56		TE header field 56
	Trailer header field 57		Trailer header field 57
	Transfer-Encoding header field 58		Transfer-Encoding header field 57
	transforming proxy 13		transforming proxy 13
	transparent proxy 14		transparent proxy 14
	tunnel 14		tunnel 14
	U		U
	Upgrade header field 58		Upgrade header field 58
	upstream 12		upstream 12
	URI scheme		URI scheme
	http 18		http 18
	https 19		https 19
End of changes. 63 change blocks.
	98 lines changed or deleted		96 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/