draft-ietf-httpbis-messaging-09.txt		draft-ietf-httpbis-messaging-10.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: January 12, 2021 J. Reschke, Ed.		Expires: January 13, 2021 J. F. Reschke, Ed.
	greenbytes		greenbytes
	July 11, 2020		July 12, 2020
	HTTP/1.1 Messaging		HTTP/1.1 Messaging
	draft-ietf-httpbis-messaging-09		draft-ietf-httpbis-messaging-10
	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.10.		The changes in this draft are summarized in Appendix D.11.
	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 January 12, 2021.		This Internet-Draft will expire on January 13, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 3, line 4 ¶		skipping to change at page 3, line 5 ¶
	2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6		2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7		2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7
	2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8		2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8
	3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10		3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10		3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
	3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11		3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
	3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12		3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12
	3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12		3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12
	3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13		3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13
	4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14		4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16		5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16
	5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16		5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 17
	6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17		6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18		6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18
	6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19		6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
	6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20		6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20
	7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22		7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 22
	7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23		7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23
	7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 24		7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 24
	7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 24		7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 25
	7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25		7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25
	7.2. Transfer Codings for Compression . . . . . . . . . . . . 26		7.2. Transfer Codings for Compression . . . . . . . . . . . . 26
	7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26		7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26
	7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28		8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28
	9. Connection Management . . . . . . . . . . . . . . . . . . . . 28		9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29		9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29
	9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30		9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
	9.3. Associating a Response to a Request . . . . . . . . . . . 31		9.3. Associating a Response to a Request . . . . . . . . . . . 31
	9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31		9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31
	9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32		9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32
	9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32		9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32
	9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33		9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33
	9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33		9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 34
	9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34		9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35		9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35
	9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36		9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36
	9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 38		9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 39
	9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 39		9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 39
	10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 40		10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 40
	10.1. Media Type message/http . . . . . . . . . . . . . . . . 40		10.1. Media Type message/http . . . . . . . . . . . . . . . . 40
	10.2. Media Type application/http . . . . . . . . . . . . . . 41		10.2. Media Type application/http . . . . . . . . . . . . . . 41
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 42		11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
	11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42		11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42
	11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43		11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43
	11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43		11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43
	11.4. Message Confidentiality . . . . . . . . . . . . . . . . 44		11.4. Message Confidentiality . . . . . . . . . . . . . . . . 44
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
	12.1. Field Name Registration . . . . . . . . . . . . . . . . 44		12.1. Field Name Registration . . . . . . . . . . . . . . . . 44
	12.2. Media Type Registration . . . . . . . . . . . . . . . . 44		12.2. Media Type Registration . . . . . . . . . . . . . . . . 44
	12.3. Transfer Coding Registration . . . . . . . . . . . . . . 45		12.3. Transfer Coding Registration . . . . . . . . . . . . . . 45
	12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 45		12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 45
	12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 45		12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 45
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
	13.1. Normative References . . . . . . . . . . . . . . . . . . 45		13.1. Normative References . . . . . . . . . . . . . . . . . . 45
	13.2. Informative References . . . . . . . . . . . . . . . . . 47		13.2. Informative References . . . . . . . . . . . . . . . . . 46
	Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 49		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 48
	Appendix B. Differences between HTTP and MIME . . . . . . . . . 50		Appendix B. Differences between HTTP and MIME . . . . . . . . . 50
	B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 51		B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 50
	B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 51		B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 50
	B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 51		B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 51
	B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 52		B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 51
	B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 52		B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 51
	B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 52		B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 51
	Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 52		Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 52
	C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 53		C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 52
	C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 53		C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 53
	C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 54		C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 53
	C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 54		C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 54
	C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 54		C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 54
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 55		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 54
	D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 55		D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 55
	D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 56		D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 55
	D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 56		D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 55
	D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 57		D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 56
	D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 57		D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 56
	D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 57		D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 56
	D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 57		D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 57
	D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 58		D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 57
	D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 58		D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 58
	D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 59		D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 58
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59		D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 58
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 61		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 58
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
	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 13, line 30 ¶		skipping to change at page 13, line 34 ¶
	follows:		follows:
	If the server's configuration (or outbound gateway) provides a		If the server's configuration (or outbound gateway) provides a
	fixed URI scheme, that scheme is used for the target URI.		fixed URI scheme, that scheme is used for the target URI.
	Otherwise, if the request is received over a TLS-secured TCP		Otherwise, if the request is received over a TLS-secured TCP
	connection, the target URI's scheme is "https"; if not, the scheme		connection, the target URI's scheme is "https"; if not, the scheme
	is "http".		is "http".
	If the server's configuration (or outbound gateway) provides a		If the server's configuration (or outbound gateway) provides a
	fixed URI authority component, that authority is used for the		fixed URI authority component, that authority is used for the
	target URI. If not, then if the request-target is in authority-		target URI. If not, then if the request-target is in
	form, the target URI's authority component is the same as the		authority-form, the target URI's authority component is the same
	request-target. If not, then if a Host header field is supplied		as the request-target. If not, then if a Host header field is
	with a non-empty field-value, the authority component is the same		supplied with a non-empty field-value, the authority component is
	as the Host field-value. Otherwise, the authority component is		the same as the Host field-value. Otherwise, the authority
	assigned the default name configured for the server and, if the		component is assigned the default name configured for the server
	connection's incoming TCP port number differs from the default		and, if the connection's incoming TCP port number differs from the
	port for the target URI's scheme, then a colon (":") and the		default port for the target URI's scheme, then a colon (":") and
	incoming port number (in decimal form) are appended to the		the incoming port number (in decimal form) are appended to the
	authority component.		authority component.
	If the request-target is in authority-form or asterisk-form, the		If the request-target is in authority-form or asterisk-form, the
	target URI's combined path and query component is empty.		target URI's combined path and query component is empty.
	Otherwise, the combined path and query component is the same as		Otherwise, the combined path and query component is the same as
	the request-target.		the request-target.
	The components of the target URI, once determined as above, can be		The components of the target URI, once determined as above, can be
	combined into absolute-URI form by concatenating the scheme,		combined into absolute-URI form by concatenating the scheme,
	"://", authority, and combined path and query component.		"://", authority, and combined path and query component.
	skipping to change at page 15, line 40 ¶		skipping to change at page 16, line 5 ¶
	field-line = field-name ":" OWS field-value OWS		field-line = field-name ":" OWS field-value OWS
	Most HTTP field names and the rules for parsing within field values		Most HTTP field names and the rules for parsing within field values
	are defined in Section 5 of [Semantics]. This section covers the		are defined in Section 5 of [Semantics]. This section covers 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:
	+-------------------+----------+---------------+		+-------------------+----------+--------------+
	| Field Name | Status | Reference |		| Field Name | Status | Reference |
	+-------------------+----------+---------------+		| Connection | standard | Section 9.1 |
	| Connection | standard | Section 9.1 |		| MIME-Version | standard | Appendix B.1 |
	| MIME-Version | standard | Appendix B.1 |		| TE | standard | Section 7.4 |
	| TE | standard | Section 7.4 |		| Transfer-Encoding | standard | Section 6.1 |
	| Transfer-Encoding | standard | Section 6.1 |		| Upgrade | standard | Section 9.9 |
	| Upgrade | standard | Section 9.9 |		+-------------------+----------+--------------+
	+-------------------+----------+---------------+
	Table 1		Table 1
	Furthermore, the field name "Close" is reserved, since using that		Furthermore, the field name "Close" is reserved, since using that
	name as an HTTP header field might conflict with the "close"		name as an HTTP header field might conflict with the "close"
	connection option of the Connection header field (Section 9.1).		connection option of the Connection header field (Section 9.1).
	+------------+----------+------------+-------------+		+------------+----------+-----------+------------+
	| Field Name | Status | Reference | Comments |		| Field Name | Status | Reference | Comments |
	+------------+----------+------------+-------------+		| Close | standard | Section 5 | (reserved) |
	| Close | standard | Section 5 | (reserved) |		+------------+----------+-----------+------------+
	+------------+----------+------------+-------------+
			Table 2
	5.1. Field Line Parsing		5.1. Field Line Parsing
	Messages are parsed using a generic algorithm, independent of the		Messages are parsed using a generic algorithm, independent of the
	individual field names. The contents within a given field line value		individual field names. The contents within a given field line value
	are not parsed until a later stage of message interpretation (usually		are not parsed until a later stage of message interpretation (usually
	after the message's entire header section has been processed).		after the message's entire header section has been processed).
	No whitespace is allowed between the field name and colon. In the		No whitespace is allowed between the field name and colon. In the
	past, differences in the handling of such whitespace have led to		past, differences in the handling of such whitespace have led to
	skipping to change at page 17, line 23 ¶		skipping to change at page 17, line 37 ¶
	A proxy or gateway that receives an obs-fold in a response message		A proxy or gateway that receives an obs-fold in a response message
	that is not within a message/http container MUST either discard the		that is not within a message/http container MUST either discard the
	message and replace it with a 502 (Bad Gateway) response, preferably		message and replace it with a 502 (Bad Gateway) response, preferably
	with a representation explaining that unacceptable line folding was		with a representation explaining that unacceptable line folding was
	received, or replace each received obs-fold with one or more SP		received, or replace each received obs-fold with one or more SP
	octets prior to interpreting the field value or forwarding the		octets prior to interpreting the field value or forwarding the
	message downstream.		message downstream.
	A user agent that receives an obs-fold in a response message that is		A user agent that receives an obs-fold in a response message that is
	not within a message/http container MUST replace each received obs-		not within a message/http container MUST replace each received
	fold with one or more SP octets prior to interpreting the field		obs-fold with one or more SP octets prior to interpreting the field
	value.		value.
	6. Message Body		6. Message Body
	The message body (if any) of an HTTP message is used to carry the		The message body (if any) of an HTTP message is used to carry the
	payload body (Section 7.3.3 of [Semantics]) of that request or		payload body (Section 7.3.3 of [Semantics]) of that request or
	response. The message body is identical to the payload body unless a		response. The message body is identical to the payload body unless a
	transfer coding has been applied, as described in Section 6.1.		transfer coding has been applied, as described in Section 6.1.
	message-body = *OCTET		message-body = *OCTET
	The rules for determining when a message body is present in an		The rules for determining when a message body is present in an
	HTTP/1.1 message differ for requests and responses.		HTTP/1.1 message differ for requests and responses.
	The presence of a message body in a request is signaled by a Content-		The presence of a message body in a request is signaled by a
	Length or Transfer-Encoding header field. Request message framing is		Content-Length or Transfer-Encoding header field. Request message
	independent of method semantics, even if the method does not define		framing is independent of method semantics, even if the method does
	any use for a message body.		not define any use for a message body.
	The presence of a message body in a response depends on both the		The presence of a message body in a response depends on both the
	request method to which it is responding and the response status code		request method to which it is responding and the response status code
	(Section 4), and corresponds to when a payload body is allowed; see		(Section 4), and corresponds to when a payload body is allowed; see
	Section 7.3.3 of [Semantics].		Section 7.3.3 of [Semantics].
	6.1. Transfer-Encoding		6.1. Transfer-Encoding
	The Transfer-Encoding header field lists the transfer coding names		The Transfer-Encoding header field lists the transfer coding names
	corresponding to the sequence of transfer codings that have been (or		corresponding to the sequence of transfer codings that have been (or
	skipping to change at page 19, line 44 ¶		skipping to change at page 20, line 5 ¶
	When a message does not have a Transfer-Encoding header field, a		When a message does not have a Transfer-Encoding header field, a
	Content-Length header field can provide the anticipated size, as a		Content-Length header field can provide the anticipated size, as a
	decimal number of octets, for a potential payload body. For messages		decimal number of octets, for a potential payload body. For messages
	that do include a payload body, the Content-Length field value		that do include a payload body, the Content-Length field value
	provides the framing information necessary for determining where the		provides the framing information necessary for determining where the
	body (and message) ends. For messages that do not include a payload		body (and message) ends. For messages that do not include a payload
	body, the Content-Length indicates the size of the selected		body, the Content-Length indicates the size of the selected
	representation (Section 7.2.4 of [Semantics]).		representation (Section 7.2.4 of [Semantics]).
	Note: HTTP's use of Content-Length for message framing differs		| *Note:* HTTP's use of Content-Length for message framing
	significantly from the same field's use in MIME, where it is an		| differs significantly from the same field's use in MIME, where
	optional field used only within the "message/external-body" media-		| it is an optional field used only within the "message/external-
	type.		| body" media-type.
	6.3. Message Body Length		6.3. Message Body Length
	The length of a message body is determined by one of the following		The length of a message body is determined by one of the following
	(in order of precedence):		(in order of precedence):
	1. Any response to a HEAD request and any response with a 1xx		1. Any response to a HEAD request and any response with a 1xx
	(Informational), 204 (No Content), or 304 (Not Modified) status		(Informational), 204 (No Content), or 304 (Not Modified) status
	code is always terminated by the first empty line after the		code is always terminated by the first empty line after the
	header fields, regardless of the header fields present in the		header fields, regardless of the header fields present in the
	skipping to change at page 22, line 31 ¶		skipping to change at page 22, line 37 ¶
	that is being transferred.		that is being transferred.
	transfer-coding = token *( OWS ";" OWS transfer-parameter )		transfer-coding = token *( OWS ";" OWS transfer-parameter )
	Parameters are in the form of a 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
	Encoding (Section 6.1) header fields.		Transfer-Encoding (Section 6.1) header fields.
	+------------+------------------------------------------+-----------+		+------------+-------------------------------+-----------+
	| Name | Description | Reference |		| Name | Description | Reference |
	+------------+------------------------------------------+-----------+		| chunked | Transfer in a series of | Section |
	| chunked | Transfer in a series of chunks | Section 7 |		| | chunks | 7.1 |
	| | | .1 |		| compress | UNIX "compress" data format | Section |
	| compress | UNIX "compress" data format [Welch] | Section 7 |		| | [Welch] | 7.2 |
	| | | .2 |		| deflate | "deflate" compressed data | Section |
	| deflate | "deflate" compressed data ([RFC1951]) | Section 7 |		| | ([RFC1951]) inside the "zlib" | 7.2 |
	| | inside the "zlib" data format | .2 |		| | data format ([RFC1950]) | |
	| | ([RFC1950]) | |		| gzip | GZIP file format [RFC1952] | Section |
	| gzip | GZIP file format [RFC1952] | Section 7 |		| | | 7.2 |
	| | | .2 |		| trailers | (reserved) | Section 7 |
	| trailers | (reserved) | Section 7 |		| x-compress | Deprecated (alias for | Section |
	| x-compress | Deprecated (alias for compress) | Section 7 |		| | compress) | 7.2 |
	| | | .2 |		| x-gzip | Deprecated (alias for gzip) | Section |
	| x-gzip | Deprecated (alias for gzip) | Section 7 |		| | | 7.2 |
	| | | .2 |		+------------+-------------------------------+-----------+
	+------------+------------------------------------------+-----------+
	Table 2		Table 3
	Note: the coding name "trailers" is reserved because its use would		| *Note:* the coding name "trailers" is reserved because its use
	conflict with the keyword "trailers" in the TE header field		| would conflict with the keyword "trailers" in the TE header
	(Section 7.4).		| 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 section containing trailer fields.		followed by an OPTIONAL trailer section containing trailer fields.
	Chunked enables content streams of unknown size to be transferred as		Chunked enables content streams of unknown size to be transferred as
	a sequence of length-delimited buffers, which enables the sender to		a 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 39, line 7 ¶		skipping to change at page 39, line 16 ¶
	(Section 10.4 of [Semantics]).		(Section 10.4 of [Semantics]).
	9.9.1. Upgrade Protocol Names		9.9.1. Upgrade Protocol Names
	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 4.2 of [Semantics] and future updates to		version rules of Section 4.2 of [Semantics] and future updates to
	this specification. Additional protocol names ought to be registered		this specification. Additional protocol names ought to be registered
	using the registration procedure defined in Section 9.9.2.		using the registration procedure defined in Section 9.9.2.
	+------+-------------------+--------------------+-------------------+		+------+-------------------+-----------------+----------------+
	| Name | Description | Expected Version | Reference |		| Name | Description | Expected | Reference |
	| | | Tokens | |		| | | Version Tokens | |
	+------+-------------------+--------------------+-------------------+		| HTTP | Hypertext | any DIGIT.DIGIT | Section 4.2 of |
	| HTTP | Hypertext | any DIGIT.DIGIT | Section 4.2 of |		| | Transfer Protocol | (e.g, "2.0") | [Semantics] |
	| | Transfer Protocol | (e.g, "2.0") | [Semantics] |		+------+-------------------+-----------------+----------------+
	+------+-------------------+--------------------+-------------------+
			Table 4
	9.9.2. Upgrade Token Registry		9.9.2. Upgrade Token Registry
	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
	skipping to change at page 40, line 26 ¶		skipping to change at page 40, line 37 ¶
	Subtype name: http		Subtype name: http
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: version, msgtype		Optional parameters: version, msgtype
	version: The HTTP-version number of the enclosed message (e.g.,		version: The HTTP-version number of the enclosed message (e.g.,
	"1.1"). If not present, the version can be determined from the		"1.1"). If not present, the version can be determined from the
	first line of the body.		first line of the body.
	msgtype: The message type -- "request" or "response". If not		msgtype: The message type - "request" or "response". If not
	present, the type can be determined from the first line of the		present, the type can be determined from the first line of the
	body.		body.
	Encoding considerations: only "7bit", "8bit", or "binary" are		Encoding considerations: only "7bit", "8bit", or "binary" are
	permitted		permitted
	Security considerations: see Section 11		Security considerations: see Section 11
	Interoperability considerations: N/A		Interoperability considerations: N/A
	Published specification: This specification (see Section 10.1).		Published specification: This specification (see Section 10.1).
	Applications that use this media type: N/A		Applications that use this media type: N/A
	Fragment identifier considerations: N/A		Fragment identifier considerations: N/A
			Additional information: Magic number(s): N/A
	Additional information:		Deprecated alias names for this type: N/A
	Magic number(s): N/A
	Deprecated alias names for this type: N/A		File extension(s): N/A
	File extension(s): N/A		Macintosh file type code(s): N/A
	Macintosh file type code(s): N/A
	Person and email address to contact for further information:		Person and email address to contact for further information: See Aut
	See Authors' Addresses section.		hors' Addresses section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: N/A		Restrictions on usage: N/A
	Author: See Authors' Addresses section.		Author: See Authors' Addresses section.
	Change controller: IESG		Change controller: IESG
	10.2. Media Type application/http		10.2. Media Type application/http
	skipping to change at page 41, line 34 ¶		skipping to change at page 41, line 40 ¶
	Subtype name: http		Subtype name: http
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: version, msgtype		Optional parameters: version, msgtype
	version: The HTTP-version number of the enclosed messages (e.g.,		version: The HTTP-version number of the enclosed messages (e.g.,
	"1.1"). If not present, the version can be determined from the		"1.1"). If not present, the version can be determined from the
	first line of the body.		first line of the body.
	msgtype: The message type -- "request" or "response". If not		msgtype: The message type - "request" or "response". If not
	present, the type can be determined from the first line of the		present, the type can be determined from the first line of the
	body.		body.
	Encoding considerations: HTTP messages enclosed by this type are in		Encoding considerations: HTTP messages enclosed by this type are in
	"binary" format; use of an appropriate Content-Transfer-Encoding		"binary" format; use of an appropriate Content-Transfer-Encoding
	is required when transmitted via email.		is required when transmitted via email.
	Security considerations: see Section 11		Security considerations: see Section 11
	Interoperability considerations: N/A		Interoperability considerations: N/A
	skipping to change at page 41, line 45 ¶		skipping to change at page 42, line 4 ¶
	present, the type can be determined from the first line of the		present, the type can be determined from the first line of the
	body.		body.
	Encoding considerations: HTTP messages enclosed by this type are in		Encoding considerations: HTTP messages enclosed by this type are in
	"binary" format; use of an appropriate Content-Transfer-Encoding		"binary" format; use of an appropriate Content-Transfer-Encoding
	is required when transmitted via email.		is required when transmitted via email.
	Security considerations: see Section 11		Security considerations: see Section 11
	Interoperability considerations: N/A		Interoperability considerations: N/A
	Published specification: This specification (see Section 10.2).		Published specification: This specification (see Section 10.2).
	Applications that use this media type: N/A		Applications that use this media type: N/A
	Fragment identifier considerations: N/A
	Additional information:		Fragment identifier considerations: N/A
	Deprecated alias names for this type: N/A		Additional information: Deprecated alias names for this type: N/A
	Magic number(s): N/A		Magic number(s): N/A
	File extension(s): N/A		File extension(s): N/A
	Macintosh file type code(s): N/A		Macintosh file type code(s): N/A
	Person and email address to contact for further information:		Person and email address to contact for further information: See Aut
	See Authors' Addresses section.		hors' Addresses section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: N/A		Restrictions on usage: N/A
	Author: See Authors' Addresses section.		Author: See Authors' Addresses section.
	Change controller: IESG		Change controller: IESG
	11. Security Considerations		11. Security Considerations
	skipping to change at page 45, line 26 ¶		skipping to change at page 45, line 26 ¶
	with the registration procedure of Section 9.9.2 and the upgrade		with the registration procedure of Section 9.9.2 and the upgrade
	token names summarized in the table of Section 9.9.1.		token names summarized in the table of Section 9.9.1.
	12.5. ALPN Protocol ID Registration		12.5. ALPN Protocol ID Registration
	Please update the "TLS Application-Layer Protocol Negotiation (ALPN)		Please update the "TLS Application-Layer Protocol Negotiation (ALPN)
	Protocol IDs" registry at <https://www.iana.org/assignments/tls-		Protocol IDs" registry at <https://www.iana.org/assignments/tls-
	extensiontype-values/tls-extensiontype-values.xhtml> with the		extensiontype-values/tls-extensiontype-values.xhtml> with the
	registration below:		registration below:
	+----------+--------------------------------------+-----------------+		+----------+-----------------------------+----------------+
	| Protocol | Identification Sequence | Reference |		| Protocol | Identification Sequence | Reference |
	+----------+--------------------------------------+-----------------+		| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | (this |
	| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e | (this |		| | 0x31 0x2e 0x31 ("http/1.1") | specification) |
	| | 0x31 ("http/1.1") | specification) |		+----------+-----------------------------+----------------+
	+----------+--------------------------------------+-----------------+
			Table 5
	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. F. Reschke,
	Ed., "HTTP Caching", draft-ietf-httpbis-cache-09 (work in		Ed., "HTTP Caching", Work in Progress, Internet-Draft,
	progress), July 2020.		draft-ietf-httpbis-cache-10, July 12, 2020,
			<https://tools.ietf.org/html/draft-ietf-httpbis-cache-10>.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
	Specification version 3.3", RFC 1950,		Format 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>.
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G.		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P., and
	Randers-Pehrson, "GZIP file format specification version		G. Randers-Pehrson, "GZIP file format specification
	4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,		version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,
	<https://www.rfc-editor.org/info/rfc1952>.		<https://www.rfc-editor.org/info/rfc1952>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	skipping to change at page 46, line 38 ¶		skipping to change at page 46, line 38 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[Semantics]		[Semantics]
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
	Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-09		Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
	(work in progress), July 2020.		draft-ietf-httpbis-semantics-10, July 12, 2020,
			<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
			10>.
	[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., "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,		[Err4667] RFC Errata, Erratum ID 4667, RFC 7230,
	<https://www.rfc-editor.org/errata/eid4667>.		<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.T., and H.F. Nielsen,
	Transfer Protocol -- HTTP/1.0", RFC 1945,		"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
	DOI 10.17487/RFC1945, May 1996,		DOI 10.17487/RFC1945, May 1996,
	<https://www.rfc-editor.org/info/rfc1945>.		<https://www.rfc-editor.org/info/rfc1945>.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,		Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
	<https://www.rfc-editor.org/info/rfc2045>.		<https://www.rfc-editor.org/info/rfc2045>.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	DOI 10.17487/RFC2046, November 1996,		DOI 10.17487/RFC2046, November 1996,
	<https://www.rfc-editor.org/info/rfc2046>.		<https://www.rfc-editor.org/info/rfc2046>.
	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2049] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Five: Conformance Criteria and		Extensions (MIME) Part Five: Conformance Criteria and
	Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,		Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
	<https://www.rfc-editor.org/info/rfc2049>.		<https://www.rfc-editor.org/info/rfc2049>.
	[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>.
	[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>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
	Protocol (HTTP/1.1): Message Syntax and Routing",		Transfer 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. F. Reschke, Ed., "Hypertext
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Transfer Protocol (HTTP/1.1): Semantics and Content",
	DOI 10.17487/RFC7231, June 2014,		RFC 7231, 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		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<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
	skipping to change at page 59, line 16 ¶		skipping to change at page 58, line 33 ¶
	o In Section 2.2, disallow bare CRs (<https://github.com/httpwg/		o In Section 2.2, disallow bare CRs (<https://github.com/httpwg/
	http-core/issues/31>)		http-core/issues/31>)
	o Appendix A now uses the sender variant of the "#" list expansion		o Appendix A now uses the sender variant of the "#" list expansion
	(<https://github.com/httpwg/http-core/issues/192>)		(<https://github.com/httpwg/http-core/issues/192>)
	o In Section 5, adjust IANA "Close" entry for new registry format		o In Section 5, adjust IANA "Close" entry for new registry format
	(<https://github.com/httpwg/http-core/issues/273>)		(<https://github.com/httpwg/http-core/issues/273>)
	Index		D.11. Since draft-ietf-httpbis-messaging-09
	A
	absolute-form (of request-target) 11
	application/http Media Type 41
	asterisk-form (of request-target) 12
	authority-form (of request-target) 12
	C
	Connection header field 29, 34
	Content-Length header field 19
	Content-Transfer-Encoding header field 52
	chunked (Coding Format) 18, 20
	chunked (transfer coding) 23
	close 29, 34
	compress (transfer coding) 26
	D
	deflate (transfer coding) 26
	F
	Fields
	Connection 29
	MIME-Version 51
	TE 27
	Transfer-Encoding 18
	Upgrade 36
	G
	Grammar
	absolute-form 10-11
	ALPHA 5
	asterisk-form 10, 12
	authority-form 10, 12
	chunk 23
	chunk-data 23
	chunk-ext 23-24
	chunk-ext-name 24
	chunk-ext-val 24
	chunk-size 23
	chunked-body 23
	Connection 30
	connection-option 30
	CR 5
	CRLF 5
	CTL 5
	DIGIT 5
	DQUOTE 5
	field-line 15, 25
	field-name 15
	field-value 15
	HEXDIG 5
	HTAB 5
	HTTP-message 6
	HTTP-name 8
	HTTP-version 8
	last-chunk 23
	LF 5
	message-body 17
	method 10
	obs-fold 16
	OCTET 5
	origin-form 10
	rank 27
	reason-phrase 15
	request-line 9
	request-target 10
	SP 5
	start-line 6
	status-code 15
	status-line 14
	t-codings 27
	t-ranking 27
	TE 27
	trailer-section 23, 25
	transfer-coding 22
	Transfer-Encoding 18
	transfer-parameter 22
	Upgrade 37
	VCHAR 5
	gzip (transfer coding) 26
	H
	Header Fields
	Connection 29
	MIME-Version 51
	TE 27
	Transfer-Encoding 18
	Upgrade 36
	header line 6
	header section 6
	headers 6
	M
	MIME-Version header field 51
	Media Type
	application/http 41
	message/http 40
	message/http Media Type 40
	method 10
	O
	origin-form (of request-target) 10
	R
	request-target 10
	T
	TE header field 27
	Transfer-Encoding header field 18
	U
	Upgrade header field 36
	X		o Switch to xml2rfc v3 mode for draft generation
	x-compress (transfer coding) 26		(<https://github.com/httpwg/http-core/issues/394>)
	x-gzip (transfer coding) 26
	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
	San Jose, CA 95110		San Jose, CA 95110
	United States of America		United States of America
	EMail: fielding@gbiv.com		Email: fielding@gbiv.com
	URI: https://roy.gbiv.com/		URI: https://roy.gbiv.com/
	Mark Nottingham (editor)		Mark Nottingham (editor)
	Fastly		Fastly
	EMail: mnot@mnot.net		Email: mnot@mnot.net
	URI: https://www.mnot.net/		URI: https://www.mnot.net/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster 48155		48155 Münster
	Germany		Germany
	EMail: julian.reschke@greenbytes.de		Email: julian.reschke@greenbytes.de
	URI: https://greenbytes.de/tech/webdav/		URI: https://greenbytes.de/tech/webdav/
End of changes. 65 change blocks.
	270 lines changed or deleted		155 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/