draft-ietf-httpbis-messaging-01.txt		draft-ietf-httpbis-messaging-02.txt
	HTTP Working Group R. Fielding, Ed.		HTTP Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 7230 (if approved) M. Nottingham, Ed.		Obsoletes: 7230 (if approved) M. Nottingham, Ed.
	Intended status: Standards Track Fastly		Intended status: Standards Track Fastly
	Expires: December 2, 2018 J. Reschke, Ed.		Expires: January 3, 2019 J. Reschke, Ed.
	greenbytes		greenbytes
	May 31, 2018		July 2, 2018
	HTTP/1.1 Messaging		HTTP/1.1 Messaging
	draft-ietf-httpbis-messaging-01		draft-ietf-httpbis-messaging-02
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level protocol for distributed, collaborative, hypertext information		level protocol for distributed, collaborative, hypertext information
	systems. This document specifies the HTTP/1.1 message syntax,		systems. This document specifies the HTTP/1.1 message syntax,
	message parsing, connection management, and related security		message parsing, connection management, and related security
	concerns.		concerns.
	This document obsoletes portions of RFC 7230.		This document obsoletes portions of RFC 7230.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<https://lists.w3.org/Archives/Public/ietf-http-wg/>.		<https://lists.w3.org/Archives/Public/ietf-http-wg/>.
	Working Group information can be found at <https://httpwg.org/>;		Working Group information can be found at <https://httpwg.org/>;
	source code and issues list for this draft can be found at		source code and issues list for this draft can be found at
	<https://github.com/httpwg/http-core>.		<https://github.com/httpwg/http-core>.
	The changes in this draft are summarized in Appendix D.2.		The changes in this draft are summarized in Appendix D.3.
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 December 2, 2018.		This Internet-Draft will expire on January 3, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 16 ¶		skipping to change at page 3, line 16 ¶
	4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Field Parsing . . . . . . . . . . . . . . . . . . . . . . 15		5.1. Field Parsing . . . . . . . . . . . . . . . . . . . . . . 15
	5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15		5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15
	6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16		6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17		6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
	6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18		6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18
	6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19		6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19
	7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21		7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22		7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22
	7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 22		7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23
	7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23		7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23
	7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24		7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
	7.2. Transfer Codings for Compression . . . . . . . . . . . . 24		7.2. Transfer Codings for Compression . . . . . . . . . . . . 25
	7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25		7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
	7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 26		8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
	9. Connection Management . . . . . . . . . . . . . . . . . . . . 27		9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 27		9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
	9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 29		9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
	9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 29		9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
	9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 30		9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
	9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31		9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
	9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 31		9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
	9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32		9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33
	9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33		9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
	9.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34		9.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.7.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36		9.7.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36
	9.7.2. Upgrade Token Registry . . . . . . . . . . . . . . . 36		9.7.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37
	10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37		10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37
	10.1. Media Type message/http . . . . . . . . . . . . . . . . 37		10.1. Media Type message/http . . . . . . . . . . . . . . . . 38
	10.2. Media Type application/http . . . . . . . . . . . . . . 38		10.2. Media Type application/http . . . . . . . . . . . . . . 39
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 39		11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 39		11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40
	11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 40		11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41
	11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 40		11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 41
	11.4. Message Confidentiality . . . . . . . . . . . . . . . . 41		11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	12.1. Header Field Registration . . . . . . . . . . . . . . . 41		12.1. Header Field Registration . . . . . . . . . . . . . . . 42
	12.2. Media Type Registration . . . . . . . . . . . . . . . . 42		12.2. Media Type Registration . . . . . . . . . . . . . . . . 42
	12.3. Transfer Coding Registration . . . . . . . . . . . . . . 42		12.3. Transfer Coding Registration . . . . . . . . . . . . . . 42
	12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 42		12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	13.1. Normative References . . . . . . . . . . . . . . . . . . 42		13.1. Normative References . . . . . . . . . . . . . . . . . . 43
	13.2. Informative References . . . . . . . . . . . . . . . . . 43		13.2. Informative References . . . . . . . . . . . . . . . . . 44
	Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 45		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46
	Appendix B. Differences between HTTP and MIME . . . . . . . . . 46		Appendix B. Differences between HTTP and MIME . . . . . . . . . 47
	B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 47		B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 48
	B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 47		B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 48
	B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 47		B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 48
	B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 48		B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 49
	B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 48		B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 49
	B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 48		B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 49
	Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 48		Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 49
	C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 49		C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 50
	C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 49		C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 50
	C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 50		C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 51
	C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 50		C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 51
	C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 50		C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 52
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 51		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 52
	D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 51		D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 52
	D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 51		D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 52
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51		D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 53
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level request/response protocol that uses extensible semantics and		level request/response protocol that uses extensible semantics and
	self-descriptive messages for flexible interaction with network-based		self-descriptive messages for flexible interaction with network-based
	hypertext information systems. HTTP is defined by a series of		hypertext information systems. HTTP is defined by a series of
	documents that collectively form the HTTP/1.1 specification:		documents that collectively form the HTTP/1.1 specification:
	o "HTTP Semantics" [Semantics]		o "HTTP Semantics" [Semantics]
	skipping to change at page 6, line 34 ¶		skipping to change at page 6, line 34 ¶
	for determining the length of the message body (Section 6).		for determining the length of the message body (Section 6).
	start-line = request-line / status-line		start-line = request-line / status-line
	In theory, a client could receive requests and a server could receive		In theory, a client could receive requests and a server could receive
	responses, distinguishing them by their different start-line formats.		responses, distinguishing them by their different start-line formats.
	In practice, servers are implemented to only expect a request (a		In practice, servers are implemented to only expect a request (a
	response is interpreted as an unknown or invalid request method) and		response is interpreted as an unknown or invalid request method) and
	clients are implemented to only expect a response.		clients are implemented to only expect a response.
	[[CREF1: Although HTTP makes use of some protocol elements similar to		Although HTTP makes use of some protocol elements similar to the
	the Multipurpose Internet Mail Extensions (MIME) [RFC2045], see		Multipurpose Internet Mail Extensions (MIME) [RFC2045], see
	Appendix B for the differences between HTTP and MIME messages.]]		Appendix B for the differences between HTTP and MIME messages.
	2.2. HTTP Version		2.2. HTTP Version
	HTTP uses a "<major>.<minor>" numbering scheme to indicate versions		HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
	of the protocol. This specification defines version "1.1".		of the protocol. This specification defines version "1.1".
	Section 3.5 of [Semantics] specifies the semantics of HTTP version		Section 3.5 of [Semantics] specifies the semantics of HTTP version
	numbers.		numbers.
	The version of an HTTP/1.x message is indicated by an HTTP-version		The version of an HTTP/1.x message is indicated by an HTTP-version
	field in the start-line. HTTP-version is case-sensitive.		field in the start-line. HTTP-version is case-sensitive.
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 33 ¶
	reason-phrase = *( HTAB / SP / VCHAR / obs-text )		reason-phrase = *( HTAB / SP / VCHAR / obs-text )
	5. Header Fields		5. Header Fields
	Each header field consists of a case-insensitive field name followed		Each header field consists of a case-insensitive field name followed
	by a colon (":"), optional leading whitespace, the field value, and		by a colon (":"), optional leading whitespace, the field value, and
	optional trailing whitespace.		optional trailing whitespace.
	header-field = field-name ":" OWS field-value OWS		header-field = field-name ":" OWS field-value OWS
	[[CREF2: Most HTTP field names and the rules for parsing within field		Most HTTP field names and the rules for parsing within field values
	values are defined in Section 4 of [Semantics]. This section covers		are defined in Section 4 of [Semantics]. This section covers the
	the generic syntax for header field inclusion within, and extraction		generic syntax for header field inclusion within, and extraction
	from, HTTP/1.1 messages. In addition, the following header fields		from, HTTP/1.1 messages. In addition, the following header fields
	are defined by this document because they are specific to HTTP/1.1		are defined by this document because they are specific to HTTP/1.1
	message processing: ]]		message processing:
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	| Connection | http | standard | Section 9.1 |		| Connection | http | standard | Section 9.1 |
	| MIME-Version | http | standard | Appendix B.1 |		| MIME-Version | http | standard | Appendix B.1 |
	| TE | http | standard | Section 7.4 |		| TE | http | standard | Section 7.4 |
	| Transfer-Encoding | http | standard | Section 6.1 |		| Transfer-Encoding | http | standard | Section 6.1 |
	| Upgrade | http | standard | Section 9.7 |		| Upgrade | http | standard | Section 9.7 |
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	skipping to change at page 15, line 23 ¶		skipping to change at page 15, line 23 ¶
	Messages are parsed using a generic algorithm, independent of the		Messages are parsed using a generic algorithm, independent of the
	individual header field names. The contents within a given field		individual header field names. The contents within a given field
	value are not parsed until a later stage of message interpretation		value are not parsed until a later stage of message interpretation
	(usually after the message's entire header section has been		(usually after the message's entire header section has been
	processed).		processed).
	No whitespace is allowed between the header field-name and colon. In		No whitespace is allowed between the header field-name and colon. In
	the past, differences in the handling of such whitespace have led to		the past, differences in the handling of such whitespace have led to
	security vulnerabilities in request routing and response handling. A		security vulnerabilities in request routing and response handling. A
	server MUST reject any received request message that contains		server MUST reject any received request message that contains
	whitespace between a header field-name and colon with a response code		whitespace between a header field-name and colon with a response
	of 400 (Bad Request). A proxy MUST remove any such whitespace from a		status code of 400 (Bad Request). A proxy MUST remove any such
	response message before forwarding the message downstream.		whitespace from a response message before forwarding the message
			downstream.
	A field value might be preceded and/or followed by optional		A field value might be preceded and/or followed by optional
	whitespace (OWS); a single SP preceding the field-value is preferred		whitespace (OWS); a single SP preceding the field-value is preferred
	for consistent readability by humans. The field value does not		for consistent readability by humans. The field value does not
	include any leading or trailing whitespace: OWS occurring before the		include any leading or trailing whitespace: OWS occurring before the
	first non-whitespace octet of the field value or after the last non-		first non-whitespace octet of the field value or after the last non-
	whitespace octet of the field value ought to be excluded by parsers		whitespace octet of the field value ought to be excluded by parsers
	when extracting the field value from a header field.		when extracting the field value from a header field.
	5.2. Obsolete Line Folding		5.2. Obsolete Line Folding
	skipping to change at page 21, line 26 ¶		skipping to change at page 21, line 26 ¶
	property of the message rather than a property of the representation		property of the message rather than a property of the representation
	that is being transferred.		that is being transferred.
	transfer-coding = "chunked" ; Section 7.1		transfer-coding = "chunked" ; Section 7.1
	/ "compress" ; [Semantics], Section 6.1.2.1		/ "compress" ; [Semantics], Section 6.1.2.1
	/ "deflate" ; [Semantics], Section 6.1.2.2		/ "deflate" ; [Semantics], Section 6.1.2.2
	/ "gzip" ; [Semantics], Section 6.1.2.3		/ "gzip" ; [Semantics], Section 6.1.2.3
	/ transfer-extension		/ transfer-extension
	transfer-extension = token *( OWS ";" OWS transfer-parameter )		transfer-extension = token *( OWS ";" OWS transfer-parameter )
	Parameters are in the form of a name or name=value pair.		Parameters are in the form of a name=value pair.
	transfer-parameter = token BWS "=" BWS ( token / quoted-string )		transfer-parameter = token BWS "=" BWS ( token / quoted-string )
	All transfer-coding names are case-insensitive and ought to be		All transfer-coding names are case-insensitive and ought to be
	registered within the HTTP Transfer Coding registry, as defined in		registered within the HTTP Transfer Coding registry, as defined in
	Section 7.3. They are used in the TE (Section 7.4) and Transfer-		Section 7.3. They are used in the TE (Section 7.4) and Transfer-
	Encoding (Section 6.1) header fields.		Encoding (Section 6.1) header fields.
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	| Name | Description | Reference |		| Name | Description | Reference |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	| chunked | Transfer in a series of chunks | Section 7 |		| chunked | Transfer in a series of chunks | Section 7 |
	| | | .1 |		| | | .1 |
	| compress | UNIX "compress" data format [Welch] | Section 7 |		| compress | UNIX "compress" data format [Welch] | Section 7 |
	| | | .2 |		| | | .2 |
	| deflate | "deflate" compressed data ([RFC1951]) | Section 7 |		| deflate | "deflate" compressed data ([RFC1951]) | Section 7 |
	| | inside the "zlib" data format | .2 |		| | inside the "zlib" data format | .2 |
	| | ([RFC1950]) | |		| | ([RFC1950]) | |
	| gzip | GZIP file format [RFC1952] | Section 7 |		| gzip | GZIP file format [RFC1952] | Section 7 |
	| | | .2 |		| | | .2 |
			| trailers | (reserved) | Section 7 |
	| x-compress | Deprecated (alias for compress) | Section 7 |		| x-compress | Deprecated (alias for compress) | Section 7 |
	| | | .2 |		| | | .2 |
	| x-gzip | Deprecated (alias for gzip) | Section 7 |		| x-gzip | Deprecated (alias for gzip) | Section 7 |
	| | | .2 |		| | | .2 |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
			Note: the coding name "trailers" is reserved because it would
			clash with the use of the keyword "trailers" in the TE header
			field (Section 7.4).
	7.1. Chunked Transfer Coding		7.1. Chunked Transfer Coding
	The chunked transfer coding wraps the payload body in order to		The chunked transfer coding wraps the payload body in order to
	transfer it as a series of chunks, each with its own size indicator,		transfer it as a series of chunks, each with its own size indicator,
	followed by an OPTIONAL trailer containing header fields. Chunked		followed by an OPTIONAL trailer containing header fields. Chunked
	enables content streams of unknown size to be transferred as a		enables content streams of unknown size to be transferred as a
	sequence of length-delimited buffers, which enables the sender to		sequence of length-delimited buffers, which enables the sender to
	retain connection persistence and the recipient to know when it has		retain connection persistence and the recipient to know when it has
	received the entire message.		received the entire message.
	skipping to change at page 22, line 42 ¶		skipping to change at page 23, line 17 ¶
	A recipient MUST be able to parse and decode the chunked transfer		A recipient MUST be able to parse and decode the chunked transfer
	coding.		coding.
	7.1.1. Chunk Extensions		7.1.1. Chunk Extensions
	The chunked encoding allows each chunk to include zero or more chunk		The chunked encoding allows each chunk to include zero or more chunk
	extensions, immediately following the chunk-size, for the sake of		extensions, immediately following the chunk-size, for the sake of
	supplying per-chunk metadata (such as a signature or hash), mid-		supplying per-chunk metadata (such as a signature or hash), mid-
	message control information, or randomization of message body size.		message control information, or randomization of message body size.
	chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )		chunk-ext = *( BWS ";" BWS chunk-ext-name
			[ BWS "=" BWS chunk-ext-val ] )
	chunk-ext-name = token		chunk-ext-name = token
	chunk-ext-val = token / quoted-string		chunk-ext-val = token / quoted-string
	The chunked encoding is specific to each connection and is likely to		The chunked encoding is specific to each connection and is likely to
	be removed or recoded by each recipient (including intermediaries)		be removed or recoded by each recipient (including intermediaries)
	before any higher-level application would have a chance to inspect		before any higher-level application would have a chance to inspect
	the extensions. Hence, use of chunk extensions is generally limited		the extensions. Hence, use of chunk extensions is generally limited
	to specialized HTTP services such as "long polling" (where client and		to specialized HTTP services such as "long polling" (where client and
	server can have shared expectations regarding the use of chunk		server can have shared expectations regarding the use of chunk
	skipping to change at page 25, line 18 ¶		skipping to change at page 26, line 4 ¶
	transfer coding names. It is maintained at		transfer coding names. It is maintained at
	<https://www.iana.org/assignments/http-parameters>.		<https://www.iana.org/assignments/http-parameters>.
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Name		o Name
	o Description		o Description
	o Pointer to specification text		o Pointer to specification text
	Names of transfer codings MUST NOT overlap with names of content		Names of transfer codings MUST NOT overlap with names of content
	codings (Section 6.1.2 of [Semantics]) unless the encoding		codings (Section 6.1.2 of [Semantics]) unless the encoding
	transformation is identical, as is the case for the compression		transformation is identical, as is the case for the compression
	codings defined in Section 7.2.		codings defined in Section 7.2.
			The TE header field (Section 7.4) uses a pseudo parameter named "q"
			as rank value when multiple transfer codings are acceptable. Future
			registrations of transfer codings SHOULD NOT define parameters called
			"q" (case-insensitively) in order to avoid ambiguities.
	Values to be added to this namespace require IETF Review (see		Values to be added to this namespace require IETF Review (see
	Section 4.1 of [RFC5226]), and MUST conform to the purpose of		Section 4.8 of [RFC8126]), and MUST conform to the purpose of
	transfer coding defined in this specification.		transfer coding defined in this specification.
	Use of program names for the identification of encoding formats is		Use of program names for the identification of encoding formats is
	not desirable and is discouraged for future encodings.		not desirable and is discouraged for future encodings.
	7.4. TE		7.4. TE
	The "TE" header field in a request indicates what transfer codings,		The "TE" header field in a request indicates what transfer codings,
	besides chunked, the client is willing to accept in response, and		besides chunked, the client is willing to accept in response, and
	whether or not the client is willing to accept trailer fields in a		whether or not the client is willing to accept trailer fields in a
	skipping to change at page 29, line 47 ¶		skipping to change at page 30, line 34 ¶
	based on the most recently received message's protocol version and		based on the most recently received message's protocol version and
	Connection header field (if any):		Connection header field (if any):
	o If the "close" connection option is present, the connection will		o If the "close" connection option is present, the connection will
	not persist after the current response; else,		not persist after the current response; else,
	o If the received protocol is HTTP/1.1 (or later), the connection		o If the received protocol is HTTP/1.1 (or later), the connection
	will persist after the current response; else,		will persist after the current response; else,
	o If the received protocol is HTTP/1.0, the "keep-alive" connection		o If the received protocol is HTTP/1.0, the "keep-alive" connection
	option is present, the recipient is not a proxy, and the recipient		option is present, either the recipient is not a proxy or the
	wishes to honor the HTTP/1.0 "keep-alive" mechanism, the		message is a response, and the recipient wishes to honor the
	connection will persist after the current response; otherwise,		HTTP/1.0 "keep-alive" mechanism, the connection will persist after
			the current response; otherwise,
	o The connection will close after the current response.		o The connection will close after the current response.
	A client MAY send additional requests on a persistent connection		A client MAY send additional requests on a persistent connection
	until it sends or receives a "close" connection option or receives an		until it sends or receives a "close" connection option or receives an
	HTTP/1.0 response without a "keep-alive" connection option.		HTTP/1.0 response without a "keep-alive" connection option.
	In order to remain persistent, all messages on a connection need to		In order to remain persistent, all messages on a connection need to
	have a self-defined message length (i.e., one not defined by closure		have a self-defined message length (i.e., one not defined by closure
	of the connection), as described in Section 6. A server MUST read		of the connection), as described in Section 6. A server MUST read
	skipping to change at page 36, line 36 ¶		skipping to change at page 37, line 25 ¶
	The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"		The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
	defines the namespace for protocol-name tokens used to identify		defines the namespace for protocol-name tokens used to identify
	protocols in the Upgrade header field. The registry is maintained at		protocols in the Upgrade header field. The registry is maintained at
	<https://www.iana.org/assignments/http-upgrade-tokens>.		<https://www.iana.org/assignments/http-upgrade-tokens>.
	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.4 of [RFC8126]) 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.
	2. The registration MUST name a responsible party for the		2. The registration MUST name a responsible party for the
	registration.		registration.
	3. The registration MUST name a point of contact.		3. The registration MUST name a point of contact.
	4. The registration MAY name a set of specifications associated with		4. The registration MAY name a set of specifications associated with
	that token. Such specifications need not be publicly available.		that token. Such specifications need not be publicly available.
	skipping to change at page 41, line 38 ¶		skipping to change at page 42, line 26 ¶
	can be used over many different forms of encrypted connection, with		can be used over many different forms of encrypted connection, with
	the selection of such transports being identified by the choice of		the selection of such transports being identified by the choice of
	URI scheme or within user agent configuration.		URI scheme or within user agent configuration.
	The "https" scheme can be used to identify resources that require a		The "https" scheme can be used to identify resources that require a
	confidential connection, as described in Section 2.5.2 of		confidential connection, as described in Section 2.5.2 of
	[Semantics].		[Semantics].
	12. IANA Considerations		12. IANA Considerations
	This section is to be removed before publishing as an RFC.
	The change controller for the following registrations is: "IETF		The change controller for the following registrations is: "IETF
	(iesg@ietf.org) - Internet Engineering Task Force".		(iesg@ietf.org) - Internet Engineering Task Force".
	12.1. Header Field Registration		12.1. Header Field Registration
	Please update the "Message Headers" registry of "Permanent Message		Please update the "Message Headers" registry of "Permanent Message
	Header Field Names" at <https://www.iana.org/assignments/message-		Header Field Names" at <https://www.iana.org/assignments/message-
	headers> with the header field names listed in the two tables of		headers> with the header field names listed in the two tables of
	Section 5.		Section 5.
	skipping to change at page 42, line 31 ¶		skipping to change at page 43, line 17 ¶
	Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token		Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token
	Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>		Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>
	with the registration procedure of Section 9.7.2 and the upgrade		with the registration procedure of Section 9.7.2 and the upgrade
	token names summarized in the table of Section 9.7.1.		token names summarized in the table of Section 9.7.1.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Caching", draft-ietf-httpbis-cache-01 (work in		Ed., "HTTP Caching", draft-ietf-httpbis-cache-02 (work in
	progress), May 2018.		progress), July 2018.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950,		Specification version 3.3", RFC 1950,
	DOI 10.17487/RFC1950, May 1996,		DOI 10.17487/RFC1950, May 1996,
	<https://www.rfc-editor.org/info/rfc1950>.		<https://www.rfc-editor.org/info/rfc1950>.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,		version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
	<https://www.rfc-editor.org/info/rfc1951>.		<https://www.rfc-editor.org/info/rfc1951>.
	skipping to change at page 43, line 17 ¶		skipping to change at page 43, line 51 ¶
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
	[Semantics]		[Semantics]
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-01		Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-02
	(work in progress), May 2018.		(work in progress), July 2018.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	[Welch] Welch, T., "A Technique for High-Performance Data		[Welch] Welch, T., "A Technique for High-Performance Data
	Compression", IEEE Computer 17(6), June 1984.		Compression", IEEE Computer 17(6), June 1984.
	13.2. Informative References		13.2. Informative References
			[Err4667] RFC Errata, Erratum ID 4667, RFC 7230,
			<https://www.rfc-editor.org/errata/eid4667>.
	[Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting,		[Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting,
	Web Cache Poisoning Attacks, and Related Topics", March		Web Cache Poisoning Attacks, and Related Topics", March
	2004, <http://packetstormsecurity.com/papers/general/		2004, <http://packetstormsecurity.com/papers/general/
	whitepaper_httpresponse.pdf>.		whitepaper_httpresponse.pdf>.
	[Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP		[Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
	Request Smuggling", June 2005,		Request Smuggling", June 2005,
	<http://www.watchfire.com/news/whitepapers.aspx>.		<http://www.watchfire.com/news/whitepapers.aspx>.
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
	skipping to change at page 44, line 20 ¶		skipping to change at page 45, line 10 ¶
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",		Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	RFC 2068, DOI 10.17487/RFC2068, January 1997,		RFC 2068, DOI 10.17487/RFC2068, January 1997,
	<https://www.rfc-editor.org/info/rfc2068>.		<https://www.rfc-editor.org/info/rfc2068>.
	[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,		[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
	"MIME Encapsulation of Aggregate Documents, such as HTML		"MIME Encapsulation of Aggregate Documents, such as HTML
	(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,		(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
	<https://www.rfc-editor.org/info/rfc2557>.		<https://www.rfc-editor.org/info/rfc2557>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<https://www.rfc-editor.org/info/rfc5226>.
	[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008,
	<https://www.rfc-editor.org/info/rfc5322>.		<https://www.rfc-editor.org/info/rfc5322>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	DOI 10.17487/RFC6265, April 2011,		DOI 10.17487/RFC6265, April 2011,
	<https://www.rfc-editor.org/info/rfc6265>.		<https://www.rfc-editor.org/info/rfc6265>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014,
	<https://www.rfc-editor.org/info/rfc7231>.		<https://www.rfc-editor.org/info/rfc7231>.
			[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	Appendix A. Collected ABNF		Appendix A. Collected ABNF
	In the collected ABNF below, list rules are expanded as per		In the collected ABNF below, list rules are expanded as per
	Section 11 of [Semantics].		Section 11 of [Semantics].
	BWS = <BWS, see [Semantics], Section 4.3>		BWS = <BWS, see [Semantics], Section 4.3>
	Connection = *( "," OWS ) connection-option *( OWS "," [ OWS		Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
	connection-option ] )		connection-option ] )
	skipping to change at page 45, line 39 ¶		skipping to change at page 46, line 39 ¶
	absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>		absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
	absolute-form = absolute-URI		absolute-form = absolute-URI
	absolute-path = <absolute-path, see [Semantics], Section 2.4>		absolute-path = <absolute-path, see [Semantics], Section 2.4>
	asterisk-form = "*"		asterisk-form = "*"
	authority = <authority, see [RFC3986], Section 3.2>		authority = <authority, see [RFC3986], Section 3.2>
	authority-form = authority		authority-form = authority
	chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF		chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
	chunk-data = 1*OCTET		chunk-data = 1*OCTET
	chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )		chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val
			] )
	chunk-ext-name = token		chunk-ext-name = token
	chunk-ext-val = token / quoted-string		chunk-ext-val = token / quoted-string
	chunk-size = 1*HEXDIG		chunk-size = 1*HEXDIG
	chunked-body = *chunk last-chunk trailer-part CRLF		chunked-body = *chunk last-chunk trailer-part CRLF
	comment = <comment, see [Semantics], Section 4.2.3>		comment = <comment, see [Semantics], Section 4.2.3>
	connection-option = token		connection-option = token
	field-name = <field-name, see [Semantics], Section 4.2>		field-name = <field-name, see [Semantics], Section 4.2>
	field-value = <field-value, see [Semantics], Section 4.2>		field-value = <field-value, see [Semantics], Section 4.2>
	skipping to change at page 51, line 5 ¶		skipping to change at page 52, line 13 ¶
	message over a MIME-compliant protocol.		message over a MIME-compliant protocol.
	C.2. Changes from RFC 7230		C.2. Changes from RFC 7230
	Most of the sections introducing HTTP's design goals, history,		Most of the sections introducing HTTP's design goals, history,
	architecture, conformance criteria, protocol versioning, URIs,		architecture, conformance criteria, protocol versioning, URIs,
	message routing, and header field values have been moved to		message routing, and header field values have been moved to
	[Semantics]. This document has been reduced to just the messaging		[Semantics]. This document has been reduced to just the messaging
	syntax and connection management requirements specific to HTTP/1.1.		syntax and connection management requirements specific to HTTP/1.1.
			Furthermore:
			In the ABNF for chunked extensions, re-introduce (bad) whitespace
			around ";" and "=". Whitespace was removed in [RFC7230], but later
			this change was found to break existing implementations (see
			[Err4667]). (Section 7.1.1)
			Disallow transfer coding parameters called "q" in order to avoid
			conflicts with the use of ranks in the TE header field.
			(Section 7.3)
	Appendix D. Change Log		Appendix D. Change Log
	This section is to be removed before publishing as an RFC.		This section is to be removed before publishing as an RFC.
	D.1. Between RFC7230 and draft 00		D.1. Between RFC7230 and draft 00
	The changes were purely editorial:		The changes were purely editorial:
	o Change boilerplate and abstract to indicate the "draft" status,		o Change boilerplate and abstract to indicate the "draft" status,
	and update references to ancestor specifications.		and update references to ancestor specifications.
	skipping to change at page 51, line 43 ¶		skipping to change at page 53, line 13 ¶
	from RFC 7230 (Messaging) to semantics [Semantics].		from RFC 7230 (Messaging) to semantics [Semantics].
	o Moved discussion of MIME differences from RFC 7231 (Semantics) to		o Moved discussion of MIME differences from RFC 7231 (Semantics) to
	Appendix B since they mostly cover transforming 1.1 messages.		Appendix B since they mostly cover transforming 1.1 messages.
	o Moved all extensibility tips, registration procedures, and		o Moved all extensibility tips, registration procedures, and
	registry tables from the IANA considerations to normative		registry tables from the IANA considerations to normative
	sections, reducing the IANA considerations to just instructions		sections, reducing the IANA considerations to just instructions
	that will be removed prior to publication as an RFC.		that will be removed prior to publication as an RFC.
			D.3. Since draft-ietf-httpbis-messaging-01
			o Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
			http-core/issues/75>)
			o Resolved erratum 4779, no change needed here
			(<https://github.com/httpwg/http-core/issues/87>,
			<https://www.rfc-editor.org/errata/eid4779>)
			o In Section 7, fixed prose claiming transfer parameters allow bare
			names (<https://github.com/httpwg/http-core/issues/88>,
			<https://www.rfc-editor.org/errata/eid4839>)
			o Resolved erratum 4225, no change needed here
			(<https://github.com/httpwg/http-core/issues/90>,
			<https://www.rfc-editor.org/errata/eid4225>)
			o Replace "response code" with "response status code"
			(<https://github.com/httpwg/http-core/issues/94>,
			<https://www.rfc-editor.org/errata/eid4050>)
			o In Section 9.3, clarify statement about HTTP/1.0 keep-alive
			(<https://github.com/httpwg/http-core/issues/96>,
			<https://www.rfc-editor.org/errata/eid4205>)
			o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="
			(<https://github.com/httpwg/http-core/issues/101>,
			<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-
			editor.org/errata/eid4825>)
			o In Section 7.3, state that transfer codings should not use
			parameters named "q" (<https://github.com/httpwg/http-core/
			issues/15>, <https://www.rfc-editor.org/errata/eid4683>)
			o In Section 7, mark coding name "trailers" as reserved in the IANA
			registry (<https://github.com/httpwg/http-core/issues/108>)
	Index		Index
	A		A
	absolute-form (of request-target) 10		absolute-form (of request-target) 10
	application/http Media Type 38		application/http Media Type 39
	asterisk-form (of request-target) 11		asterisk-form (of request-target) 11
	authority-form (of request-target) 11		authority-form (of request-target) 11
	C		C
	Connection header field 27, 33		Connection header field 28, 33
	Content-Length header field 18		Content-Length header field 18
	Content-Transfer-Encoding header field 48		Content-Transfer-Encoding header field 49
	chunked (Coding Format) 17, 19		chunked (Coding Format) 17, 19
	chunked (transfer coding) 22		chunked (transfer coding) 22
	close 27, 33		close 28, 33
	compress (transfer coding) 24		compress (transfer coding) 25
	D		D
	deflate (transfer coding) 24		deflate (transfer coding) 25
	E		E
	effective request URI 12		effective request URI 12
	G		G
	Grammar		Grammar
	absolute-form 9-10		absolute-form 9-10
	ALPHA 5		ALPHA 5
	asterisk-form 9, 11		asterisk-form 9, 11
	authority-form 9, 11		authority-form 9, 11
	chunk 22		chunk 22
	chunk-data 22		chunk-data 22
	chunk-ext 22		chunk-ext 22-23
	chunk-ext-name 22		chunk-ext-name 23
	chunk-ext-val 22		chunk-ext-val 23
	chunk-size 22		chunk-size 22
	chunked-body 22		chunked-body 22-23
	Connection 28		Connection 29
	connection-option 28		connection-option 29
	CR 5		CR 5
	CRLF 5		CRLF 5
	CTL 5		CTL 5
	DIGIT 5		DIGIT 5
	DQUOTE 5		DQUOTE 5
	field-name 14		field-name 14
	field-value 14		field-value 14
	header-field 14, 23		header-field 14, 23
	HEXDIG 5		HEXDIG 5
	HTAB 5		HTAB 5
	HTTP-message 6		HTTP-message 6
	HTTP-name 6		HTTP-name 6
	HTTP-version 6		HTTP-version 6
	last-chunk 22		last-chunk 22
	LF 5		LF 5
	message-body 16		message-body 16
	method 9		method 9
	obs-fold 15		obs-fold 15
	OCTET 5		OCTET 5
	origin-form 9-10		origin-form 9-10
	rank 25		rank 26
	reason-phrase 14		reason-phrase 14
	request-line 8		request-line 8
	request-target 9		request-target 9
	SP 5		SP 5
	start-line 6		start-line 6
	status-code 14		status-code 14
	status-line 13		status-line 13
	t-codings 25		t-codings 26
	t-ranking 25		t-ranking 26
	TE 25		TE 26
	trailer-part 22-23		trailer-part 22-23
	transfer-coding 21		transfer-coding 21
	Transfer-Encoding 17		Transfer-Encoding 17
	transfer-extension 21		transfer-extension 21
	transfer-parameter 21		transfer-parameter 21
	Upgrade 34		Upgrade 35
	VCHAR 5		VCHAR 5
	gzip (transfer coding) 24		gzip (transfer coding) 25
	H		H
	header field 6		header field 6
	header section 6		header section 6
	headers 6		headers 6
	M		M
	MIME-Version header field 47		MIME-Version header field 48
	Media Type		Media Type
	application/http 38		application/http 39
	message/http 37		message/http 38
	message/http Media Type 37		message/http Media Type 38
	method 9		method 9
	O		O
	origin-form (of request-target) 10		origin-form (of request-target) 10
	R		R
	request-target 9		request-target 9
	T		T
	TE header field 25		TE header field 26
	Transfer-Encoding header field 17		Transfer-Encoding header field 17
	U		U
	Upgrade header field 34		Upgrade header field 34
	X		X
	x-compress (transfer coding) 24		x-compress (transfer coding) 25
	x-gzip (transfer coding) 24		x-gzip (transfer coding) 25
	Acknowledgments		Acknowledgments
	See Appendix "Acknowledgments" of [Semantics].		See Appendix "Acknowledgments" of [Semantics].
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe		Adobe
	345 Park Ave		345 Park Ave
End of changes. 49 change blocks.
	105 lines changed or deleted		168 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/