< draft-ietf-httpbis-p1-messaging-24.txt		draft-ietf-httpbis-p1-messaging-25.txt >
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2145,2616 (if approved) J. Reschke, Ed.		Obsoletes: 2145,2616 (if approved) J. Reschke, Ed.
	Updates: 2817,2818 (if approved) greenbytes		Updates: 2817,2818 (if approved) greenbytes
	Intended status: Standards Track September 25, 2013		Intended status: Standards Track November 17, 2013
	Expires: March 29, 2014		Expires: May 21, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing		Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
	draft-ietf-httpbis-p1-messaging-24		draft-ietf-httpbis-p1-messaging-25
	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 provides an		information initiative since 1990. This document provides an
	overview of HTTP architecture and its associated terminology, defines		overview of HTTP architecture and its associated terminology, defines
	the "http" and "https" Uniform Resource Identifier (URI) schemes,		the "http" and "https" Uniform Resource Identifier (URI) schemes,
	defines the HTTP/1.1 message syntax and parsing requirements, and		defines the HTTP/1.1 message syntax and parsing requirements, and
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.4.		The changes in this draft are summarized in Appendix C.2.
	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
	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 March 29, 2014.		This Internet-Draft will expire on May 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 47 ¶		skipping to change at page 3, line 47 ¶
	5.6. Associating a Response to a Request . . . . . . . . . . . 46		5.6. Associating a Response to a Request . . . . . . . . . . . 46
	5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46		5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
	5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46		5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 46
	5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48		5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48
	6. Connection Management . . . . . . . . . . . . . . . . . . . . 49		6. Connection Management . . . . . . . . . . . . . . . . . . . . 49
	6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49		6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 49
	6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51		6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51
	6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51		6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 51
	6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52		6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 52
	6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53		6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
	6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54		6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 53
	6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54		6.5. Failures and Time-outs . . . . . . . . . . . . . . . . . . 54
	6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55		6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55
	6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56		6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
	7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58		7. ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
	8.1. Header Field Registration . . . . . . . . . . . . . . . . 59		8.1. Header Field Registration . . . . . . . . . . . . . . . . 59
	8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60		8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60
	8.3. Internet Media Type Registration . . . . . . . . . . . . . 60		8.3. Internet Media Type Registration . . . . . . . . . . . . . 60
	8.3.1. Internet Media Type message/http . . . . . . . . . . . 61		8.3.1. Internet Media Type message/http . . . . . . . . . . . 60
	8.3.2. Internet Media Type application/http . . . . . . . . . 62		8.3.2. Internet Media Type application/http . . . . . . . . . 61
	8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63		8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
	8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63		8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63
	8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 63		8.4.2. Registration . . . . . . . . . . . . . . . . . . . . . 63
	8.5. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64		8.5. Content Coding Registration . . . . . . . . . . . . . . . 64
	8.5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 64		8.6. Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64
	8.5.2. Upgrade Token Registration . . . . . . . . . . . . . . 65		8.6.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 64
			8.6.2. Upgrade Token Registration . . . . . . . . . . . . . . 65
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 65		9. Security Considerations . . . . . . . . . . . . . . . . . . . 65
	9.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 65		9.1. DNS-related Attacks . . . . . . . . . . . . . . . . . . . 65
	9.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 65		9.2. Intermediaries and Caching . . . . . . . . . . . . . . . . 65
	9.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 66		9.3. Buffer Overflows . . . . . . . . . . . . . . . . . . . . . 66
	9.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 66		9.4. Message Integrity . . . . . . . . . . . . . . . . . . . . 66
	9.5. Server Log Information . . . . . . . . . . . . . . . . . . 67		9.5. Server Log Information . . . . . . . . . . . . . . . . . . 67
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 67		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 68
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 69
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 69		11.1. Normative References . . . . . . . . . . . . . . . . . . . 69
	11.2. Informative References . . . . . . . . . . . . . . . . . . 70		11.2. Informative References . . . . . . . . . . . . . . . . . . 71
	Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 72		Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 72
	A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 73		A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 73
	A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 73		A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 73
	A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 73		A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 74
	A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 74		A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 74
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 74		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 74
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 76		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 77
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 79		publication) . . . . . . . . . . . . . . . . . . . . 79
	C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 79		C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 79
	C.2. Since draft-ietf-httpbis-p1-messaging-21 . . . . . . . . . 79		C.2. Since draft-ietf-httpbis-p1-messaging-24 . . . . . . . . . 79
	C.3. Since draft-ietf-httpbis-p1-messaging-22 . . . . . . . . . 80		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
	C.4. Since draft-ietf-httpbis-p1-messaging-23 . . . . . . . . . 82
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
	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 self-		request/response protocol that uses extensible semantics and self-
	descriptive message payloads for flexible interaction with network-		descriptive message payloads for flexible interaction with network-
	based hypertext information systems. This document is the first in a		based hypertext information systems. This document is the first in a
	series of documents that collectively form the HTTP/1.1		series of documents that collectively form the HTTP/1.1
	specification:		specification:
	skipping to change at page 12, line 44 ¶		skipping to change at page 12, line 44 ¶
	resource owners, and protocol element registrations when they apply		resource owners, and protocol element registrations when they apply
	beyond the scope of a single communication.		beyond the scope of a single communication.
	The verb "generate" is used instead of "send" where a requirement		The verb "generate" is used instead of "send" where a requirement
	differentiates between creating a protocol element and merely		differentiates between creating a protocol element and merely
	forwarding a received element downstream.		forwarding a received element downstream.
	An implementation is considered conformant if it complies with all of		An implementation is considered conformant if it complies with all of
	the requirements associated with the roles it partakes in HTTP.		the requirements associated with the roles it partakes in HTTP.
	Conformance includes both the syntax and semantics of HTTP protocol		Conformance includes both the syntax and semantics of protocol
	elements. A sender MUST NOT generate protocol elements that convey a		elements. A sender MUST NOT generate protocol elements that convey a
	meaning that is known by that sender to be false. A sender MUST NOT		meaning that is known by that sender to be false. A sender MUST NOT
	generate protocol elements that do not match the grammar defined by		generate protocol elements that do not match the grammar defined by
	the corresponding ABNF rules. Within a given message, a sender MUST		the corresponding ABNF rules. Within a given message, a sender MUST
	NOT generate protocol elements or syntax alternatives that are only		NOT generate protocol elements or syntax alternatives that are only
	allowed to be generated by participants in other roles (i.e., a role		allowed to be generated by participants in other roles (i.e., a role
	that the sender does not have for that message).		that the sender does not have for that message).
	When a received protocol element is parsed, the recipient MUST be		When a received protocol element is parsed, the recipient MUST be
	able to parse any value of reasonable length that is applicable to		able to parse any value of reasonable length that is applicable to
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	header fields ought to be implemented by all HTTP/1.x implementations		header fields ought to be implemented by all HTTP/1.x implementations
	whether or not they advertise conformance with HTTP/1.1.		whether or not they advertise conformance with HTTP/1.1.
	New header fields can be introduced without changing the protocol		New header fields can be introduced without changing the protocol
	version if their defined semantics allow them to be safely ignored by		version if their defined semantics allow them to be safely ignored by
	recipients that do not recognize them. Header field extensibility is		recipients that do not recognize them. Header field extensibility is
	discussed in Section 3.2.1.		discussed in Section 3.2.1.
	Intermediaries that process HTTP messages (i.e., all intermediaries		Intermediaries that process HTTP messages (i.e., all intermediaries
	other than those acting as tunnels) MUST send their own HTTP-version		other than those acting as tunnels) MUST send their own HTTP-version
	in forwarded messages. In other words, they MUST NOT blindly forward		in forwarded messages. In other words, they are not allowed to
	the first line of an HTTP message without ensuring that the protocol		blindly forward the first line of an HTTP message without ensuring
	version in that message matches a version to which that intermediary		that the protocol version in that message matches a version to which
	is conformant for both the receiving and sending of messages.		that intermediary is conformant for both the receiving and sending of
	Forwarding an HTTP message without rewriting the HTTP-version might		messages. Forwarding an HTTP message without rewriting the HTTP-
	result in communication errors when downstream recipients use the		version might result in communication errors when downstream
	message sender's version to determine what features are safe to use		recipients use the message sender's version to determine what
	for later communication with that sender.		features are safe to use for later communication with that sender.
	A client SHOULD send a request version equal to the highest version		A client SHOULD send a request version equal to the highest version
	to which the client is conformant and whose major version is no		to which the client is conformant and whose major version is no
	higher than the highest version supported by the server, if this is		higher than the highest version supported by the server, if this is
	known. A client MUST NOT send a version to which it is not		known. A client MUST NOT send a version to which it is not
	conformant.		conformant.
	A client MAY send a lower request version if it is known that the		A client MAY send a lower request version if it is known that the
	server incorrectly implements the HTTP specification, but only after		server incorrectly implements the HTTP specification, but only after
	the client has attempted at least one normal request and determined		the client has attempted at least one normal request and determined
	from the response status code or header fields (e.g., Server) that		from the response status code or header fields (e.g., Server) that
	the server improperly handles higher request versions.		the server improperly handles higher request versions.
	A server SHOULD send a response version equal to the highest version		A server SHOULD send a response version equal to the highest version
	to which the server is conformant and whose major version is less		to which the server is conformant that has a major version less than
	than or equal to the one received in the request. A server MUST NOT		or equal to the one received in the request. A server MUST NOT send
	send a version to which it is not conformant. A server MAY send a		a version to which it is not conformant. A server can send a 505
	505 (HTTP Version Not Supported) response if it cannot send a		(HTTP Version Not Supported) response if it wishes, for any reason,
	response using the major version used in the client's request.		to refuse service of the client's major protocol version.
	A server MAY send an HTTP/1.0 response to a request if it is known or		A server MAY send an HTTP/1.0 response to a request if it is known or
	suspected that the client incorrectly implements the HTTP		suspected that the client incorrectly implements the HTTP
	specification and is incapable of correctly processing later version		specification and is incapable of correctly processing later version
	responses, such as when a client fails to parse the version number		responses, such as when a client fails to parse the version number
	correctly or when an intermediary is known to blindly forward the		correctly or when an intermediary is known to blindly forward the
	HTTP-version even when it doesn't conform to the given minor version		HTTP-version even when it doesn't conform to the given minor version
	of the protocol. Such protocol downgrades SHOULD NOT be performed		of the protocol. Such protocol downgrades SHOULD NOT be performed
	unless triggered by specific client attributes, such as when one or		unless triggered by specific client attributes, such as when one or
	more of the request header fields (e.g., User-Agent) uniquely match		more of the request header fields (e.g., User-Agent) uniquely match
	skipping to change at page 31, line 14 ¶		skipping to change at page 31, line 14 ¶
	Aside from the cases defined above, in the absence of Transfer-		Aside from the cases defined above, in the absence of Transfer-
	Encoding, an origin server SHOULD send a Content-Length header field		Encoding, an origin server SHOULD send a Content-Length header field
	when the payload body size is known prior to sending the complete		when the payload body size is known prior to sending the complete
	header section. This will allow downstream recipients to measure		header section. This will allow downstream recipients to measure
	transfer progress, know when a received message is complete, and		transfer progress, know when a received message is complete, and
	potentially reuse the connection for additional requests.		potentially reuse the connection for additional requests.
	Any Content-Length field value greater than or equal to zero is		Any Content-Length field value greater than or equal to zero is
	valid. Since there is no predefined limit to the length of a		valid. Since there is no predefined limit to the length of a
	payload, a recipient SHOULD anticipate potentially large decimal		payload, a recipient MUST anticipate potentially large decimal
	numerals and prevent parsing errors due to integer conversion		numerals and prevent parsing errors due to integer conversion
	overflows (Section 9.3).		overflows (Section 9.3).
	If a message is received that has multiple Content-Length header		If a message is received that has multiple Content-Length header
	fields with field-values consisting of the same decimal value, or a		fields with field-values consisting of the same decimal value, or a
	single Content-Length header field with a field value containing a		single Content-Length header field with a field value containing a
	list of identical decimal values (e.g., "Content-Length: 42, 42"),		list of identical decimal values (e.g., "Content-Length: 42, 42"),
	indicating that duplicate Content-Length header fields have been		indicating that duplicate Content-Length header fields have been
	generated or combined by an upstream message processor, then the		generated or combined by an upstream message processor, then the
	recipient MUST either reject the message as invalid or replace the		recipient MUST either reject the message as invalid or replace the
	skipping to change at page 50, line 36 ¶		skipping to change at page 50, line 36 ¶
	Connection = 1#connection-option		Connection = 1#connection-option
	connection-option = token		connection-option = token
	Connection options are case-insensitive.		Connection options are case-insensitive.
	A sender MUST NOT send a connection option corresponding to a header		A sender MUST NOT send a connection option corresponding to a header
	field that is intended for all recipients of the payload. For		field that is intended for all recipients of the payload. For
	example, Cache-Control is never appropriate as a connection option		example, Cache-Control is never appropriate as a connection option
	(Section 5.2 of [Part6]).		(Section 5.2 of [Part6]).
	The connection options do not have to correspond to a header field		The connection options do not always correspond to a header field
	present in the message, since a connection-specific header field		present in the message, since a connection-specific header field
	might not be needed if there are no parameters associated with that		might not be needed if there are no parameters associated with a
	connection option. Recipients that trigger certain connection		connection option. In contrast, a connection-specific header field
	behavior based on the presence of connection options MUST do so based		that is received without a corresponding connection option usually
	on the presence of the connection-option rather than only the		indicates that the field has been improperly forwarded by an
	presence of the optional header field. In other words, if the		intermediary and ought to be ignored by the recipient.
	connection option is received as a header field but not indicated
	within the Connection field-value, then the recipient MUST ignore the
	connection-specific header field because it has likely been forwarded
	by an intermediary that is only partially conformant.
	When defining new connection options, specifications ought to		When defining new connection options, specification authors ought to
	carefully consider existing deployed header fields and ensure that		survey existing header field names and ensure that the new connection
	the new connection option does not share the same name as an		option does not share the same name as an already deployed header
	unrelated header field that might already be deployed. Defining a		field. Defining a new connection option essentially reserves that
	new connection option essentially reserves that potential field-name		potential field-name for carrying additional information related to
	for carrying additional information related to the connection option,		the connection option, since it would be unwise for senders to use
	since it would be unwise for senders to use that field-name for		that field-name for anything else.
	anything else.
	The "close" connection option is defined for a sender to signal that		The "close" connection option is defined for a sender to signal that
	this connection will be closed after completion of the response. For		this connection will be closed after completion of the response. For
	example,		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 sender is going to close the connection after the current		the sender is going to close the connection after the current
	request/response is complete (Section 6.6).		request/response is complete (Section 6.6).
	skipping to change at page 58, line 21 ¶		skipping to change at page 58, line 13 ¶
	of the existing connection; it cannot be used to switch the		of the existing connection; it cannot be used to switch the
	underlying connection (transport) protocol, nor to switch the		underlying connection (transport) protocol, nor to switch the
	existing communication to a different connection. For those		existing communication to a different connection. For those
	purposes, it is more appropriate to use a 3xx (Redirection) response		purposes, it is more appropriate to use a 3xx (Redirection) response
	(Section 6.4 of [Part2]).		(Section 6.4 of [Part2]).
	This specification only defines the protocol name "HTTP" for use by		This specification only defines the protocol name "HTTP" for use by
	the family of Hypertext Transfer Protocols, as defined by the HTTP		the family of Hypertext Transfer Protocols, as defined by the HTTP
	version rules of Section 2.6 and future updates to this		version rules of Section 2.6 and future updates to this
	specification. Additional tokens ought to be registered with IANA		specification. Additional tokens ought to be registered with IANA
	using the registration procedure defined in Section 8.5.		using the registration procedure defined in Section 8.6.
	7. ABNF list extension: #rule		7. ABNF list extension: #rule
	A #rule extension to the ABNF rules of [RFC5234] is used to improve		A #rule extension to the ABNF rules of [RFC5234] is used to improve
	readability in the definitions of some header field values.		readability in the definitions of some header field values.
	A construct "#" is defined, similar to "*", for defining comma-		A construct "#" is defined, similar to "*", for defining comma-
	delimited lists of elements. The full form is "<n>#<m>element"		delimited lists of elements. The full form is "<n>#<m>element"
	indicating at least <n> and at most <m> elements, each separated by a		indicating at least <n> and at most <m> elements, each separated by a
	single comma (",") and optional whitespace (OWS).		single comma (",") and optional whitespace (OWS).
	skipping to change at page 59, line 37 ¶		skipping to change at page 59, line 27 ¶
	", ,"		", ,"
	Appendix B shows the collected ABNF after the list constructs have		Appendix B shows the collected ABNF after the list constructs have
	been expanded, as described above, for recipients.		been expanded, as described above, for recipients.
	8. IANA Considerations		8. IANA Considerations
	8.1. Header Field Registration		8.1. Header Field Registration
	HTTP header fields are registered within the Message Header Field		HTTP header fields are registered within the Message Header Field
	Registry maintained at <http://www.iana.org/assignments/		Registry maintained at
	message-headers/message-header-index.html>.		<http://www.iana.org/assignments/message-headers/>.
	This document defines the following HTTP header fields, so their		This document defines the following HTTP header fields, so their
	associated registry entries shall be updated according to the		associated registry entries shall be updated according to the
	permanent registrations below (see [BCP90]):		permanent registrations below (see [BCP90]):
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	| Connection | http | standard | Section 6.1 |		| Connection | http | standard | Section 6.1 |
	| Content-Length | http | standard | Section 3.3.2 |		| Content-Length | http | standard | Section 3.3.2 |
	skipping to change at page 60, line 35 ¶		skipping to change at page 60, line 17 ¶
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Close | http | reserved | Section 8.1 |		| Close | http | reserved | Section 8.1 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	8.2. URI Scheme Registration		8.2. URI Scheme Registration
	IANA maintains the registry of URI Schemes [BCP115] at		IANA maintains the registry of URI Schemes [BCP115] at
	<http://www.iana.org/assignments/uri-schemes.html>.		<http://www.iana.org/assignments/uri-schemes/>.
	This document defines the following URI schemes, so their associated		This document defines the following URI schemes, so their associated
	registry entries shall be updated according to the permanent		registry entries shall be updated according to the permanent
	registrations below:		registrations below:
	+------------+------------------------------------+---------------+		+------------+------------------------------------+---------------+
	| URI Scheme | Description | Reference |		| URI Scheme | Description | Reference |
	+------------+------------------------------------+---------------+		+------------+------------------------------------+---------------+
	| http | Hypertext Transfer Protocol | Section 2.7.1 |		| http | Hypertext Transfer Protocol | Section 2.7.1 |
	| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |		| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
	+------------+------------------------------------+---------------+		+------------+------------------------------------+---------------+
	8.3. Internet Media Type Registration		8.3. Internet Media Type Registration
			IANA maintains the registry of Internet media types [BCP13] at
			<http://www.iana.org/assignments/media-types>.
	This document serves as the specification for the Internet media		This document serves as the specification for the Internet media
	types "message/http" and "application/http". The following is to be		types "message/http" and "application/http". The following is to be
	registered with IANA (see [BCP13]).		registered with IANA.
	8.3.1. Internet Media Type message/http		8.3.1. Internet Media Type message/http
	The message/http type can be used to enclose a single HTTP request or		The message/http type can be used to enclose a single HTTP request or
	response message, provided that it obeys the MIME restrictions for		response message, provided that it obeys the MIME restrictions for
	all "message" types regarding line length and encodings.		all "message" types regarding line length and encodings.
	Type name: message		Type name: message
	Subtype name: http		Subtype name: http
	skipping to change at page 64, line 18 ¶		skipping to change at page 64, line 5 ¶
	| chunked | Transfer in a series of chunks | Section 4.1 |		| chunked | Transfer in a series of chunks | Section 4.1 |
	| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |		| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
	| deflate | "deflate" compressed data | Section 4.2.2 |		| deflate | "deflate" compressed data | Section 4.2.2 |
	| | ([RFC1951]) inside the "zlib" data | |		| | ([RFC1951]) inside the "zlib" data | |
	| | format ([RFC1950]) | |		| | format ([RFC1950]) | |
	| gzip | GZIP file format [RFC1952] | Section 4.2.3 |		| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
	| x-compress | Deprecated (alias for compress) | Section 4.2.1 |		| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
	| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |		| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
	+------------+--------------------------------------+---------------+		+------------+--------------------------------------+---------------+
	8.5. Upgrade Token Registry		8.5. Content Coding Registration
			IANA maintains the registry of HTTP Content Codings at
			<http://www.iana.org/assignments/http-parameters>.
			The HTTP Content Codings Registry shall be updated with the
			registrations below:
			+------------+--------------------------------------+---------------+
			| Name | Description | Reference |
			+------------+--------------------------------------+---------------+
			| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
			| deflate | "deflate" compressed data | Section 4.2.2 |
			| | ([RFC1951]) inside the "zlib" data | |
			| | format ([RFC1950]) | |
			| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
			| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
			| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
			+------------+--------------------------------------+---------------+
			8.6. Upgrade Token Registry
	The HTTP Upgrade Token Registry defines the name space for protocol-		The HTTP Upgrade Token Registry defines the name space for protocol-
	name tokens used to identify protocols in the Upgrade header field.		name tokens used to identify protocols in the Upgrade header field.
	The registry is maintained at		The registry is maintained at
	<http://www.iana.org/assignments/http-upgrade-tokens>.		<http://www.iana.org/assignments/http-upgrade-tokens>.
	8.5.1. Procedure		8.6.1. Procedure
	Each registered protocol name is associated with contact information		Each registered protocol name is associated with contact information
	and an optional set of specifications that details how the connection		and an optional set of specifications that details how the connection
	will be processed after it has been upgraded.		will be processed after it has been upgraded.
	Registrations happen on a "First Come First Served" basis (see		Registrations happen on a "First Come First Served" basis (see
	Section 4.1 of [RFC5226]) and are subject to the following rules:		Section 4.1 of [RFC5226]) and are subject to the following rules:
	1. A protocol-name token, once registered, stays registered forever.		1. A protocol-name token, once registered, stays registered forever.
	skipping to change at page 65, line 9 ¶		skipping to change at page 65, line 16 ¶
	The IANA will keep a record of all such changes, and make them		The IANA will keep a record of all such changes, and make them
	available upon request.		available upon request.
	7. The IESG MAY reassign responsibility for a protocol token. This		7. The IESG MAY reassign responsibility for a protocol token. This
	will normally only be used in the case when a responsible party		will normally only be used in the case when a responsible party
	cannot be contacted.		cannot be contacted.
	This registration procedure for HTTP Upgrade Tokens replaces that		This registration procedure for HTTP Upgrade Tokens replaces that
	previously defined in Section 7.2 of [RFC2817].		previously defined in Section 7.2 of [RFC2817].
	8.5.2. Upgrade Token Registration		8.6.2. Upgrade Token Registration
	The HTTP Upgrade Token Registry shall be updated with the		The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
	registration below:		with the registration below:
	+-------+----------------------+----------------------+-------------+		+-------+----------------------+----------------------+-------------+
	| Value | Description | Expected Version | Reference |		| Value | Description | Expected Version | Reference |
	| | | Tokens | |		| | | Tokens | |
	+-------+----------------------+----------------------+-------------+		+-------+----------------------+----------------------+-------------+
	| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |		| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
	| | Protocol | (e.g, "2.0") | |		| | Protocol | (e.g, "2.0") | |
	+-------+----------------------+----------------------+-------------+		+-------+----------------------+----------------------+-------------+
	The responsible party is: "IETF (iesg@ietf.org) - Internet		The responsible party is: "IETF (iesg@ietf.org) - Internet
	skipping to change at page 68, line 13 ¶		skipping to change at page 68, line 23 ¶
	group chair.		group chair.
	Since 1999, the following contributors have helped improve the HTTP		Since 1999, the following contributors have helped improve the HTTP
	specification by reporting bugs, asking smart questions, drafting or		specification by reporting bugs, asking smart questions, drafting or
	reviewing text, and evaluating open issues:		reviewing text, and evaluating open issues:
	Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de		Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de
	Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex		Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex
	Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai		Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai
	Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson,		Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson,
	Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok		Andrei Popov, Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn
	Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin		Ulsberg, Ashok Kumar, Balachander Krishnamurthy, Barry Leiba, Ben
	Carlyle, Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern		Laurie, Benjamin Carlyle, Benjamin Niven-Jenkins, Bil Corry, Bill
	Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell,		Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin,
	Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bryce Nesbitt,		Brian Kell, Brian McBarron, Brian Pane, Brian Raymor, Brian Smith,
	Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry,		Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann,
	Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan		Charles Fry, Chris Newman, Cyrus Daboo, Dale Robert Anderson, Dan
	Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, Dave Crocker,		Wing, Dan Winship, Daniel Stenberg, Darrel Miller, Dave Cridland,
	Dave Kristol, Dave Thaler, David Booth, David Singer, David W.		Dave Crocker, Dave Kristol, Dave Thaler, David Booth, David Singer,
	Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane		David W. Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed,
	Wessels, Edward Lee, Eitan Adler, Eliot Lear, Eran Hammer-Lahav, Eric		Duane Wessels, Edward Lee, Eitan Adler, Eliot Lear, Emile Stephan,
	D. Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik		Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence,
	Aronesty, Evan Prodromou, Felix Geisendoerfer, Florian Weimer, Frank		Eric Rescorla, Erik Aronesty, EungJun Yi, Evan Prodromou, Felix
	Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser, Gabor Molnar,		Geisendoerfer, Florian Weimer, Frank Ellermann, Fred Akalin, Fred
	Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, Gili Tzabari,		Bohle, Frederic Kayser, Gabor Molnar, Gabriel Montenegro, Geoffrey
	Grahame Grieve, Greg Wilkins, Grzegorz Calkowski, Harald Tveit		Sneddon, Gervase Markham, Gili Tzabari, Grahame Grieve, Greg Wilkins,
	Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S.		Grzegorz Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge
	Thompson, Henry Story, Herbert van de Sompel, Herve Ruellan, Howard		Hess, Henrik Nordstrom, Henry S. Thompson, Henry Story, Herbert van
	Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilari		de Sompel, Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian
	Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, James Cloos,		Hickson, Ido Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J.
	James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan		Ross Nicoll, James Cloos, James H. Manger, James Lacey, James M.
	Algermissen, Jeff Hodges (who came up with the term 'effective		Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with
	Request-URI'), Jeff Pinner, Jeff Walden, Jim Luther, Jitu Padhye, Joe		the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim
	D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C.		Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, John
	Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John		C. Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John
	Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan		Schneider, John Stracke, John Sullivan, Jonas Sicking, Jonathan A.
	Billington, Jonathan Moore, Jonathan Silvera, Jordi Ros, Joris		Rees, Jonathan Billington, Jonathan Moore, Jonathan Silvera, Jordi
	Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin		Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin,
	Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl		Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh,
	Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman,		Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman,
	Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak,		Konstantin Voronkov, Kris Zyp, Leif Hedstrom, Lisa Dusseault, Maciej
	Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley,		Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark Baker,
	Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst,		Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J.
	Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew		Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch,
	Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael Sweet,		Matthew Cox, Max Clark, Michael Burrows, Michael Hausenblas, Michael
	Michael Tuexen, Michael Welzl, Mike Amundsen, Mike Belshe, Mike		Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen,
	Bishop, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy,		Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin,
	Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams,		Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas
	Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Osama Mazahir, Pablo		Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater,
	Castro, Pat Hayes, Patrick R. McManus, Paul E. Jones, Paul Hoffman,		Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E.
	Paul Marquess, Peter Lepeska, Peter Occil, Peter Saint-Andre, Peter		Jones, Paul Hoffman, Paul Marquess, Peter Lepeska, Peter Occil, Peter
	Watkins, Phil Archer, Philippe Mougin, Phillip Hallam-Baker, Piotr		Saint-Andre, Peter Watkins, Phil Archer, Philippe Mougin, Phillip
	Dobrogost, Poul-Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray		Hallam-Baker, Piotr Dobrogost, Poul-Henning Kamp, Preethi Natarajan,
	Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robby Simpson, Robert		Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robby
	Brewer, Robert Collins, Robert Mattson, Robert O'Callahan, Robert		Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert
	Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto		O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de
	Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, Ryan		Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny
	Hamilton, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam		Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam
	Pullara, Sam Ruby, Scott Lawrence (who maintained the original issues		Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence
	list), Sean B. Palmer, Sebastien Barnoud, Shane McCarron, Shigeki		(who maintained the original issues list), Sean B. Palmer, Sebastien
	Ohtsu, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane		Barnoud, Shane McCarron, Shigeki Ohtsu, Stefan Eissing, Stefan
	Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu		Tilkov, Stefanos Harhalakis, Stephane Bortzmeyer, Stephen Farrell,
	Allamaraju, Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa,		Stephen Ludin, Stuart Williams, Subbu Allamaraju, Subramanian
			Moonesamy, Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa,
	Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Thomas		Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Thomas
	Maslen, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim		Maslen, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim
	Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo		Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo
	Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William		Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William
	A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland,		A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland,
	Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yuchung Cheng,		Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yuchung Cheng,
	Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A.		Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A.
	Shaw, and Zhong Yu.		Shaw, and Zhong Yu.
	See Section 16 of [RFC2616] for additional acknowledgements from		See Section 16 of [RFC2616] for additional acknowledgements from
	prior revisions.		prior revisions.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Semantics and Content",		Transfer Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-24 (work in progress),		draft-ietf-httpbis-p2-semantics-25 (work in progress),
	September 2013.		November 2013.
	[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Conditional Requests",		Transfer Protocol (HTTP/1.1): Conditional Requests",
	draft-ietf-httpbis-p4-conditional-24 (work in		draft-ietf-httpbis-p4-conditional-25 (work in
	progress), September 2013.		progress), November 2013.
	[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"Hypertext Transfer Protocol (HTTP/1.1): Range		"Hypertext Transfer Protocol (HTTP/1.1): Range
	Requests", draft-ietf-httpbis-p5-range-24 (work in		Requests", draft-ietf-httpbis-p5-range-25 (work in
	progress), September 2013.		progress), November 2013.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-24 (work in progress),		draft-ietf-httpbis-p6-cache-25 (work in progress),
	September 2013.		November 2013.
	[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Authentication",		Transfer Protocol (HTTP/1.1): Authentication",
	draft-ietf-httpbis-p7-auth-24 (work in progress),		draft-ietf-httpbis-p7-auth-25 (work in progress),
	September 2013.		November 2013.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, September 1981.		RFC 793, September 1981.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	Format Specification version 3.3", RFC 1950, May 1996.		Format Specification version 3.3", RFC 1950, May 1996.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
	Specification version 1.3", RFC 1951, May 1996.		Specification version 1.3", RFC 1951, May 1996.
	skipping to change at page 76, line 35 ¶		skipping to change at page 76, line 47 ¶
	other than 101 (this was incorporated from [RFC2817]). Furthermore,		other than 101 (this was incorporated from [RFC2817]). Furthermore,
	the ordering in the field value is now significant. (Section 6.7)		the ordering in the field value is now significant. (Section 6.7)
	Empty list elements in list productions (e.g., a list header field		Empty list elements in list productions (e.g., a list header field
	containing ", ,") have been deprecated. (Section 7)		containing ", ,") have been deprecated. (Section 7)
	Registration of Transfer Codings now requires IETF Review		Registration of Transfer Codings now requires IETF Review
	(Section 8.4)		(Section 8.4)
	This specification now defines the Upgrade Token Registry, previously		This specification now defines the Upgrade Token Registry, previously
	defined in Section 7.2 of [RFC2817]. (Section 8.5)		defined in Section 7.2 of [RFC2817]. (Section 8.6)
	The expectation to support HTTP/0.9 requests has been removed.		The expectation to support HTTP/0.9 requests has been removed.
	(Appendix A)		(Appendix A)
	Issues with the Keep-Alive and Proxy-Connection header fields in		Issues with the Keep-Alive and Proxy-Connection header fields in
	requests are pointed out, with use of the latter being discouraged		requests are pointed out, with use of the latter being discouraged
	altogether. (Appendix A.1.2)		altogether. (Appendix A.1.2)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	BWS = OWS		BWS = OWS
	Connection = *( "," OWS ) connection-option *( OWS "," [ OWS		Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
	connection-option ] )		connection-option ] )
	skipping to change at page 79, line 28 ¶		skipping to change at page 79, line 41 ¶
	uri-host = <host, defined in [RFC3986], Section 3.2.2>		uri-host = <host, defined in [RFC3986], Section 3.2.2>
	value = word		value = word
	word = token / quoted-string		word = token / quoted-string
	Appendix C. Change Log (to be removed by RFC Editor before publication)		Appendix C. Change Log (to be removed by RFC Editor before publication)
	C.1. Since RFC 2616		C.1. Since RFC 2616
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the IETF Last Call draft are summarized in <http://
	in <http://trac.tools.ietf.org/html/		trac.tools.ietf.org/html/
	draft-ietf-httpbis-p1-messaging-21#appendix-D>.		draft-ietf-httpbis-p1-messaging-24#appendix-C>.
	C.2. Since draft-ietf-httpbis-p1-messaging-21
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/128>: "Cite HTTPS
	URI scheme definition" (the spec now includes the HTTPs scheme
	definition and thus updates RFC 2818)
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/389>: "mention of
	'proxies' in section about caches"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/390>: "use of ABNF
	terms from RFC 3986"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/391>: "transferring
	URIs with userinfo in payload"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/392>: "editorial
	improvements to message length definition"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/395>: "Connection
	header field MUST vs SHOULD"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/396>: "editorial
	improvements to persistent connections section"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/397>: "URI
	normalization vs empty path"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/408>: "p1 feedback"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/409>: "is parsing
	OBS-FOLD mandatory?"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/410>: "HTTPS and
	Shared Caching"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/411>: "Requirements
	for recipients of ws between start-line and first header field"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/412>: "SP and HT
	when being tolerant"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/414>: "Message
	Parsing Strictness"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/415>: "'Render'"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/419>: "p2 editorial
	feedback"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/420>: "Content-
	Length SHOULD be sent"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/431>: "origin-form
	does not allow path starting with "//""
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/433>: "ambiguity in
	part 1 example"
	C.3. Since draft-ietf-httpbis-p1-messaging-22
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/435>: "Part1 should
	have a reference to TCP (RFC 793)"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type
	registration template issues"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/441>: P1 editorial
	nits
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/442>: "BWS" (vs
	conformance)
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/444>: "obs-fold
	language"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/445>: "Ordering in
	Upgrade"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/446>: "p1 editorial
	feedback"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/447>: "HTTP and TCP
	name delegation"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a
	higher minor HTTP version number"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/451>: "HTTP(S) URIs
	and fragids"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering
	x-gzip and x-deflate"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/460>: "Via and
	gateways"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/465>: "Mention 203
	Non-Authoritative Information in p1"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/476>: "SHOULD and
	conformance"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/477>: "Pipelining
	language"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/482>: "proxy
	handling of a really bad Content-Length"
	C.4. Since draft-ietf-httpbis-p1-messaging-23		C.2. Since draft-ietf-httpbis-p1-messaging-24
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/343>: "chunk-		o <http://tools.ietf.org/wg/httpbis/trac/ticket/502>: "APPSDIR
	extensions" (un-deprecated and explained)		review of draft-ietf-httpbis-p1-messaging-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/483>: "MUST fix
	Content-Length?"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/492>: "list notation		o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value
	defined in appendix"		parsing"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/497>: "Fine-Tuning		o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
	when Upgrade takes effect"		registrations to correct draft"
	Index		Index
	A		A
	absolute-form (of request-target) 42		absolute-form (of request-target) 42
	accelerator 10		accelerator 10
	application/http Media Type 62		application/http Media Type 61
	asterisk-form (of request-target) 42		asterisk-form (of request-target) 42
	authority-form (of request-target) 42		authority-form (of request-target) 42
	B		B
	browser 7		browser 7
	C		C
	cache 11		cache 11
	cacheable 12		cacheable 12
	captive portal 11		captive portal 11
	skipping to change at page 85, line 20 ¶		skipping to change at page 83, line 10 ¶
	http URI scheme 17		http URI scheme 17
	https URI scheme 18		https URI scheme 18
	I		I
	inbound 9		inbound 9
	interception proxy 11		interception proxy 11
	intermediary 9		intermediary 9
	M		M
	Media Type		Media Type
	application/http 62		application/http 61
	message/http 61		message/http 60
	message 7		message 7
	message/http Media Type 61		message/http Media Type 60
	method 21		method 21
	N		N
	non-transforming proxy 10		non-transforming proxy 10
	O		O
	origin server 7		origin server 7
	origin-form (of request-target) 41		origin-form (of request-target) 41
	outbound 9		outbound 9
End of changes. 44 change blocks.
	258 lines changed or deleted		158 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/