draft-ietf-httpbis-messaging-10.txt		draft-ietf-httpbis-messaging-11.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 13, 2021 J. F. Reschke, Ed.		Expires: February 28, 2021 J. F. Reschke, Ed.
	greenbytes		greenbytes
	July 12, 2020		August 27, 2020
	HTTP/1.1 Messaging		HTTP/1.1 Messaging
	draft-ietf-httpbis-messaging-10		draft-ietf-httpbis-messaging-11
	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.11.		The changes in this draft are summarized in Appendix D.12.
	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 13, 2021.		This Internet-Draft will expire on February 28, 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 50 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
	2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . . . 11
	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 . . . . . . . . . . . . . . . . . . 17		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 . . . . . . . . . . . . . . . 25		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. Negotiating Transfer Codings . . . . . . . . . . . . . . 27
	8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28		8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
	9. Connection Management . . . . . . . . . . . . . . . . . . . . 28		9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29		9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 28
	9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30		9.2. Associating a Response to a Request . . . . . . . . . . . 29
	9.3. Associating a Response to a Request . . . . . . . . . . . 31		9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 29
	9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31		9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 30
	9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32		9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 30
	9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32		9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 31
	9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33		9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
	9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 34		9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34		9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 34
	9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35		9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 34
	9.9. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 36		10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 35
	9.9.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 39		10.1. Media Type message/http . . . . . . . . . . . . . . . . 35
	9.9.2. Upgrade Token Registry . . . . . . . . . . . . . . . 39		10.2. Media Type application/http . . . . . . . . . . . . . . 36
	10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 40		11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	10.1. Media Type message/http . . . . . . . . . . . . . . . . 40		11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 37
	10.2. Media Type application/http . . . . . . . . . . . . . . 41		11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 38
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 42		11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 38
	11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 42		11.4. Message Confidentiality . . . . . . . . . . . . . . . . 39
	11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 43		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 43		12.1. Field Name Registration . . . . . . . . . . . . . . . . 39
	11.4. Message Confidentiality . . . . . . . . . . . . . . . . 44		12.2. Media Type Registration . . . . . . . . . . . . . . . . 39
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44		12.3. Transfer Coding Registration . . . . . . . . . . . . . . 40
	12.1. Field Name Registration . . . . . . . . . . . . . . . . 44		12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 40
	12.2. Media Type Registration . . . . . . . . . . . . . . . . 44		12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 40
	12.3. Transfer Coding Registration . . . . . . . . . . . . . . 45		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 45		13.1. Normative References . . . . . . . . . . . . . . . . . . 40
	12.5. ALPN Protocol ID Registration . . . . . . . . . . . . . 45		13.2. Informative References . . . . . . . . . . . . . . . . . 41
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 43
	13.1. Normative References . . . . . . . . . . . . . . . . . . 45		Appendix B. Differences between HTTP and MIME . . . . . . . . . 44
	13.2. Informative References . . . . . . . . . . . . . . . . . 46		B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 45
	Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 48		B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 45
	Appendix B. Differences between HTTP and MIME . . . . . . . . . 50		B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 45
	B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 50		B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 46
	B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 50		B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 46
	B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 51		B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 46
	B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 51		Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 46
	B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 51		C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 47
	B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 51		C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 47
	Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 52		C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 48
	C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 52		C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 48
	C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 53		C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 49
	C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 53		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 49
	C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 54		D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 49
	C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 54		D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 50
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 54		D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 50
	D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 55		D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 51
	D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 55		D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 51
	D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 55		D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 51
	D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 56		D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 52
	D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 56		D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 52
	D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 56		D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 52
	D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 57		D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 53
	D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 57		D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 53
	D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 58		D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 53
	D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 58		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 53
	D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 58		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 58
	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 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line		HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line
	feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any		feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any
	visible [USASCII] character).		visible [USASCII] character).
	The rules below are defined in [Semantics]:		The rules below are defined in [Semantics]:
	BWS = <BWS, see [Semantics], Section 1.2.1>		BWS = <BWS, see [Semantics], Section 1.6.1>
	OWS = <OWS, see [Semantics], Section 1.2.1>		OWS = <OWS, see [Semantics], Section 1.6.1>
	RWS = <RWS, see [Semantics], Section 1.2.1>		RWS = <RWS, see [Semantics], Section 1.6.1>
	absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>		absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
	absolute-path = <absolute-path, see [Semantics], Section 2.4>		absolute-path = <absolute-path, see [Semantics], Section 2.4>
	authority = <authority, see [RFC3986], Section 3.2>		authority = <authority, see [RFC3986], Section 3.2>
	comment = <comment, see [Semantics], Section 5.4.1.3>		comment = <comment, see [Semantics], Section 5.4.1.3>
	field-name = <field-name, see [Semantics], Section 5.3>		field-name = <field-name, see [Semantics], Section 5.3>
	field-value = <field-value, see [Semantics], Section 5.4>		field-value = <field-value, see [Semantics], Section 5.4>
	obs-text = <obs-text, see [Semantics], Section 5.4.1.2>		obs-text = <obs-text, see [Semantics], Section 5.4.1.2>
	port = <port, see [RFC3986], Section 3.2.3>		port = <port, see [RFC3986], Section 3.2.3>
	query = <query, see [RFC3986], Section 3.4>		query = <query, see [RFC3986], Section 3.4>
	quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2>		quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2>
	skipping to change at page 10, line 41 ¶		skipping to change at page 10, line 41 ¶
	hypertext references, resulting in those disallowed characters being		hypertext references, resulting in those disallowed characters being
	sent as the request-target in a malformed request-line.		sent as the request-target in a malformed request-line.
	Recipients of an invalid request-line SHOULD respond with either a		Recipients of an invalid request-line SHOULD respond with either a
	400 (Bad Request) error or a 301 (Moved Permanently) redirect with		400 (Bad Request) error or a 301 (Moved Permanently) redirect with
	the request-target properly encoded. A recipient SHOULD NOT attempt		the request-target properly encoded. A recipient SHOULD NOT attempt
	to autocorrect and then process the request without a redirect, since		to autocorrect and then process the request without a redirect, since
	the invalid request-line might be deliberately crafted to bypass		the invalid request-line might be deliberately crafted to bypass
	security filters along the request chain.		security filters along the request chain.
			A client MUST send a Host header field in all HTTP/1.1 request
			messages. If the target URI includes an authority component, then a
			client MUST send a field value for Host that is identical to that
			authority component, excluding any userinfo subcomponent and its "@"
			delimiter (Section 2.5.1 of [Semantics]). If the authority component
			is missing or undefined for the target URI, then a client MUST send a
			Host header field with an empty field value.
			A server MUST respond with a 400 (Bad Request) status code to any
			HTTP/1.1 request message that lacks a Host header field and to any
			request message that contains more than one Host header field or a
			Host header field with an invalid field value.
	3.2.1. origin-form		3.2.1. origin-form
	The most common form of request-target is the origin-form.		The most common form of request-target is the origin-form.
	origin-form = absolute-path [ "?" query ]		origin-form = absolute-path [ "?" query ]
	When making a request directly to an origin server, other than a		When making a request directly to an origin server, other than a
	CONNECT or server-wide OPTIONS request (as detailed below), a client		CONNECT or server-wide OPTIONS request (as detailed below), a client
	MUST send only the absolute path and query components of the target		MUST send only the absolute path and query components of the target
	URI as the request-target. If the target URI's path component is		URI as the request-target. If the target URI's path component is
	empty, the client MUST send "/" as the path within the origin-form of		empty, the client MUST send "/" as the path within the origin-form of
	request-target. A Host header field is also sent, as defined in		request-target. A Host header field is also sent, as defined in
	Section 6.6 of [Semantics].		Section 6.5 of [Semantics].
	For example, a client wishing to retrieve a representation of the		For example, a client wishing to retrieve a representation of the
	resource identified as		resource identified as
	http://www.example.org/where?q=now		http://www.example.org/where?q=now
	directly from the origin server would open (or reuse) a TCP		directly from the origin server would open (or reuse) a TCP
	connection to port 80 of the host "www.example.org" and send the		connection to port 80 of the host "www.example.org" and send the
	lines:		lines:
	skipping to change at page 11, line 39 ¶		skipping to change at page 11, line 45 ¶
	When making a request to a proxy, other than a CONNECT or server-wide		When making a request to a proxy, other than a CONNECT or server-wide
	OPTIONS request (as detailed below), a client MUST send the target		OPTIONS request (as detailed below), a client MUST send the target
	URI in absolute-form as the request-target.		URI in absolute-form as the request-target.
	absolute-form = absolute-URI		absolute-form = absolute-URI
	The proxy is requested to either service that request from a valid		The proxy is requested to either service that request from a valid
	cache, if possible, or make the same request on the client's behalf		cache, if possible, or make the same request on the client's behalf
	to either the next inbound proxy server or directly to the origin		to either the next inbound proxy server or directly to the origin
	server indicated by the request-target. Requirements on such		server indicated by the request-target. Requirements on such
	"forwarding" of messages are defined in Section 6.7 of [Semantics].		"forwarding" of messages are defined in Section 6.6 of [Semantics].
	An example absolute-form of request-line would be:		An example absolute-form of request-line would be:
	GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1		GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
	A client MUST send a Host header field in an HTTP/1.1 request even if		A client MUST send a Host header field in an HTTP/1.1 request even if
	the request-target is in the absolute-form, since this allows the		the request-target is in the absolute-form, since this allows the
	Host information to be forwarded through ancient HTTP/1.0 proxies		Host information to be forwarded through ancient HTTP/1.0 proxies
	that might not have implemented Host.		that might not have implemented Host.
	skipping to change at page 13, line 26 ¶		skipping to change at page 13, line 33 ¶
	3.3. Reconstructing the Target URI		3.3. Reconstructing the Target URI
	Since the request-target often contains only part of the user agent's		Since the request-target often contains only part of the user agent's
	target URI, a server constructs its value to properly service the		target URI, a server constructs its value to properly service the
	request (Section 6.1 of [Semantics]).		request (Section 6.1 of [Semantics]).
	If the request-target is in absolute-form, the target URI is the same		If the request-target is in absolute-form, the target URI is the same
	as the request-target. Otherwise, the target URI is constructed as		as the request-target. Otherwise, the target URI is constructed as
	follows:		follows:
	If the server's configuration (or outbound gateway) provides a		o 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 secured connection,
	connection, the target URI's scheme is "https"; if not, the scheme		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		o 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		target URI. If not, then if the request-target is in
	authority-form, the target URI's authority component is the same		authority-form, the target URI's authority component is the same
	as the request-target. If not, then if a Host header field is		as the request-target. If not, then if a Host header field is
	supplied with a non-empty field-value, the authority component is		supplied with a non-empty field-value, the authority component is
	the same as the Host field-value. Otherwise, the authority		the same as the Host field-value. Otherwise, the authority
	component is assigned the default name configured for the server		component is assigned the default name configured for the server
	and, if the connection's incoming TCP port number differs from the		and, if the connection's incoming TCP port number differs from the
	default port for the target URI's scheme, then a colon (":") and		default port for the target URI's scheme, then a colon (":") and
	the 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		o 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		o 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.
	Example 1: the following message received over an insecure TCP		Example 1: the following message received over an insecure TCP
	connection		connection
	GET /pub/WWW/TheProject.html HTTP/1.1		GET /pub/WWW/TheProject.html HTTP/1.1
	Host: www.example.org:8080		Host: www.example.org:8080
	has a target URI of		has a target URI of
	http://www.example.org:8080/pub/WWW/TheProject.html		http://www.example.org:8080/pub/WWW/TheProject.html
	Example 2: the following message received over a TLS-secured TCP		Example 2: the following message received over a secured connection
	connection
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	Host: www.example.org		Host: www.example.org
	has a target URI of		has a target URI of
	https://www.example.org		https://www.example.org
	Recipients of an HTTP/1.0 request that lacks a Host header field		Recipients of an HTTP/1.0 request that lacks a Host header field
	might need to use heuristics (e.g., examination of the URI path for		might need to use heuristics (e.g., examination of the URI path for
	skipping to change at page 16, line 5 ¶		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 Ref.
	| Connection | standard | Section 9.1 |		------------------- ---------- ------
	| MIME-Version | standard | Appendix B.1 |		MIME-Version standard B.1
	| TE | standard | Section 7.4 |		Transfer-Encoding standard 6.1
	| Transfer-Encoding | standard | Section 6.1 |		------------------- ---------- ------
	| 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 6.8 of
			[Semantics]).
	+------------+----------+-----------+------------+		------------ ---------- ----------- ------------
	| Field Name | Status | Reference | Comments |		Field Name Status Reference Comments
	| Close | standard | Section 5 | (reserved) |		------------ ---------- ----------- ------------
	+------------+----------+-----------+------------+		Close standard Section 5 (reserved)
			------------ ---------- ----------- ------------
	Table 2		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).
	skipping to change at page 18, line 22 ¶		skipping to change at page 18, line 22 ¶
	(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
	will be) applied to the payload body in order to form the message		will be) applied to the payload body in order to form the message
	body. Transfer codings are defined in Section 7.		body. Transfer codings are defined in Section 7.
	Transfer-Encoding = 1#transfer-coding		Transfer-Encoding = #transfer-coding
	Transfer-Encoding is analogous to the Content-Transfer-Encoding field		Transfer-Encoding is analogous to the Content-Transfer-Encoding field
	of MIME, which was designed to enable safe transport of binary data		of MIME, which was designed to enable safe transport of binary data
	over a 7-bit transport service ([RFC2045], Section 6). However, safe		over a 7-bit transport service ([RFC2045], Section 6). However, safe
	transport has a different focus for an 8bit-clean transfer protocol.		transport has a different focus for an 8bit-clean transfer protocol.
	In HTTP's case, Transfer-Encoding is primarily intended to accurately		In HTTP's case, Transfer-Encoding is primarily intended to accurately
	delimit a dynamically generated payload and to distinguish payload		delimit a dynamically generated payload and to distinguish payload
	encodings that are only applied for transport efficiency or security		encodings that are only applied for transport efficiency or security
	from those that are characteristics of the selected resource.		from those that are characteristics of the selected resource.
	skipping to change at page 21, line 31 ¶		skipping to change at page 21, line 31 ¶
	6. If this is a request message and none of the above are true, then		6. If this is a request message and none of the above are true, then
	the message body length is zero (no message body is present).		the message body length is zero (no message body is present).
	7. Otherwise, this is a response message without a declared message		7. Otherwise, this is a response message without a declared message
	body length, so the message body length is determined by the		body length, so the message body length is determined by the
	number of octets received prior to the server closing the		number of octets received prior to the server closing the
	connection.		connection.
	Since there is no way to distinguish a successfully completed, close-		Since there is no way to distinguish a successfully completed, close-
	delimited message from a partially received message interrupted by		delimited response message from a partially received message
	network failure, a server SHOULD generate encoding or length-		interrupted by network failure, a server SHOULD generate encoding or
	delimited messages whenever possible. The close-delimiting feature		length-delimited messages whenever possible. The close-delimiting
	exists primarily for backwards compatibility with HTTP/1.0.		feature exists primarily for backwards compatibility with HTTP/1.0.
			| *Note:* Request messages are never close-delimited because they
			| are always explicitly framed by length or transfer coding, with
			| the absence of both implying the request ends immediately after
			| the header section.
	A server MAY reject a request that contains a message body but not a		A server MAY reject a request that contains a message body but not a
	Content-Length by responding with 411 (Length Required).		Content-Length by responding with 411 (Length Required).
	Unless a transfer coding other than chunked has been applied, a		Unless a transfer coding other than chunked has been applied, a
	client that sends a request containing a message body SHOULD use a		client that sends a request containing a message body SHOULD use a
	valid Content-Length header field if the message body length is known		valid Content-Length header field if the message body length is known
	in advance, rather than the chunked transfer coding, since some		in advance, rather than the chunked transfer coding, since some
	existing services respond to chunked with a 411 (Length Required)		existing services respond to chunked with a 411 (Length Required)
	status code even though they understand the chunked transfer coding.		status code even though they understand the chunked transfer coding.
	skipping to change at page 22, line 37 ¶		skipping to change at page 22, line 48 ¶
	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		Section 7.3. They are used in the TE (Section 5.6.5 of [Semantics])
	Transfer-Encoding (Section 6.1) header fields.		and Transfer-Encoding (Section 6.1) header fields.
	+------------+-------------------------------+-----------+		------------ ------------------------------- -----------
	| Name | Description | Reference |		Name Description Reference
	| chunked | Transfer in a series of | Section |		------------ ------------------------------- -----------
	| | chunks | 7.1 |		chunked Transfer in a series of Section
	| compress | UNIX "compress" data format | Section |		chunks 7.1
	| | [Welch] | 7.2 |		compress UNIX "compress" data format Section
	| deflate | "deflate" compressed data | Section |		[Welch] 7.2
	| | ([RFC1951]) inside the "zlib" | 7.2 |		deflate "deflate" compressed data Section
	| | data format ([RFC1950]) | |		([RFC1951]) inside the "zlib" 7.2
	| gzip | GZIP file format [RFC1952] | Section |		data format ([RFC1950])
	| | | 7.2 |		gzip GZIP file format [RFC1952] Section
	| trailers | (reserved) | Section 7 |		7.2
	| x-compress | Deprecated (alias for | Section |		trailers (reserved) Section 7
	| | compress) | 7.2 |		x-compress Deprecated (alias for Section
	| x-gzip | Deprecated (alias for gzip) | Section |		compress) 7.2
	| | | 7.2 |		x-gzip Deprecated (alias for gzip) Section
	+------------+-------------------------------+-----------+		7.2
			------------ ------------------------------- -----------
	Table 3		Table 3
	| *Note:* the coding name "trailers" is reserved because its use		| *Note:* the coding name "trailers" is reserved because its use
	| would conflict with the keyword "trailers" in the TE header		| would conflict with the keyword "trailers" in the TE header
	| field (Section 7.4).		| field (Section 5.6.5 of [Semantics]).
	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 26, line 41 ¶		skipping to change at page 26, line 41 ¶
	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 7.1.2 of [Semantics]) unless the encoding		codings (Section 7.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"		The TE header field (Section 5.6.5 of [Semantics]) uses a pseudo
	as rank value when multiple transfer codings are acceptable. Future		parameter named "q" as rank value when multiple transfer codings are
	registrations of transfer codings SHOULD NOT define parameters called		acceptable. Future registrations of transfer codings SHOULD NOT
	"q" (case-insensitively) in order to avoid ambiguities.		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.8 of [RFC8126]), 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. Negotiating Transfer Codings
	The "TE" header field in a request indicates what transfer codings,
	besides chunked, the client is willing to accept in response, and
	whether or not the client is willing to accept trailer fields in a
	chunked transfer coding.
	The TE field-value consists of a list of transfer coding names, each		The TE field (Section 5.6.5 of [Semantics]) is used in HTTP/1.1 to
	allowing for optional parameters (as described in Section 7), and/or		indicate what transfer-codings, besides chunked, the client is
	the keyword "trailers". A client MUST NOT send the chunked transfer		willing to accept in the response, and whether or not the client is
	coding name in TE; chunked is always acceptable for HTTP/1.1		willing to accept trailer fields in a chunked transfer coding.
	recipients.
	TE = #t-codings		A client MUST NOT send the chunked transfer coding name in TE;
	t-codings = "trailers" / ( transfer-coding [ t-ranking ] )		chunked is always acceptable for HTTP/1.1 recipients.
	t-ranking = OWS ";" OWS "q=" rank
	rank = ( "0" [ "." 0*3DIGIT ] )
	/ ( "1" [ "." 0*3("0") ] )
	Three examples of TE use are below.		Three examples of TE use are below.
	TE: deflate		TE: deflate
	TE:		TE:
	TE: trailers, deflate;q=0.5		TE: trailers, deflate;q=0.5
	When multiple transfer codings are acceptable, the client MAY rank		When multiple transfer codings are acceptable, the client MAY rank
	the codings by preference using a case-insensitive "q" parameter		the codings by preference using a case-insensitive "q" parameter
	(similar to the qvalues used in content negotiation fields,		(similar to the qvalues used in content negotiation fields,
	skipping to change at page 27, line 46 ¶		skipping to change at page 27, line 37 ¶
	If the TE field value is empty or if no TE field is present, the only		If the TE field value is empty or if no TE field is present, the only
	acceptable transfer coding is chunked. A message with no transfer		acceptable transfer coding is chunked. A message with no transfer
	coding is always acceptable.		coding is always acceptable.
	The keyword "trailers" indicates that the sender will not discard		The keyword "trailers" indicates that the sender will not discard
	trailer fields, as described in Section 5.6 of [Semantics].		trailer fields, as described in Section 5.6 of [Semantics].
	Since the TE header field only applies to the immediate connection, a		Since the TE header field only applies to the immediate connection, a
	sender of TE MUST also send a "TE" connection option within the		sender of TE MUST also send a "TE" connection option within the
	Connection header field (Section 9.1) in order to prevent the TE		Connection header field (Section 6.8 of [Semantics]) in order to
	field from being forwarded by intermediaries that do not support its		prevent the TE field from being forwarded by intermediaries that do
	semantics.		not support its semantics.
	8. Handling Incomplete Messages		8. Handling Incomplete Messages
	A server that receives an incomplete request message, usually due to		A server that receives an incomplete request message, usually due to
	a canceled request or a triggered timeout exception, MAY send an		a canceled request or a triggered timeout exception, MAY send an
	error response prior to closing the connection.		error response prior to closing the connection.
	A client that receives an incomplete response message, which can		A client that receives an incomplete response message, which can
	occur when a connection is closed prematurely or when decoding a		occur when a connection is closed prematurely or when decoding a
	supposedly chunked transfer coding fails, MUST record the message as		supposedly chunked transfer coding fails, MUST record the message as
	skipping to change at page 29, line 11 ¶		skipping to change at page 28, line 48 ¶
	HTTP implementations are expected to engage in connection management,		HTTP implementations are expected to engage in connection management,
	which includes maintaining the state of current connections,		which includes maintaining the state of current connections,
	establishing a new connection or reusing an existing connection,		establishing a new connection or reusing an existing connection,
	processing messages received on a connection, detecting connection		processing messages received on a connection, detecting connection
	failures, and closing each connection. Most clients maintain		failures, and closing each connection. Most clients maintain
	multiple connections in parallel, including more than one connection		multiple connections in parallel, including more than one connection
	per server endpoint. Most servers are designed to maintain thousands		per server endpoint. Most servers are designed to maintain thousands
	of concurrent connections, while controlling request queues to enable		of concurrent connections, while controlling request queues to enable
	fair use and detect denial-of-service attacks.		fair use and detect denial-of-service attacks.
	9.1. Connection		9.1. Establishment
	The "Connection" header field allows the sender to list desired
	control options for the current connection.
	When a field aside from Connection is used to supply control
	information for or about the current connection, the sender MUST list
	the corresponding field name within the Connection header field.
	Intermediaries MUST parse a received Connection header field before a
	message is forwarded and, for each connection-option in this field,
	remove any header or trailer field(s) from the message with the same
	name as the connection-option, and then remove the Connection header
	field itself (or replace it with the intermediary's own connection
	options for the forwarded message).
	Hence, the Connection header field provides a declarative way of
	distinguishing fields that are only intended for the immediate
	recipient ("hop-by-hop") from those fields that are intended for all
	recipients on the chain ("end-to-end"), enabling the message to be
	self-descriptive and allowing future connection-specific extensions
	to be deployed without fear that they will be blindly forwarded by
	older intermediaries.
	Furthermore, intermediaries SHOULD remove or replace field(s) whose
	semantics are known to require removal before forwarding, whether or
	not they appear as a Connection option, after applying those fields'
	semantics. This includes but is not limited to:
	o Proxy-Connection (Appendix C.1.2)
	o Keep-Alive (Section 19.7.1 of [RFC2068])
	o TE (Section 7.4)
	o Trailer (Section 5.6.3 of [Semantics])
	o Transfer-Encoding (Section 6.1)
	o Upgrade (Section 9.9)
	The Connection header field's value has the following grammar:
	Connection = 1#connection-option
	connection-option = token
	Connection options are case-insensitive.
	A sender MUST NOT send a connection option corresponding to a field
	that is intended for all recipients of the payload. For example,
	Cache-Control is never appropriate as a connection option
	(Section 5.2 of [Caching]).
	The connection options do not always correspond to a field present in
	the message, since a connection-specific field might not be needed if
	there are no parameters associated with a connection option. In
	contrast, a connection-specific field that is received without a
	corresponding connection option usually indicates that the field has
	been improperly forwarded by an intermediary and ought to be ignored
	by the recipient.
	When defining new connection options, specification authors ought to
	document it as reserved field name and register that definition in
	the Hypertext Transfer Protocol (HTTP) Field Name Registry
	(Section 5.3.2 of [Semantics]), to avoid collisions.
	The "close" connection option is defined for a sender to signal that
	this connection will be closed after completion of the response. For
	example,
	Connection: close
	in either the request or the response header fields indicates that
	the sender is going to close the connection after the current
	request/response is complete (Section 9.7).
	A client that does not support persistent connections MUST send the
	"close" connection option in every request message.
	A server that does not support persistent connections MUST send the
	"close" connection option in every response message that does not
	have a 1xx (Informational) status code.
	9.2. Establishment
	It is beyond the scope of this specification to describe how		It is beyond the scope of this specification to describe how
	connections are established via various transport- or session-layer		connections are established via various transport- or session-layer
	protocols. Each connection applies to only one transport link.		protocols. Each connection applies to only one transport link.
	9.3. Associating a Response to a Request		9.2. Associating a Response to a Request
	HTTP/1.1 does not include a request identifier for associating a		HTTP/1.1 does not include a request identifier for associating a
	given request message with its corresponding one or more response		given request message with its corresponding one or more response
	messages. Hence, it relies on the order of response arrival to		messages. Hence, it relies on the order of response arrival to
	correspond exactly to the order in which requests are made on the		correspond exactly to the order in which requests are made on the
	same connection. More than one response message per request only		same connection. More than one response message per request only
	occurs when one or more informational responses (1xx, see		occurs when one or more informational responses (1xx, see
	Section 10.2 of [Semantics]) precede a final response to the same		Section 10.2 of [Semantics]) precede a final response to the same
	request.		request.
	skipping to change at page 31, line 28 ¶		skipping to change at page 29, line 28 ¶
	MUST associate each received response message on that connection to		MUST associate each received response message on that connection to
	the highest ordered request that has not yet received a final (non-		the highest ordered request that has not yet received a final (non-
	1xx) response.		1xx) response.
	If an HTTP/1.1 client receives data on a connection that doesn't have		If an HTTP/1.1 client receives data on a connection that doesn't have
	any outstanding requests, it MUST NOT consider them to be a response		any outstanding requests, it MUST NOT consider them to be a response
	to a not-yet-issued request; it SHOULD close the connection, since		to a not-yet-issued request; it SHOULD close the connection, since
	message delimitation is now ambiguous, unless the data consists only		message delimitation is now ambiguous, unless the data consists only
	of one or more CRLF (which can be discarded, as per Section 2.2).		of one or more CRLF (which can be discarded, as per Section 2.2).
	9.4. Persistence		9.3. Persistence
	HTTP/1.1 defaults to the use of "persistent connections", allowing		HTTP/1.1 defaults to the use of "persistent connections", allowing
	multiple requests and responses to be carried over a single		multiple requests and responses to be carried over a single
	connection. The "close" connection option is used to signal that a		connection. The "close" connection option is used to signal that a
	connection will not persist after the current request/response. HTTP		connection will not persist after the current request/response. HTTP
	implementations SHOULD support persistent connections.		implementations SHOULD support persistent connections.
	A recipient determines whether a connection is persistent or not		A recipient determines whether a connection is persistent or not
	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 (Section 6.8 of [Semantics]), 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, either the recipient is not a proxy or the		option is present, either the recipient is not a proxy or the
	message is a response, and the recipient wishes to honor the		message is a response, and the recipient wishes to honor the
	HTTP/1.0 "keep-alive" mechanism, the connection will persist after		HTTP/1.0 "keep-alive" mechanism, the connection will persist after
	the current response; otherwise,		the current response; otherwise,
	o The connection will close after the current response.		o The connection will close after the current response.
			A client that does not support persistent connections MUST send the
			"close" connection option in every request message.
			A server that does not support persistent connections MUST send the
			"close" connection option in every response message that does not
			have a 1xx (Informational) status code.
	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
	the entire request message body or close the connection after sending		the entire request message body or close the connection after sending
	its response, since otherwise the remaining data on a persistent		its response, since otherwise the remaining data on a persistent
	connection would be misinterpreted as the next request. Likewise, a		connection would be misinterpreted as the next request. Likewise, a
	skipping to change at page 32, line 26 ¶		skipping to change at page 30, line 33 ¶
	reuse the same connection for a subsequent request.		reuse the same connection for a subsequent request.
	A proxy server MUST NOT maintain a persistent connection with an		A proxy server MUST NOT maintain a persistent connection with an
	HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and		HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
	discussion of the problems with the Keep-Alive header field		discussion of the problems with the Keep-Alive header field
	implemented by many HTTP/1.0 clients).		implemented by many HTTP/1.0 clients).
	See Appendix C.1.2 for more information on backwards compatibility		See Appendix C.1.2 for more information on backwards compatibility
	with HTTP/1.0 clients.		with HTTP/1.0 clients.
	9.4.1. Retrying Requests		9.3.1. Retrying Requests
	Connections can be closed at any time, with or without intention.		Connections can be closed at any time, with or without intention.
	Implementations ought to anticipate the need to recover from		Implementations ought to anticipate the need to recover from
	asynchronous close events. The conditions under which a client can		asynchronous close events. The conditions under which a client can
	automatically retry a sequence of outstanding requests are defined in		automatically retry a sequence of outstanding requests are defined in
	Section 8.2.2 of [Semantics].		Section 8.2.2 of [Semantics].
	9.4.2. Pipelining		9.3.2. Pipelining
	A client that supports persistent connections MAY "pipeline" its		A client that supports persistent connections MAY "pipeline" its
	requests (i.e., send multiple requests without waiting for each		requests (i.e., send multiple requests without waiting for each
	response). A server MAY process a sequence of pipelined requests in		response). A server MAY process a sequence of pipelined requests in
	parallel if they all have safe methods (Section 8.2.1 of		parallel if they all have safe methods (Section 8.2.1 of
	[Semantics]), but it MUST send the corresponding responses in the		[Semantics]), but it MUST send the corresponding responses in the
	same order that the requests were received.		same order that the requests were received.
	A client that pipelines requests SHOULD retry unanswered requests if		A client that pipelines requests SHOULD retry unanswered requests if
	the connection closes before it receives all of the corresponding		the connection closes before it receives all of the corresponding
	responses. When retrying pipelined requests after a failed		responses. When retrying pipelined requests after a failed
	connection (a connection not explicitly closed by the server in its		connection (a connection not explicitly closed by the server in its
	last complete response), a client MUST NOT pipeline immediately after		last complete response), a client MUST NOT pipeline immediately after
	connection establishment, since the first remaining request in the		connection establishment, since the first remaining request in the
	prior pipeline might have caused an error response that can be lost		prior pipeline might have caused an error response that can be lost
	again if multiple requests are sent on a prematurely closed		again if multiple requests are sent on a prematurely closed
	connection (see the TCP reset problem described in Section 9.7).		connection (see the TCP reset problem described in Section 9.6).
	Idempotent methods (Section 8.2.2 of [Semantics]) are significant to		Idempotent methods (Section 8.2.2 of [Semantics]) are significant to
	pipelining because they can be automatically retried after a		pipelining because they can be automatically retried after a
	connection failure. A user agent SHOULD NOT pipeline requests after		connection failure. A user agent SHOULD NOT pipeline requests after
	a non-idempotent method, until the final response status code for		a non-idempotent method, until the final response status code for
	that method has been received, unless the user agent has a means to		that method has been received, unless the user agent has a means to
	detect and recover from partial failure conditions involving the		detect and recover from partial failure conditions involving the
	pipelined sequence.		pipelined sequence.
	An intermediary that receives pipelined requests MAY pipeline those		An intermediary that receives pipelined requests MAY pipeline those
	requests when forwarding them inbound, since it can rely on the		requests when forwarding them inbound, since it can rely on the
	outbound user agent(s) to determine what requests can be safely		outbound user agent(s) to determine what requests can be safely
	pipelined. If the inbound connection fails before receiving a		pipelined. If the inbound connection fails before receiving a
	response, the pipelining intermediary MAY attempt to retry a sequence		response, the pipelining intermediary MAY attempt to retry a sequence
	of requests that have yet to receive a response if the requests all		of requests that have yet to receive a response if the requests all
	have idempotent methods; otherwise, the pipelining intermediary		have idempotent methods; otherwise, the pipelining intermediary
	SHOULD forward any received responses and then close the		SHOULD forward any received responses and then close the
	corresponding outbound connection(s) so that the outbound user		corresponding outbound connection(s) so that the outbound user
	agent(s) can recover accordingly.		agent(s) can recover accordingly.
	9.5. Concurrency		9.4. Concurrency
	A client ought to limit the number of simultaneous open connections		A client ought to limit the number of simultaneous open connections
	that it maintains to a given server.		that it maintains to a given server.
	Previous revisions of HTTP gave a specific number of connections as a		Previous revisions of HTTP gave a specific number of connections as a
	ceiling, but this was found to be impractical for many applications.		ceiling, but this was found to be impractical for many applications.
	As a result, this specification does not mandate a particular maximum		As a result, this specification does not mandate a particular maximum
	number of connections but, instead, encourages clients to be		number of connections but, instead, encourages clients to be
	conservative when opening multiple connections.		conservative when opening multiple connections.
	skipping to change at page 34, line 5 ¶		skipping to change at page 32, line 5 ¶
	blocking" problem, wherein a request that takes significant server-		blocking" problem, wherein a request that takes significant server-
	side processing and/or has a large payload blocks subsequent requests		side processing and/or has a large payload blocks subsequent requests
	on the same connection. However, each connection consumes server		on the same connection. However, each connection consumes server
	resources. Furthermore, using multiple connections can cause		resources. Furthermore, using multiple connections can cause
	undesirable side effects in congested networks.		undesirable side effects in congested networks.
	Note that a server might reject traffic that it deems abusive or		Note that a server might reject traffic that it deems abusive or
	characteristic of a denial-of-service attack, such as an excessive		characteristic of a denial-of-service attack, such as an excessive
	number of open connections from a single client.		number of open connections from a single client.
	9.6. Failures and Timeouts		9.5. Failures and Timeouts
	Servers will usually have some timeout value beyond which they will		Servers will usually have some timeout value beyond which they will
	no longer maintain an inactive connection. Proxy servers might make		no longer maintain an inactive connection. Proxy servers might make
	this a higher value since it is likely that the client will be making		this a higher value since it is likely that the client will be making
	more connections through the same proxy server. The use of		more connections through the same proxy server. The use of
	persistent connections places no requirements on the length (or		persistent connections places no requirements on the length (or
	existence) of this timeout for either the client or the server.		existence) of this timeout for either the client or the server.
	A client or server that wishes to time out SHOULD issue a graceful		A client or server that wishes to time out SHOULD issue a graceful
	close on the connection. Implementations SHOULD constantly monitor		close on the connection. Implementations SHOULD constantly monitor
	skipping to change at page 34, line 40 ¶		skipping to change at page 32, line 40 ¶
	expectation that clients will retry. The latter technique can		expectation that clients will retry. The latter technique can
	exacerbate network congestion.		exacerbate network congestion.
	A client sending a message body SHOULD monitor the network connection		A client sending a message body SHOULD monitor the network connection
	for an error response while it is transmitting the request. If the		for an error response while it is transmitting the request. If the
	client sees a response that indicates the server does not wish to		client sees a response that indicates the server does not wish to
	receive the message body and is closing the connection, the client		receive the message body and is closing the connection, the client
	SHOULD immediately cease transmitting the body and close its side of		SHOULD immediately cease transmitting the body and close its side of
	the connection.		the connection.
	9.7. Tear-down		9.6. Tear-down
	The Connection header field (Section 9.1) provides a "close"		The Connection header field (Section 6.8 of [Semantics]) provides a
	connection option that a sender SHOULD send when it wishes to close		"close" connection option that a sender SHOULD send when it wishes to
	the connection after the current request/response pair.		close the connection after the current request/response pair.
	A client that sends a "close" connection option MUST NOT send further		A client that sends a "close" connection option MUST NOT send further
	requests on that connection (after the one containing "close") and		requests on that connection (after the one containing "close") and
	MUST close the connection after reading the final response message		MUST close the connection after reading the final response message
	corresponding to this request.		corresponding to this request.
	A server that receives a "close" connection option MUST initiate a		A server that receives a "close" connection option MUST initiate a
	close of the connection (see below) after it sends the final response		close of the connection (see below) after it sends the final response
	to the request that contained "close". The server SHOULD send a		to the request that contained "close". The server SHOULD send a
	"close" connection option in its final response on that connection.		"close" connection option in its final response on that connection.
	skipping to change at page 35, line 45 ¶		skipping to change at page 33, line 45 ¶
	the write side of the read/write connection. The server then		the write side of the read/write connection. The server then
	continues to read from the connection until it receives a		continues to read from the connection until it receives a
	corresponding close by the client, or until the server is reasonably		corresponding close by the client, or until the server is reasonably
	certain that its own TCP stack has received the client's		certain that its own TCP stack has received the client's
	acknowledgement of the packet(s) containing the server's last		acknowledgement of the packet(s) containing the server's last
	response. Finally, the server fully closes the connection.		response. Finally, the server fully closes the connection.
	It is unknown whether the reset problem is exclusive to TCP or might		It is unknown whether the reset problem is exclusive to TCP or might
	also be found in other transport connection protocols.		also be found in other transport connection protocols.
			Note that a TCP connection that is half-closed by the client does not
			delimit a request message, nor does it imply that the client is no
			longer interested in a response. In general, transport signals
			cannot be relied upon to signal edge cases, since HTTP/1.1 is
			independent of transport.
			9.7. TLS Connection Initiation
			Conceptually, HTTP/TLS is simply sending HTTP messages over a
			connection secured via TLS [RFC8446].
			The HTTP client also acts as the TLS client. It initiates a
			connection to the server on the appropriate port and sends the TLS
			ClientHello to begin the TLS handshake. When the TLS handshake has
			finished, the client may then initiate the first HTTP request. All
			HTTP data MUST be sent as TLS "application data", but is otherwise
			treated like a normal connection for HTTP (including potential reuse
			as a persistent connection).
	9.8. TLS Connection Closure		9.8. TLS Connection Closure
	TLS provides a facility for secure connection closure. When a valid		TLS provides a facility for secure connection closure. When a valid
	closure alert is received, an implementation can be assured that no		closure alert is received, an implementation can be assured that no
	further data will be received on that connection. TLS		further data will be received on that connection. TLS
	implementations MUST initiate an exchange of closure alerts before		implementations MUST initiate an exchange of closure alerts before
	closing a connection. A TLS implementation MAY, after sending a		closing a connection. A TLS implementation MAY, after sending a
	closure alert, close the connection without waiting for the peer to		closure alert, close the connection without waiting for the peer to
	send its closure alert, generating an "incomplete close". Note that		send its closure alert, generating an "incomplete close". Note that
	an implementation which does this MAY choose to reuse the session.		an implementation which does this MAY choose to reuse the session.
	skipping to change at page 36, line 42 ¶		skipping to change at page 35, line 15 ¶
	Servers SHOULD be prepared to receive an incomplete close from the		Servers SHOULD be prepared to receive an incomplete close from the
	client, since the client can often determine when the end of server		client, since the client can often determine when the end of server
	data is. Servers SHOULD be willing to resume TLS sessions closed in		data is. Servers SHOULD be willing to resume TLS sessions closed in
	this fashion.		this fashion.
	Servers MUST attempt to initiate an exchange of closure alerts with		Servers MUST attempt to initiate an exchange of closure alerts with
	the client before closing the connection. Servers MAY close the		the client before closing the connection. Servers MAY close the
	connection after sending the closure alert, thus generating an		connection after sending the closure alert, thus generating an
	incomplete close on the client side.		incomplete close on the client side.
	9.9. Upgrade
	The "Upgrade" header field is intended to provide a simple mechanism
	for transitioning from HTTP/1.1 to some other protocol on the same
	connection.
	A client MAY send a list of protocol names in the Upgrade header
	field of a request to invite the server to switch to one or more of
	the named protocols, in order of descending preference, before
	sending the final response. A server MAY ignore a received Upgrade
	header field if it wishes to continue using the current protocol on
	that connection. Upgrade cannot be used to insist on a protocol
	change.
	Upgrade = 1#protocol
	protocol = protocol-name ["/" protocol-version]
	protocol-name = token
	protocol-version = token
	Although protocol names are registered with a preferred case,
	recipients SHOULD use case-insensitive comparison when matching each
	protocol-name to supported protocols.
	A server that sends a 101 (Switching Protocols) response MUST send an
	Upgrade header field to indicate the new protocol(s) to which the
	connection is being switched; if multiple protocol layers are being
	switched, the sender MUST list the protocols in layer-ascending
	order. A server MUST NOT switch to a protocol that was not indicated
	by the client in the corresponding request's Upgrade header field. A
	server MAY choose to ignore the order of preference indicated by the
	client and select the new protocol(s) based on other factors, such as
	the nature of the request or the current load on the server.
	A server that sends a 426 (Upgrade Required) response MUST send an
	Upgrade header field to indicate the acceptable protocols, in order
	of descending preference.
	A server MAY send an Upgrade header field in any other response to
	advertise that it implements support for upgrading to the listed
	protocols, in order of descending preference, when appropriate for a
	future request.
	The following is a hypothetical example sent by a client:
	GET /hello HTTP/1.1
	Host: www.example.com
	Connection: upgrade
	Upgrade: websocket, IRC/6.9, RTA/x11
	The capabilities and nature of the application-level communication
	after the protocol change is entirely dependent upon the new
	protocol(s) chosen. However, immediately after sending the 101
	(Switching Protocols) response, the server is expected to continue
	responding to the original request as if it had received its
	equivalent within the new protocol (i.e., the server still has an
	outstanding request to satisfy after the protocol has been changed,
	and is expected to do so without requiring the request to be
	repeated).
	For example, if the Upgrade header field is received in a GET request
	and the server decides to switch protocols, it first responds with a
	101 (Switching Protocols) message in HTTP/1.1 and then immediately
	follows that with the new protocol's equivalent of a response to a
	GET on the target resource. This allows a connection to be upgraded
	to protocols with the same semantics as HTTP without the latency cost
	of an additional round trip. A server MUST NOT switch protocols
	unless the received message semantics can be honored by the new
	protocol; an OPTIONS request can be honored by any protocol.
	The following is an example response to the above hypothetical
	request:
	HTTP/1.1 101 Switching Protocols
	Connection: upgrade
	Upgrade: websocket
	[... data stream switches to websocket with an appropriate response
	(as defined by new protocol) to the "GET /hello" request ...]
	When Upgrade is sent, the sender MUST also send a Connection header
	field (Section 9.1) that contains an "upgrade" connection option, in
	order to prevent Upgrade from being accidentally forwarded by
	intermediaries that might not implement the listed protocols. A
	server MUST ignore an Upgrade header field that is received in an
	HTTP/1.0 request.
	A client cannot begin using an upgraded protocol on the connection
	until it has completely sent the request message (i.e., the client
	can't change the protocol it is sending in the middle of a message).
	If a server receives both an Upgrade and an Expect header field with
	the "100-continue" expectation (Section 9.1.1 of [Semantics]), the
	server MUST send a 100 (Continue) response before sending a 101
	(Switching Protocols) response.
	The Upgrade header field only applies to switching protocols on top
	of the existing connection; it cannot be used to switch the
	underlying connection (transport) protocol, nor to switch the
	existing communication to a different connection. For those
	purposes, it is more appropriate to use a 3xx (Redirection) response
	(Section 10.4 of [Semantics]).
	9.9.1. Upgrade Protocol Names
	This specification only defines the protocol name "HTTP" for use by
	the family of Hypertext Transfer Protocols, as defined by the HTTP
	version rules of Section 4.2 of [Semantics] and future updates to
	this specification. Additional protocol names ought to be registered
	using the registration procedure defined in Section 9.9.2.
	+------+-------------------+-----------------+----------------+
	| Name | Description | Expected | Reference |
	| | | Version Tokens | |
	| HTTP | Hypertext | any DIGIT.DIGIT | Section 4.2 of |
	| | Transfer Protocol | (e.g, "2.0") | [Semantics] |
	+------+-------------------+-----------------+----------------+
	Table 4
	9.9.2. Upgrade Token Registry
	The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
	defines the namespace for protocol-name tokens used to identify
	protocols in the Upgrade header field. The registry is maintained at
	<https://www.iana.org/assignments/http-upgrade-tokens>.
	Each registered protocol name is associated with contact information
	and an optional set of specifications that details how the connection
	will be processed after it has been upgraded.
	Registrations happen on a "First Come First Served" basis (see
	Section 4.4 of [RFC8126]) and are subject to the following rules:
	1. A protocol-name token, once registered, stays registered forever.
	2. A protocol-name token is case-insensitive and registered with the
	preferred case to be generated by senders.
	3. The registration MUST name a responsible party for the
	registration.
	4. The registration MUST name a point of contact.
	5. The registration MAY name a set of specifications associated with
	that token. Such specifications need not be publicly available.
	6. The registration SHOULD name a set of expected "protocol-version"
	tokens associated with that token at the time of registration.
	7. The responsible party MAY change the registration at any time.
	The IANA will keep a record of all such changes, and make them
	available upon request.
	8. The IESG MAY reassign responsibility for a protocol token. This
	will normally only be used in the case when a responsible party
	cannot be contacted.
	10. Enclosing Messages as Data		10. Enclosing Messages as Data
	10.1. Media Type message/http		10.1. Media Type message/http
	The message/http media type can be used to enclose a single HTTP		The message/http media type can be used to enclose a single HTTP
	request or response message, provided that it obeys the MIME		request or response message, provided that it obeys the MIME
	restrictions for all "message" types regarding line length and		restrictions for all "message" types regarding line length and
	encodings.		encodings.
	Type name: message		Type name: message
	skipping to change at page 45, line 16 ¶		skipping to change at page 40, line 16 ¶
	Please update the "HTTP Transfer Coding Registry" at		Please update the "HTTP Transfer Coding Registry" at
	<https://www.iana.org/assignments/http-parameters/> with the		<https://www.iana.org/assignments/http-parameters/> with the
	registration procedure of Section 7.3 and the content coding names		registration procedure of Section 7.3 and the content coding names
	summarized in the table of Section 7.		summarized in the table of Section 7.
	12.4. Upgrade Token Registration		12.4. Upgrade Token Registration
	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.9.2 and the upgrade		with the registration procedure of Section 6.7.2 of [Semantics] and
	token names summarized in the table of Section 9.9.1.		the upgrade token names summarized in the table of Section 6.7.1 of
			[Semantics].
	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 |		---------- ----------------------------- ----------------
	| | 0x31 0x2e 0x31 ("http/1.1") | specification) |		HTTP/1.1 0x68 0x74 0x74 0x70 0x2f (this
	+----------+-----------------------------+----------------+		0x31 0x2e 0x31 ("http/1.1") specification)
			---------- ----------------------------- ----------------
	Table 5		Table 4
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,		[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
	Ed., "HTTP Caching", Work in Progress, Internet-Draft,		Ed., "HTTP Caching", Work in Progress, Internet-Draft,
	draft-ietf-httpbis-cache-10, July 12, 2020,		draft-ietf-httpbis-cache-11, August 27, 2020,
	<https://tools.ietf.org/html/draft-ietf-httpbis-cache-10>.		<https://tools.ietf.org/html/draft-ietf-httpbis-cache-11>.
	[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data		[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
	Format 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>.
	skipping to change at page 46, line 40 ¶		skipping to change at page 41, line 40 ¶
	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. F. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
	Ed., "HTTP Semantics", Work in Progress, Internet-Draft,		Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
	draft-ietf-httpbis-semantics-10, July 12, 2020,		draft-ietf-httpbis-semantics-11, August 27, 2020,
	<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-		<https://tools.ietf.org/html/draft-ietf-httpbis-semantics-
	10>.		11>.
	[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., "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
	skipping to change at page 48, line 25 ¶		skipping to change at page 43, line 25 ¶
	[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
	Section 5.5.1 of [Semantics].		Section 5.5.1 of [Semantics].
	BWS = <BWS, see [Semantics], Section 1.2.1>		BWS = <BWS, see [Semantics], Section 1.6.1>
	Connection = connection-option *( OWS "," OWS connection-option )
	HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [		HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [
	message-body ]		message-body ]
	HTTP-name = %x48.54.54.50 ; HTTP		HTTP-name = %x48.54.54.50 ; HTTP
	HTTP-version = HTTP-name "/" DIGIT "." DIGIT		HTTP-version = HTTP-name "/" DIGIT "." DIGIT
	OWS = <OWS, see [Semantics], Section 1.2.1>		OWS = <OWS, see [Semantics], Section 1.6.1>
	RWS = <RWS, see [Semantics], Section 1.2.1>
	TE = [ t-codings *( OWS "," OWS t-codings ) ]		RWS = <RWS, see [Semantics], Section 1.6.1>
	Transfer-Encoding = transfer-coding *( OWS "," OWS transfer-coding )
	Upgrade = protocol *( OWS "," OWS protocol )		Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding
			) ]
	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 = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS 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-section CRLF		chunked-body = *chunk last-chunk trailer-section CRLF
	comment = <comment, see [Semantics], Section 5.4.1.3>		comment = <comment, see [Semantics], Section 5.4.1.3>
	connection-option = token
	field-line = field-name ":" OWS field-value OWS		field-line = field-name ":" OWS field-value OWS
	field-name = <field-name, see [Semantics], Section 5.3>		field-name = <field-name, see [Semantics], Section 5.3>
	field-value = <field-value, see [Semantics], Section 5.4>		field-value = <field-value, see [Semantics], Section 5.4>
	last-chunk = 1*"0" [ chunk-ext ] CRLF		last-chunk = 1*"0" [ chunk-ext ] CRLF
	message-body = *OCTET		message-body = *OCTET
	method = token		method = token
	obs-fold = OWS CRLF RWS		obs-fold = OWS CRLF RWS
	obs-text = <obs-text, see [Semantics], Section 5.4.1.2>		obs-text = <obs-text, see [Semantics], Section 5.4.1.2>
	origin-form = absolute-path [ "?" query ]		origin-form = absolute-path [ "?" query ]
	port = <port, see [RFC3986], Section 3.2.3>		port = <port, see [RFC3986], Section 3.2.3>
	protocol = protocol-name [ "/" protocol-version ]
	protocol-name = token
	protocol-version = token
	query = <query, see [RFC3986], Section 3.4>		query = <query, see [RFC3986], Section 3.4>
	quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2>		quoted-string = <quoted-string, see [Semantics], Section 5.4.1.2>
	rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
	reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )		reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
	request-line = method SP request-target SP HTTP-version		request-line = method SP request-target SP HTTP-version
	request-target = origin-form / absolute-form / authority-form /		request-target = origin-form / absolute-form / authority-form /
	asterisk-form		asterisk-form
	start-line = request-line / status-line		start-line = request-line / status-line
	status-code = 3DIGIT		status-code = 3DIGIT
	status-line = HTTP-version SP status-code SP [ reason-phrase ]		status-line = HTTP-version SP status-code SP [ reason-phrase ]
	t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
	t-ranking = OWS ";" OWS "q=" rank
	token = <token, see [Semantics], Section 5.4.1.1>		token = <token, see [Semantics], Section 5.4.1.1>
	trailer-section = *( field-line CRLF )		trailer-section = *( field-line CRLF )
	transfer-coding = token *( OWS ";" OWS transfer-parameter )		transfer-coding = token *( OWS ";" OWS transfer-parameter )
	transfer-parameter = token BWS "=" BWS ( token / quoted-string )		transfer-parameter = token BWS "=" BWS ( token / quoted-string )
	uri-host = <host, see [RFC3986], Section 3.2.2>		uri-host = <host, see [RFC3986], Section 3.2.2>
	Appendix B. Differences between HTTP and MIME		Appendix B. Differences between HTTP and MIME
	HTTP/1.1 uses many of the constructs defined for the Internet Message		HTTP/1.1 uses many of the constructs defined for the Internet Message
	skipping to change at page 53, line 8 ¶		skipping to change at page 47, line 40 ¶
	properly encode the request-target.		properly encode the request-target.
	C.1. Changes from HTTP/1.0		C.1. Changes from HTTP/1.0
	This section summarizes major differences between versions HTTP/1.0		This section summarizes major differences between versions HTTP/1.0
	and HTTP/1.1.		and HTTP/1.1.
	C.1.1. Multihomed Web Servers		C.1.1. Multihomed Web Servers
	The requirements that clients and servers support the Host header		The requirements that clients and servers support the Host header
	field (Section 6.6 of [Semantics]), report an error if it is missing		field (Section 6.5 of [Semantics]), report an error if it is missing
	from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are		from an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are
	among the most important changes defined by HTTP/1.1.		among the most important changes defined by HTTP/1.1.
	Older HTTP/1.0 clients assumed a one-to-one relationship of IP		Older HTTP/1.0 clients assumed a one-to-one relationship of IP
	addresses and servers; there was no other established mechanism for		addresses and servers; there was no other established mechanism for
	distinguishing the intended server of a request than the IP address		distinguishing the intended server of a request than the IP address
	to which that request was directed. The Host header field was		to which that request was directed. The Host header field was
	introduced during the development of HTTP/1.1 and, though it was		introduced during the development of HTTP/1.1 and, though it was
	quickly implemented by most HTTP/1.0 browsers, additional		quickly implemented by most HTTP/1.0 browsers, additional
	requirements were placed on all HTTP/1.1 requests in order to ensure		requirements were placed on all HTTP/1.1 requests in order to ensure
	skipping to change at page 56, line 13 ¶		skipping to change at page 50, line 46 ¶
	<https://www.rfc-editor.org/errata/eid4839>)		<https://www.rfc-editor.org/errata/eid4839>)
	o Resolved erratum 4225, no change needed here		o Resolved erratum 4225, no change needed here
	(<https://github.com/httpwg/http-core/issues/90>,		(<https://github.com/httpwg/http-core/issues/90>,
	<https://www.rfc-editor.org/errata/eid4225>)		<https://www.rfc-editor.org/errata/eid4225>)
	o Replace "response code" with "response status code"		o Replace "response code" with "response status code"
	(<https://github.com/httpwg/http-core/issues/94>,		(<https://github.com/httpwg/http-core/issues/94>,
	<https://www.rfc-editor.org/errata/eid4050>)		<https://www.rfc-editor.org/errata/eid4050>)
	o In Section 9.4, clarify statement about HTTP/1.0 keep-alive		o In Section 9.3, clarify statement about HTTP/1.0 keep-alive
	(<https://github.com/httpwg/http-core/issues/96>,		(<https://github.com/httpwg/http-core/issues/96>,
	<https://www.rfc-editor.org/errata/eid4205>)		<https://www.rfc-editor.org/errata/eid4205>)
	o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="		o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="
	(<https://github.com/httpwg/http-core/issues/101>,		(<https://github.com/httpwg/http-core/issues/101>,
	<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-		<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-
	editor.org/errata/eid4825>)		editor.org/errata/eid4825>)
	o In Section 7.3, state that transfer codings should not use		o In Section 7.3, state that transfer codings should not use
	parameters named "q" (<https://github.com/httpwg/http-core/		parameters named "q" (<https://github.com/httpwg/http-core/
	issues/15>, <https://www.rfc-editor.org/errata/eid4683>)		issues/15>, <https://www.rfc-editor.org/errata/eid4683>)
	o In Section 7, mark coding name "trailers" as reserved in the IANA		o In Section 7, mark coding name "trailers" as reserved in the IANA
	registry (<https://github.com/httpwg/http-core/issues/108>)		registry (<https://github.com/httpwg/http-core/issues/108>)
	D.4. Since draft-ietf-httpbis-messaging-02		D.4. Since draft-ietf-httpbis-messaging-02
	o In Section 4, explain why the reason phrase should be ignored by		o In Section 4, explain why the reason phrase should be ignored by
	clients (<https://github.com/httpwg/http-core/issues/60>).		clients (<https://github.com/httpwg/http-core/issues/60>).
	o Add Section 9.3 to explain how request/response correlation is		o Add Section 9.2 to explain how request/response correlation is
	performed (<https://github.com/httpwg/http-core/issues/145>)		performed (<https://github.com/httpwg/http-core/issues/145>)
	D.5. Since draft-ietf-httpbis-messaging-03		D.5. Since draft-ietf-httpbis-messaging-03
	o In Section 9.3, caution against treating data on a connection as		o In Section 9.2, caution against treating data on a connection as
	part of a not-yet-issued request (<https://github.com/httpwg/http-		part of a not-yet-issued request (<https://github.com/httpwg/http-
	core/issues/26>)		core/issues/26>)
	o In Section 7, remove the predefined codings from the ABNF and make		o In Section 7, remove the predefined codings from the ABNF and make
	it generic instead (<https://github.com/httpwg/http-core/		it generic instead (<https://github.com/httpwg/http-core/
	issues/66>)		issues/66>)
	o Use RFC 7405 ABNF notation for case-sensitive string constants		o Use RFC 7405 ABNF notation for case-sensitive string constants
	(<https://github.com/httpwg/http-core/issues/133>)		(<https://github.com/httpwg/http-core/issues/133>)
	D.6. Since draft-ietf-httpbis-messaging-04		D.6. Since draft-ietf-httpbis-messaging-04
	o In Section 9.9, clarify that protocol-name is to be matched case-
	insensitively (<https://github.com/httpwg/http-core/issues/8>)		o In Section 6.7 of [Semantics], clarify that protocol-name is to be
			matched case-insensitively (<https://github.com/httpwg/http-core/
			issues/8>)
	o In Section 5.2, add leading optional whitespace to obs-fold ABNF		o In Section 5.2, add leading optional whitespace to obs-fold ABNF
	(<https://github.com/httpwg/http-core/issues/19>,		(<https://github.com/httpwg/http-core/issues/19>,
	<https://www.rfc-editor.org/errata/eid4189>)		<https://www.rfc-editor.org/errata/eid4189>)
	o In Section 4, add clarifications about empty reason phrases		o In Section 4, add clarifications about empty reason phrases
	(<https://github.com/httpwg/http-core/issues/197>)		(<https://github.com/httpwg/http-core/issues/197>)
	o Move discussion of retries from Section 9.4.1 into [Semantics]		o Move discussion of retries from Section 9.3.1 into [Semantics]
	(<https://github.com/httpwg/http-core/issues/230>)		(<https://github.com/httpwg/http-core/issues/230>)
	D.7. Since draft-ietf-httpbis-messaging-05		D.7. Since draft-ietf-httpbis-messaging-05
	o In Section 7.1.2, the trailer part has been renamed the trailer		o In Section 7.1.2, the trailer part has been renamed the trailer
	section (for consistency with the header section) and trailers are		section (for consistency with the header section) and trailers are
	no longer merged as header fields by default, but rather can be		no longer merged as header fields by default, but rather can be
	discarded, kept separate from header fields, or merged with header		discarded, kept separate from header fields, or merged with header
	fields only if understood and defined as being mergeable		fields only if understood and defined as being mergeable
	(<https://github.com/httpwg/http-core/issues/16>)		(<https://github.com/httpwg/http-core/issues/16>)
	o In Section 2.1 and related Sections, move the trailing CRLF from		o In Section 2.1 and related Sections, move the trailing CRLF from
	the line grammars into the message format		the line grammars into the message format
	(<https://github.com/httpwg/http-core/issues/62>)		(<https://github.com/httpwg/http-core/issues/62>)
	o Moved Section 2.3 down (<https://github.com/httpwg/http-core/		o Moved Section 2.3 down (<https://github.com/httpwg/http-core/
	issues/68>)		issues/68>)
	o In Section 9.9, use 'websocket' instead of 'HTTP/2.0' in examples		o In Section 6.7 of [Semantics], use 'websocket' instead of
	(<https://github.com/httpwg/http-core/issues/112>)		'HTTP/2.0' in examples (<https://github.com/httpwg/http-core/
			issues/112>)
	o Move version non-specific text from Section 6 into semantics as		o Move version non-specific text from Section 6 into semantics as
	"payload body" (<https://github.com/httpwg/http-core/issues/159>)		"payload body" (<https://github.com/httpwg/http-core/issues/159>)
	o In Section 9.8, add text from RFC 2818		o In Section 9.8, add text from RFC 2818
	(<https://github.com/httpwg/http-core/issues/236>)		(<https://github.com/httpwg/http-core/issues/236>)
	D.8. Since draft-ietf-httpbis-messaging-06		D.8. Since draft-ietf-httpbis-messaging-06
	o In Section 12.5, update the APLN protocol id for HTTP/1.1		o In Section 12.5, update the APLN protocol id for HTTP/1.1
	(<https://github.com/httpwg/http-core/issues/49>)		(<https://github.com/httpwg/http-core/issues/49>)
	o In Section 5, align with updates to field terminology in semantics		o In Section 5, align with updates to field terminology in semantics
	(<https://github.com/httpwg/http-core/issues/111>)		(<https://github.com/httpwg/http-core/issues/111>)
	o In Section 9.1, clarify that new connection options indeed need to		o In Section 6.8 of [Semantics], clarify that new connection options
	be registered (<https://github.com/httpwg/http-core/issues/285>)		indeed need to be registered (<https://github.com/httpwg/http-
			core/issues/285>)
	o In Section 1.1, reference RFC 8174 as well		o In Section 1.1, reference RFC 8174 as well
	(<https://github.com/httpwg/http-core/issues/303>)		(<https://github.com/httpwg/http-core/issues/303>)
	D.9. Since draft-ietf-httpbis-messaging-07		D.9. Since draft-ietf-httpbis-messaging-07
	o Move TE: trailers into [Semantics] (<https://github.com/httpwg/		o Move TE: trailers into [Semantics] (<https://github.com/httpwg/
	http-core/issues/18>)		http-core/issues/18>)
	o In Section 6.3, adjust requirements for handling multiple content-		o In Section 6.3, adjust requirements for handling multiple content-
	skipping to change at page 58, line 38 ¶		skipping to change at page 53, line 27 ¶
	(<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>)
	D.11. Since draft-ietf-httpbis-messaging-09		D.11. Since draft-ietf-httpbis-messaging-09
	o Switch to xml2rfc v3 mode for draft generation		o Switch to xml2rfc v3 mode for draft generation
	(<https://github.com/httpwg/http-core/issues/394>)		(<https://github.com/httpwg/http-core/issues/394>)
			D.12. Since draft-ietf-httpbis-messaging-10
			o In Section 6.3, note that TCP half-close does not delimit a
			request; talk about corresponding server-side behaviour in
			Section 9.6 (<https://github.com/httpwg/http-core/issues/22>)
			o Moved requirements specific to HTTP/1.1 from [Semantics] into
			Section 3.2 (<https://github.com/httpwg/http-core/issues/182>)
			o In Section 6.1 (Transfer-Encoding), adjust ABNF to allow empty
			lists (<https://github.com/httpwg/http-core/issues/210>)
			o In Section 9.7, add text from RFC 2818
			(<https://github.com/httpwg/http-core/issues/236>)
			o Moved definitions of "TE" and "Upgrade" into [Semantics]
			(<https://github.com/httpwg/http-core/issues/392>)
			o Moved definition of "Connection" into [Semantics]
			(<https://github.com/httpwg/http-core/issues/407>)
	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
	skipping to change at page 59, line 4 ¶		skipping to change at page 54, line 15 ¶
	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
			Prahran VIC
			Australia
	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
	48155 Münster		48155 Münster
	Germany		Germany
End of changes. 71 change blocks.
	433 lines changed or deleted		246 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/