frankenRFC723x_msg.txt		draft-ietf-httpbis-messaging-18.txt
	Internet Engineering Task Force (IETF) R. Fielding, Ed.		HTTP Working Group R. Fielding, Ed.
	Request for Comments: 7230 Adobe		Internet-Draft Adobe
	Obsoletes: 2145, 2616 J. Reschke, Ed.		Obsoletes: 7230 (if approved) M. Nottingham, Ed.
	Updates: 2817, 2818 greenbytes		Intended status: Standards Track Fastly
	Category: Standards Track June 2014		Expires: 19 February 2022 J. Reschke, Ed.
	ISSN: 2070-1721		greenbytes
			18 August 2021
	Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing		HTTP/1.1
			draft-ietf-httpbis-messaging-18
	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 provides an overview of HTTP architecture and		systems. This document specifies the HTTP/1.1 message syntax,
	its associated terminology, defines the "http" and "https" Uniform		message parsing, connection management, and related security
	Resource Identifier (URI) schemes, defines the HTTP/1.1 message		concerns.
	syntax and parsing requirements, and describes related security
	concerns for implementations.		This document obsoletes portions of RFC 7230.
	Editorial Note		Editorial Note
	This note is not in the original RFC.		This note is to be removed before publishing as an RFC.
	The purpose of this document is to produce diffs that show just the		Discussion of this draft takes place on the HTTP working group
	changes from text in the original RFCs that were input for http-core.		mailing list (ietf-http-wg@w3.org), which is archived at
	Hence, the frankenRFC documents show all of the original text (including		<https://lists.w3.org/Archives/Public/ietf-http-wg/>.
	stuff that has been deleted) plus some new text [in brackets] to anchor
	context, rearranged to minimize the resulting diffs when compared to the
	most recently published version of draft-ietf-httpbis-messaging.
	After this document is updated to match any reorg changes in the latest		Working Group information can be found at <https://httpwg.org/>;
	version, the franken diffs are saved and published in this directory as		source code and issues list for this draft can be found at
	diff_messaging_frfc_to_NN.html (where NN is the I-D draft revision)		<https://github.com/httpwg/http-core>.
			The changes in this draft are summarized in Appendix D.19.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This Internet-Draft is submitted in full conformance with the
			provisions of BCP 78 and BCP 79.
	This document is a product of the Internet Engineering Task Force		Internet-Drafts are working documents of the Internet Engineering
	(IETF). It represents the consensus of the IETF community. It has		Task Force (IETF). Note that other groups may also distribute
	received public review and has been approved for publication by the		working documents as Internet-Drafts. The list of current Internet-
	Internet Engineering Steering Group (IESG). Further information on		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet Standards is available in Section 2 of RFC 5741.
	Information about the current status of this document, any errata,		Internet-Drafts are draft documents valid for a maximum of six months
	and how to provide feedback on it may be obtained at		and may be updated, replaced, or obsoleted by other documents at any
	http://www.rfc-editor.org/info/rfc7230.		time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
			This Internet-Draft will expire on 19 February 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(http://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction ....................................................5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Notation ......................................6		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
	1.2. Syntax Notation ............................................6		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
	2. Architecture ....................................................6		2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Client/Server Messaging ....................................7		2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Implementation Diversity ...................................8		2.2. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7
	2.3. Intermediaries .............................................9		2.3. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 8
	2.4. Caches ....................................................11		3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.5. Conformance and Error Handling ............................12		3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 10
	2.6. Protocol Versioning .......................................13		3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
	2.7. Uniform Resource Identifiers ..............................16		3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 11
	2.7.1. http URI Scheme ....................................17		3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
	2.7.2. https URI Scheme ...................................18		3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 12
	2.7.3. http and https URI Normalization and Comparison ....19		3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12
	3. Message Format .................................................19		3.3. Reconstructing the Target URI . . . . . . . . . . . . . . 13
	3.1. Start Line ................................................20		4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 15
	3.1.1. Request Line .......................................21		5. Field Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.1.2. Status Line ........................................22		5.1. Field Line Parsing . . . . . . . . . . . . . . . . . . . 16
	3.2. Header Fields .............................................22		5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 17
	3.2.1. Field Extensibility ................................23		6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
	3.2.2. Field Order ........................................23		6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 18
	3.2.3. Whitespace .........................................24		6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 20
	3.2.4. Field Parsing ......................................25		6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 20
	3.2.5. Field Limits .......................................26		7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 23
	3.2.6. Field Value Components .............................27		7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 23
	3.3. Message Body ..............................................28		7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 24
	3.3.1. Transfer-Encoding ..................................28		7.1.2. Chunked Trailer Section . . . . . . . . . . . . . . . 25
	3.3.2. Content-Length .....................................30		7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25
	3.3.3. Message Body Length ................................32		7.2. Transfer Codings for Compression . . . . . . . . . . . . 26
	3.4. Handling Incomplete Messages ..............................34		7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26
	3.5. Message Parsing Robustness ................................34		7.4. Negotiating Transfer Codings . . . . . . . . . . . . . . 27
	4. Transfer Codings ...............................................35		8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 28
	4.1. Chunked Transfer Coding ...................................36		9. Connection Management . . . . . . . . . . . . . . . . . . . . 29
	4.1.1. Chunk Extensions ...................................36		9.1. Establishment . . . . . . . . . . . . . . . . . . . . . . 29
	4.1.2. Chunked Trailer Part ...............................37		9.2. Associating a Response to a Request . . . . . . . . . . . 29
	4.1.3. Decoding Chunked ...................................38		9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
	4.2. Compression Codings .......................................38		9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
	4.2.1. Compress Coding ....................................38		9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
	4.2.2. Deflate Coding .....................................38		9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
	4.2.3. Gzip Coding ........................................39		9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
	4.3. TE ........................................................39		9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
	4.4. Trailer ...................................................40		9.7. TLS Connection Initiation . . . . . . . . . . . . . . . . 35
	5. Message Routing ................................................40		9.8. TLS Connection Closure . . . . . . . . . . . . . . . . . 35
	5.1. Identifying a Target Resource .............................40		10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 36
	5.2. Connecting Inbound ........................................41		10.1. Media Type message/http . . . . . . . . . . . . . . . . 36
	5.3. Request Target ............................................41		10.2. Media Type application/http . . . . . . . . . . . . . . 37
	5.3.1. origin-form ........................................42		11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
	5.3.2. absolute-form ......................................42		11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 38
	5.3.3. authority-form .....................................43		11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 39
	5.3.4. asterisk-form ......................................43		11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 40
	5.4. Host ......................................................44		11.4. Message Confidentiality . . . . . . . . . . . . . . . . 40
	5.5. Effective Request URI .....................................45		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	5.6. Associating a Response to a Request .......................46		12.1. Field Name Registration . . . . . . . . . . . . . . . . 41
	5.7. Message Forwarding ........................................47		12.2. Media Type Registration . . . . . . . . . . . . . . . . 41
	5.7.1. Via ................................................47		12.3. Transfer Coding Registration . . . . . . . . . . . . . . 41
	5.7.2. Transformations ....................................49		12.4. ALPN Protocol ID Registration . . . . . . . . . . . . . 42
	6. Connection Management ..........................................50		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	6.1. Connection ................................................51		13.1. Normative References . . . . . . . . . . . . . . . . . . 43
	6.2. Establishment .............................................52		13.2. Informative References . . . . . . . . . . . . . . . . . 44
	6.3. Persistence ...............................................52		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 45
	6.3.1. Retrying Requests ..................................53		Appendix B. Differences between HTTP and MIME . . . . . . . . . 47
	6.3.2. Pipelining .........................................54		B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 47
	6.4. Concurrency ...............................................55		B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 47
	6.5. Failures and Timeouts .....................................55		B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 48
	6.6. Tear-down .................................................56		B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 48
	6.7. Upgrade ...................................................57		B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 48
	7. ABNF List Extension: #rule .....................................59		B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 48
	8. IANA Considerations ............................................61		Appendix C. Changes from previous RFCs . . . . . . . . . . . . . 49
	8.1. Header Field Registration .................................61		C.1. Changes from HTTP/0.9 . . . . . . . . . . . . . . . . . . 49
	8.2. URI Scheme Registration ...................................62		C.2. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 49
	8.3. Internet Media Type Registration ..........................62		C.2.1. Multihomed Web Servers . . . . . . . . . . . . . . . 49
	8.3.1. Internet Media Type message/http ...................62		C.2.2. Keep-Alive Connections . . . . . . . . . . . . . . . 49
	8.3.2. Internet Media Type application/http ...............63		C.2.3. Introduction of Transfer-Encoding . . . . . . . . . . 50
	8.4. Transfer Coding Registry ..................................64		C.3. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 50
	8.4.1. Procedure ..........................................65		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 51
	8.4.2. Registration .......................................65		D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 51
	8.5. Content Coding Registration ...............................66		D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 51
	8.6. Upgrade Token Registry ....................................66		D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 52
	8.6.1. Procedure ..........................................66		D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 52
	8.6.2. Upgrade Token Registration .........................67		D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 53
	9. Security Considerations ........................................67		D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 53
	9.1. Establishing Authority ....................................67		D.7. Since draft-ietf-httpbis-messaging-05 . . . . . . . . . . 53
	9.2. Risks of Intermediaries ...................................68		D.8. Since draft-ietf-httpbis-messaging-06 . . . . . . . . . . 54
	9.3. Attacks via Protocol Element Length .......................69		D.9. Since draft-ietf-httpbis-messaging-07 . . . . . . . . . . 54
	9.4. Response Splitting ........................................69		D.10. Since draft-ietf-httpbis-messaging-08 . . . . . . . . . . 54
	9.5. Request Smuggling .........................................70		D.11. Since draft-ietf-httpbis-messaging-09 . . . . . . . . . . 55
	9.6. Message Integrity .........................................70		D.12. Since draft-ietf-httpbis-messaging-10 . . . . . . . . . . 55
	9.7. Message Confidentiality ...................................71		D.13. Since draft-ietf-httpbis-messaging-11 . . . . . . . . . . 55
	9.8. Privacy of Server Log Information .........................71		D.14. Since draft-ietf-httpbis-messaging-12 . . . . . . . . . . 55
	10. Acknowledgments ...............................................72		D.15. Since draft-ietf-httpbis-messaging-13 . . . . . . . . . . 56
	11. References ....................................................74		D.16. Since draft-ietf-httpbis-messaging-14 . . . . . . . . . . 56
	11.1. Normative References .....................................74		D.17. Since draft-ietf-httpbis-messaging-15 . . . . . . . . . . 57
	11.2. Informative References ...................................75		D.18. Since draft-ietf-httpbis-messaging-16 . . . . . . . . . . 57
	Appendix A. HTTP Version History ..................................78		D.19. Since draft-ietf-httpbis-messaging-17 . . . . . . . . . . 57
	A.1. Changes from HTTP/1.0 ....................................78		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57
	A.1.1. Multihomed Web Servers ............................78		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
	A.1.2. Keep-Alive Connections ............................79		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
	A.1.3. Introduction of Transfer-Encoding .................79
	A.2. Changes from RFC 2616 ....................................80
	Appendix B. Collected ABNF ........................................82
	Index .............................................................85
	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 message payloads for flexible interaction with		self-descriptive messages for flexible interaction with network-based
	network-based hypertext information systems. This document is the		hypertext information systems. HTTP/1.1 is defined by:
	first in a series of documents that collectively form the HTTP/1.1
	specification:
	1. "Message Syntax and Routing" (this document)
	2. "Semantics and Content" [RFC7231]
	3. "Conditional Requests" [RFC7232]
	4. "Range Requests" [RFC7233]
	5. "Caching" [RFC7234]		* This document
	6. "Authentication" [RFC7235]		* "HTTP Semantics" [HTTP]
			* "HTTP Caching" [CACHING]
	This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP		This document specifies how HTTP semantics are conveyed using the
	versioning). This specification also updates the use of CONNECT to		HTTP/1.1 message syntax, framing and connection management
	establish a tunnel, previously defined in RFC 2817, and defines the		mechanisms. Its goal is to define the complete set of requirements
	"https" URI scheme that was described informally in RFC 2818.		for HTTP/1.1 message parsers and message-forwarding intermediaries.
	This document describes the architectural elements that are used or		This document obsoletes the portions of RFC 7230 related to HTTP/1.1
	referred to in HTTP, defines the "http" and "https" URI schemes,		messaging and connection management, with the changes being
	describes overall network operation and connection management, and		summarized in Appendix C.3. The other parts of RFC 7230 are
	defines HTTP message framing and forwarding requirements. Our goal		obsoleted by "HTTP Semantics" [HTTP].
	is to define all of the mechanisms necessary for HTTP message
	handling that are independent of message semantics, thereby defining
	the complete set of requirements for message parsers and message-
	forwarding intermediaries.
	1.1. Requirements Notation		1.1. Requirements Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	Conformance criteria and considerations regarding error handling are		Conformance criteria and considerations regarding error handling are
	defined in Section 2.5.		defined in Section 2 of [HTTP].
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] with a list extension, defined in Section 7,		notation of [RFC5234], extended with the notation for case-
			sensitivity in strings defined in [RFC7405].
			It also uses a list extension, defined in Section 5.6.1 of [HTTP],
	that allows for compact definition of comma-separated lists using a		that allows for compact definition of comma-separated lists using a
	'#' operator (similar to how the '*' operator indicates repetition).		'#' operator (similar to how the '*' operator indicates repetition).
	Appendix B shows the collected grammar with all list operators		Appendix A shows the collected grammar with all list operators
	expanded to standard ABNF notation.		expanded to standard ABNF notation.
	As a convention, ABNF rule names prefixed with "obs-" denote		As a convention, ABNF rule names prefixed with "obs-" denote
	"obsolete" grammar rules that appear for historical reasons.		"obsolete" grammar rules that appear for historical reasons.
	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 [RFC7230]:		The rules below are defined in [HTTP]:
	BWS = <BWS, see [RFC7230], Section 3.2.3>		BWS = <BWS, see [HTTP], Section 5.6.3>
	OWS = <OWS, see [RFC7230], Section 3.2.3>		OWS = <OWS, see [HTTP], Section 5.6.3>
	RWS = <RWS, see [RFC7230], Section 3.2.3>		RWS = <RWS, see [HTTP], Section 5.6.3>
	comment = <comment, see [RFC7230], Section 3.2.6>		absolute-path = <absolute-path, see [HTTP], Section 4>
	field-name = <comment, see [RFC7230], Section 3.2>		field-name = <field-name, see [HTTP], Section 5.1>
	quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>		field-value = <field-value, see [HTTP], Section 5.5>
	token = <token, see [RFC7230], Section 3.2.6>		obs-text = <obs-text, see [HTTP], Section 5.6.4>
			quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
			token = <token, see [HTTP], Section 5.6.2>
			transfer-coding =
			<transfer-coding, see [HTTP], Section 10.1.4>
	[new]		The rules below are defined in [URI]:
	absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>		absolute-URI = <absolute-URI, see [URI], Section 4.3>
	partial-URI = <partial-URI, see [RFC7230], Section 2.7>		authority = <authority, see [URI], Section 3.2>
	URI-reference = <URI-reference, see [RFC7230], Section 2.7>		uri-host = <host, see [URI], Section 3.2.2>
			port = <port, see [URI], Section 3.2.3>
			query = <query, see [URI], Section 3.4>
	2. Message		2. Message
			HTTP/1.1 clients and servers communicate by sending messages. See
			Section 3 of [HTTP] for the general terminology and core concepts of
			HTTP.
	2.1. Message Format		2.1. Message Format
	All HTTP/1.1 messages consist of a start-line followed by a sequence		An HTTP/1.1 message consists of a start-line followed by a CRLF and a
	of octets in a format similar to the Internet Message Format		sequence of octets in a format similar to the Internet Message Format
	[RFC5322]: zero or more header fields (collectively referred to as		[RFC5322]: zero or more header field lines (collectively referred to
	the "headers" or the "header section"), an empty line indicating the		as the "headers" or the "header section"), an empty line indicating
	end of the header section, and an optional message body.		the end of the header section, and an optional message body.
	HTTP-message = start-line		HTTP-message = start-line CRLF
	*( header-field CRLF )		*( field-line CRLF )
	CRLF		CRLF
	[ message-body ]		[ message-body ]
	3.1. Start Line		A message can be either a request from client to server or a response
			from server to client. Syntactically, the two types of message
	An HTTP message can be either a request from client to server or a		differ only in the start-line, which is either a request-line (for
	response from server to client. Syntactically, the two types of		requests) or a status-line (for responses), and in the algorithm for
	message differ only in the start-line, which is either a request-line		determining the length of the message body (Section 6).
	(for requests) or a status-line (for responses), and in the algorithm
	for determining the length of the message body (Section 3.3).
	start-line = request-line / status-line		start-line = request-line / status-line
	In theory, a client could receive requests and a server could receive		In theory, a client could receive requests and a server could receive
	responses, distinguishing them by their different start-line formats,		responses, distinguishing them by their different start-line formats.
	but, in practice, servers are implemented to only expect a request (a		In practice, servers are implemented to only expect a request (a
	response is interpreted as an unknown or invalid request method) and		response is interpreted as an unknown or invalid request method) and
	clients are implemented to only expect a response.		clients are implemented to only expect a response.
	Messages are passed in a format similar to that used by Internet mail		HTTP makes use of some protocol elements similar to the Multipurpose
	[RFC5322] and the		Internet Mail Extensions (MIME) [RFC2045]. See Appendix B for the
	Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see Appendix A		differences between HTTP and MIME messages.
	of [RFC7231] for the differences between HTTP and MIME messages).
	2.2. Message Parsing Robustness		2.2. Message Parsing
	The normal procedure for parsing an HTTP message is to read the		The normal procedure for parsing an HTTP message is to read the
	start-line into a structure, read each header field into a hash table		start-line into a structure, read each header field line into a hash
	by field name until the empty line, and then use the parsed data to		table by field name until the empty line, and then use the parsed
	determine if a message body is expected. If a message body has been		data to determine if a message body is expected. If a message body
	indicated, then it is read as a stream until an amount of octets		has been indicated, then it is read as a stream until an amount of
	equal to the message body length is read or the connection is closed.		octets equal to the message body length is read or the connection is
			closed.
	A recipient MUST parse an HTTP message as a sequence of octets in an		A recipient MUST parse an HTTP message as a sequence of octets in an
	encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP		encoding that is a superset of US-ASCII [USASCII]. Parsing an HTTP
	message as a stream of Unicode characters, without regard for the		message as a stream of Unicode characters, without regard for the
	specific encoding, creates security vulnerabilities due to the		specific encoding, creates security vulnerabilities due to the
	varying ways that string processing libraries handle invalid		varying ways that string processing libraries handle invalid
	multibyte character sequences that contain the octet LF (%x0A).		multibyte character sequences that contain the octet LF (%x0A).
	String-based parsers can only be safely used within protocol elements		String-based parsers can only be safely used within protocol elements
	after the element has been extracted from the message, such as within		after the element has been extracted from the message, such as within
	a header field-value after message parsing has delineated the		a header field line value after message parsing has delineated the
	individual fields.		individual field lines.
	Although the line terminator for the start-line and header fields is		Although the line terminator for the start-line and fields is the
	the sequence CRLF, a recipient MAY recognize a single LF as a line		sequence CRLF, a recipient MAY recognize a single LF as a line
	terminator and ignore any preceding CR.		terminator and ignore any preceding CR.
			A sender MUST NOT generate a bare CR (a CR character not immediately
			followed by LF) within any protocol elements other than the content.
			A recipient of such a bare CR MUST consider that element to be
			invalid or replace each bare CR with SP before processing the element
			or forwarding the message.
	Older HTTP/1.0 user agent implementations might send an extra CRLF		Older HTTP/1.0 user agent implementations might send an extra CRLF
	after a POST request as a workaround for some early server		after a POST request as a workaround for some early server
	applications that failed to read message body content that was not		applications that failed to read message body content that was not
	terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface		terminated by a line-ending. An HTTP/1.1 user agent MUST NOT preface
	or follow a request with an extra CRLF. If terminating the request		or follow a request with an extra CRLF. If terminating the request
	message body with a line-ending is desired, then the user agent MUST		message body with a line-ending is desired, then the user agent MUST
	count the terminating CRLF octets as part of the message body length.		count the terminating CRLF octets as part of the message body length.
	In the interest of robustness, a server that is expecting to receive		In the interest of robustness, a server that is expecting to receive
	and parse a request-line SHOULD ignore at least one empty line (CRLF)		and parse a request-line SHOULD ignore at least one empty line (CRLF)
	received prior to the request-line.		received prior to the request-line.
	A sender MUST NOT send whitespace between the start-line and the		A sender MUST NOT send whitespace between the start-line and the
	first header field. A recipient that receives whitespace between the		first header field.
	start-line and the first header field MUST either reject the message
	as invalid or consume each whitespace-preceded line without further
	processing of it (i.e., ignore the entire line, along with any
	subsequent lines preceded by whitespace, until a properly formed
	header field is received or the header section is terminated).
	The presence of such whitespace in a request might be an attempt to		A recipient that receives whitespace between the start-line and the
	trick a server into ignoring that field or processing the line after		first header field MUST either reject the message as invalid or
	it as a new request, either of which might result in a security		consume each whitespace-preceded line without further processing of
	vulnerability if other implementations within the request chain		it (i.e., ignore the entire line, along with any subsequent lines
	interpret the same message differently. Likewise, the presence of		preceded by whitespace, until a properly formed header field is
	such whitespace in a response might be ignored by some clients or		received or the header section is terminated). Rejection or removal
	cause others to cease parsing.		of invalid whitespace-preceded lines is necessary to prevent their
			misinterpretation by downstream recipients that might be vulnerable
			to request smuggling (Section 11.2) or response splitting
			(Section 11.1) attacks.
	When a server listening only for HTTP request messages, or processing		When a server listening only for HTTP request messages, or processing
	what appears from the start-line to be an HTTP request message,		what appears from the start-line to be an HTTP request message,
	receives a sequence of octets that does not match the HTTP-message		receives a sequence of octets that does not match the HTTP-message
	grammar aside from the robustness exceptions listed above, the server		grammar aside from the robustness exceptions listed above, the server
	SHOULD respond with a 400 (Bad Request) response.		SHOULD respond with a 400 (Bad Request) response and close the
			connection.
	2.6. Protocol Versioning		2.3. HTTP Version
	HTTP uses a "<major>.<minor>" numbering scheme to indicate versions		HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
	of the protocol. This specification defines version "1.1".		of the protocol. This specification defines version "1.1".
			Section 2.5 of [HTTP] specifies the semantics of HTTP version
			numbers.
	The version of an HTTP message is indicated by an HTTP-version field		The version of an HTTP/1.x message is indicated by an HTTP-version
	in the first line of the message. HTTP-version is case-sensitive.		field in the start-line. HTTP-version is case-sensitive.
	HTTP-version = HTTP-name "/" DIGIT "." DIGIT		HTTP-version = HTTP-name "/" DIGIT "." DIGIT
	HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive		HTTP-name = %s"HTTP"
	When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [RFC1945]		When an HTTP/1.1 message is sent to an HTTP/1.0 recipient [HTTP/1.0]
	or a recipient whose version is unknown, the HTTP/1.1 message is		or a recipient whose version is unknown, the HTTP/1.1 message is
	constructed such that it can be interpreted as a valid HTTP/1.0		constructed such that it can be interpreted as a valid HTTP/1.0
	message if all of the newer features are ignored. This specification		message if all of the newer features are ignored. This specification
	places recipient-version requirements on some new features so that a		places recipient-version requirements on some new features so that a
	conformant sender will only use compatible features until it has		conformant sender will only use compatible features until it has
	determined, through configuration or the receipt of a message, that		determined, through configuration or the receipt of a message, that
	the recipient supports HTTP/1.1.		the recipient supports HTTP/1.1.
	Intermediaries that process HTTP messages (i.e., all intermediaries		Intermediaries that process HTTP messages (i.e., all intermediaries
	other than those acting as tunnels) MUST send their own HTTP-version		other than those acting as tunnels) MUST send their own HTTP-version
	in forwarded messages. In other words, they are not allowed to		in forwarded messages, unless it is purposefully downgraded as a
	blindly forward the first line of an HTTP message without ensuring		workaround for an upstream issue. In other words, an intermediary is
	that the protocol version in that message matches a version to which		not allowed to blindly forward the start-line without ensuring that
	that intermediary is conformant for both the receiving and sending of		the protocol version in that message matches a version to which that
	messages. Forwarding an HTTP message without rewriting the		intermediary is conformant for both the receiving and sending of
	HTTP-version might result in communication errors when downstream		messages. Forwarding an HTTP message without rewriting the HTTP-
			version might result in communication errors when downstream
	recipients use the message sender's version to determine what		recipients use the message sender's version to determine what
	features are safe to use for later communication with that sender.		features are safe to use for later communication with that sender.
	A server MAY send an HTTP/1.0 response to a request if it is known or		A server MAY send an HTTP/1.0 response to an HTTP/1.1 request if it
	suspected that the client incorrectly implements the HTTP		is known or suspected that the client incorrectly implements the HTTP
	specification and is incapable of correctly processing later version		specification and is incapable of correctly processing later version
	responses, such as when a client fails to parse the version number		responses, such as when a client fails to parse the version number
	correctly or when an intermediary is known to blindly forward the		correctly or when an intermediary is known to blindly forward the
	HTTP-version even when it doesn't conform to the given minor version		HTTP-version even when it doesn't conform to the given minor version
	of the protocol. Such protocol downgrades SHOULD NOT be performed		of the protocol. Such protocol downgrades SHOULD NOT be performed
	unless triggered by specific client attributes, such as when one or		unless triggered by specific client attributes, such as when one or
	more of the request header fields (e.g., User-Agent) uniquely match		more of the request header fields (e.g., User-Agent) uniquely match
	the values sent by a client known to be in error.		the values sent by a client known to be in error.
	3.1.1. Request Line		3. Request Line
	A request-line begins with a method token, followed by a single space		A request-line begins with a method token, followed by a single space
	(SP), the request-target, another single space (SP), the protocol		(SP), the request-target, another single space (SP), and ends with
	version, and ends with CRLF.		the protocol version.
	request-line = method SP request-target SP HTTP-version CRLF		request-line = method SP request-target SP HTTP-version
	Although the request-line and status-line grammar rules require that		Although the request-line grammar rule requires that each of the
	each of the component elements be separated by a single SP octet,		component elements be separated by a single SP octet, recipients MAY
	recipients MAY instead parse on whitespace-delimited word boundaries		instead parse on whitespace-delimited word boundaries and, aside from
	and, aside from the CRLF terminator, treat any form of whitespace as		the CRLF terminator, treat any form of whitespace as the SP separator
	the SP separator while ignoring preceding or trailing whitespace;		while ignoring preceding or trailing whitespace; such whitespace
	such whitespace includes one or more of the following octets: SP,		includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
	HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can		(%x0C), or bare CR. However, lenient parsing can result in request
	result in security vulnerabilities if there are multiple recipients		smuggling security vulnerabilities if there are multiple recipients
	of the message and each has its own unique interpretation of		of the message and each has its own unique interpretation of
	robustness (see Section 9.5).		robustness (see Section 11.2).
	HTTP does not place a predefined limit on the length of a		HTTP does not place a predefined limit on the length of a request-
	request-line, as described in Section 2.5. A server that receives a		line, as described in Section 2 of [HTTP]. A server that receives a
	method longer than any that it implements SHOULD respond with a 501		method longer than any that it implements SHOULD respond with a 501
	(Not Implemented) status code. A server that receives a		(Not Implemented) status code. A server that receives a request-
	request-target longer than any URI it wishes to parse MUST respond		target longer than any URI it wishes to parse MUST respond with a 414
	with a 414 (URI Too Long) status code (see Section 6.5.12 of		(URI Too Long) status code (see Section 15.5.15 of [HTTP]).
	[RFC7231]).
	Various ad hoc limitations on request-line length are found in		Various ad hoc limitations on request-line length are found in
	practice. It is RECOMMENDED that all HTTP senders and recipients		practice. It is RECOMMENDED that all HTTP senders and recipients
	support, at a minimum, request-line lengths of 8000 octets.		support, at a minimum, request-line lengths of 8000 octets.
			3.1. Method
	The method token indicates the request method to be performed on the		The method token indicates the request method to be performed on the
	target resource. The request method is case-sensitive.		target resource. The request method is case-sensitive.
	method = token		method = token
	The request methods defined by this specification can be found in		The request methods defined by this specification can be found in
	Section 4 of [RFC7231], along with information regarding the HTTP		Section 9 of [HTTP], along with information regarding the HTTP method
	method registry and considerations for defining new methods.		registry and considerations for defining new methods.
	3.2. Request Target		3.2. Request Target
	The request-target identifies the target resource upon which to apply		The request-target identifies the target resource upon which to apply
	the request, as defined in Section 5.3.		the request. The client derives a request-target from its desired
	Once an inbound connection is obtained, the client sends an HTTP
	request message (Section 3) with a request-target derived from the
	target URI. There are four distinct formats for the request-target,		target URI. There are four distinct formats for the request-target,
	depending on both the method being requested and whether the request		depending on both the method being requested and whether the request
	is to a proxy.		is to a proxy.
	request-target = origin-form		request-target = origin-form
	/ absolute-form		/ absolute-form
	/ authority-form		/ authority-form
	/ asterisk-form		/ asterisk-form
	Recipients typically parse the request-line into its component parts		No whitespace is allowed in the request-target. Unfortunately, some
	by splitting on whitespace (see Section 3.5), since no whitespace is		user agents fail to properly encode or exclude whitespace found in
	allowed in the three components. Unfortunately, some user agents		hypertext references, resulting in those disallowed characters being
	fail to properly encode or exclude whitespace found in hypertext		sent as the request-target in a malformed request-line.
	references, resulting in those disallowed characters being sent in a
	request-target.
	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		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		messages. If the target URI includes an authority component, then a
	client MUST send a field-value for Host that is identical to that		client MUST send a field value for Host that is identical to that
	authority component, excluding any userinfo subcomponent and its "@"		authority component, excluding any userinfo subcomponent and its "@"
	delimiter (Section 2.7.1). If the authority component is missing or		delimiter (Section 4.2.1 of [HTTP]). If the authority component is
	undefined for the target URI, then a client MUST send a Host header		missing or undefined for the target URI, then a client MUST send a
	field with an empty field-value.		Host header field with an empty field value.
	A server MUST respond with a 400 (Bad Request) status code to any		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		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		request message that contains more than one Host header field line or
	Host header field with an invalid field-value.		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 5.4.		Section 7.2 of [HTTP].
	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:
	GET /where?q=now HTTP/1.1		GET /where?q=now HTTP/1.1
	Host: www.example.org		Host: www.example.org
	followed by the remainder of the request message.		followed by the remainder of the request message.
	3.2.2. absolute-form		3.2.2. absolute-form
	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 5.7.		"forwarding" of messages are defined in Section 7.6 of [HTTP].
	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.
	When a proxy receives a request with an absolute-form of		When a proxy receives a request with an absolute-form of request-
	request-target, the proxy MUST ignore the received Host header field		target, the proxy MUST ignore the received Host header field (if any)
	(if any) and instead replace it with the host information of the		and instead replace it with the host information of the request-
	request-target. A proxy that forwards such a request MUST generate a		target. A proxy that forwards such a request MUST generate a new
	new Host field-value based on the received request-target rather than		Host field value based on the received request-target rather than
	forward the received Host field-value.		forward the received Host field value.
	To allow for transition to the absolute-form for all requests in some		When an origin server receives a request with an absolute-form of
	future version of HTTP, a server MUST accept the absolute-form in		request-target, the origin server MUST ignore the received Host
	requests, even though HTTP/1.1 clients will only send them in		header field (if any) and instead use the host information of the
	requests to proxies.		request-target. Note that if the request-target does not have an
			authority component, an empty Host header field will be sent in this
			case.
			A server MUST accept the absolute-form in requests even though most
			HTTP/1.1 clients will only send the absolute-form to a proxy.
	3.2.3. authority-form		3.2.3. authority-form
	The authority-form of request-target is only used for CONNECT		The _authority-form_ of request-target is only used for CONNECT
	requests (Section 4.3.6 of [RFC7231]).		requests (Section 9.3.6 of [HTTP]). It consists of only the uri-host
			and port number of the tunnel destination, separated by a colon
			(":").
	authority-form = authority		authority-form = uri-host ":" port
	When making a CONNECT request to establish a tunnel through one or		When making a CONNECT request to establish a tunnel through one or
	more proxies, a client MUST send only the target URI's authority		more proxies, a client MUST send only the host and port of the tunnel
	component (excluding any userinfo and its "@" delimiter) as the		destination as the request-target. The client obtains the host and
	request-target. For example,		port from the target URI's authority component, except that it sends
			the scheme's default port if the target URI elides the port. For
			example, a CONNECT request to "http://www.example.com" looks like
	CONNECT www.example.com:80 HTTP/1.1		CONNECT www.example.com:80 HTTP/1.1
			Host: www.example.com
	3.2.4. asterisk-form		3.2.4. asterisk-form
	The asterisk-form of request-target is only used for a server-wide		The _asterisk-form_ of request-target is only used for a server-wide
	OPTIONS request (Section 4.3.7 of [RFC7231]).		OPTIONS request (Section 9.3.7 of [HTTP]).
	asterisk-form = "*"		asterisk-form = "*"
	When a client wishes to request OPTIONS for the server as a whole, as		When a client wishes to request OPTIONS for the server as a whole, as
	opposed to a specific named resource of that server, the client MUST		opposed to a specific named resource of that server, the client MUST
	send only "*" (%x2A) as the request-target. For example,		send only "*" (%x2A) as the request-target. For example,
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	If a proxy receives an OPTIONS request with an absolute-form of		If a proxy receives an OPTIONS request with an absolute-form of
	request-target in which the URI has an empty path and no query		request-target in which the URI has an empty path and no query
	component, then the last proxy on the request chain MUST send a		component, then the last proxy on the request chain MUST send a
	request-target of "*" when it forwards the request to the indicated		request-target of "*" when it forwards the request to the indicated
	origin server.		origin server.
	For example, the request		For example, the request
	OPTIONS http://www.example.org:8001 HTTP/1.1		OPTIONS http://www.example.org:8001 HTTP/1.1
	would be forwarded by the final proxy as		would be forwarded by the final proxy as
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	Host: www.example.org:8001		Host: www.example.org:8001
	after connecting to port 8001 of host "www.example.org".		after connecting to port 8001 of host "www.example.org".
	3.5. Effective Request URI		3.3. Reconstructing the Target URI
	Since the request-target often contains only part of the user agent's		The target URI is the request-target when the request-target is in
	target URI, a server reconstructs the intended target as an		absolute-form. In that case, a server will parse the URI into its
	"effective request URI" to properly service the request.		generic components for further evaluation.
	If the request-target is in absolute-form, the effective request URI		Otherwise, the server reconstructs the target URI from the connection
	is the same as the request-target. Otherwise, the effective request		context and various parts of the request message in order to identify
	URI is constructed as follows:		the target resource (Section 7.1 of [HTTP]):
	If the server's configuration (or outbound gateway) provides a		* If the server's configuration provides for a fixed URI scheme, or
	fixed URI scheme, that scheme is used for the effective request		a scheme is provided by a trusted outbound gateway, that scheme is
	URI. Otherwise, if the request is received over a TLS-secured TCP		used for the target URI. This is common in large-scale
	connection, the effective request URI's scheme is "https"; if not,		deployments because a gateway server will receive the client's
			connection context and replace that with their own connection to
			the inbound server. Otherwise, if the request is received over a
			secured connection, the target URI's scheme is "https"; if not,
	the scheme is "http".		the scheme is "http".
	If the server's configuration (or outbound gateway) provides a		* If the request-target is in authority-form, the target URI's
	fixed URI authority component, that authority is used for the		authority component is the request-target. Otherwise, the target
	effective request URI. If not, then if the request-target is in		URI's authority component is the field value of the Host header
	authority-form, the effective request URI's authority component is		field. If there is no Host header field or if its field value is
	the same as the request-target. If not, then if a Host header		empty or invalid, the target URI's authority component is empty.
	field is supplied with a non-empty field-value, the authority
	component is the same as the Host field-value. Otherwise, the
	authority component is assigned the default name configured for
	the server and, if the connection's incoming TCP port number
	differs from the default port for the effective request URI's
	scheme, then a colon (":") and the incoming port number (in
	decimal form) are appended to the authority component.
	If the request-target is in authority-form or asterisk-form, the		* If the request-target is in authority-form or asterisk-form, the
	effective request URI's combined path and query component is		target URI's combined path and query component is empty.
	empty. Otherwise, the combined path and query component is the		Otherwise, the target URI's combined path and query component is
	same as the request-target.		the request-target.
	The components of the effective request URI, once determined as		* The components of a reconstructed target URI, once determined as
	above, can be combined into absolute-URI form by concatenating the		above, can be recombined into absolute-URI form by concatenating
	scheme, "://", authority, and combined path and query component.		the scheme, "://", authority, and combined path and query
			component.
	Example 1: the following message received over an insecure TCP		Example 1: the following message received over a secure 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
	has an effective request URI of		has a target URI of
	http://www.example.org:8080/pub/WWW/TheProject.html		https://www.example.org/pub/WWW/TheProject.html
	Example 2: the following message received over a TLS-secured TCP		Example 2: the following message received over an insecure connection
	connection
	OPTIONS * HTTP/1.1		OPTIONS * HTTP/1.1
	Host: www.example.org		Host: www.example.org:8080
	has an effective request URI of		has a target URI of
	https://www.example.org		http://www.example.org:8080
	Recipients of an HTTP/1.0 request that lacks a Host header field		If the target URI's authority component is empty and its URI scheme
	might need to use heuristics (e.g., examination of the URI path for		requires a non-empty authority (as is the case for "http" and
	something unique to a particular host) in order to guess the		"https"), the server can reject the request or determine whether a
	effective request URI's authority component.		configured default applies that is consistent with the incoming
			connection's context. Context might include connection details like
			address and port, what security has been applied, and locally-defined
			information specific to that server's configuration. An empty
			authority is replaced with the configured default before further
			processing of the request.
	[new]		Supplying a default name for authority within the context of a
			secured connection is inherently unsafe if there is any chance that
			the user agent's intended authority might differ from the default. A
			server that can uniquely identify an authority from the request
			context MAY use that identity as a default without this risk.
			Alternatively, it might be better to redirect the request to a safe
			resource that explains how to obtain a new client.
	[new]		Note that reconstructing the client's target URI is only half of the
			process for identifying a target resource. The other half is
			determining whether that target URI identifies a resource for which
			the server is willing and able to send a response, as defined in
			Section 7.4 of [HTTP].
	4. Status Line		4. Status Line
	The first line of a response message is the status-line, consisting		The first line of a response message is the status-line, consisting
	of the protocol version, a space (SP), the status code, another		of the protocol version, a space (SP), the status code, another
	space, a possibly empty textual phrase describing the status code,		space, and ending with an OPTIONAL textual phrase describing the
	and ending with CRLF.		status code.
	status-line = HTTP-version SP status-code SP reason-phrase CRLF		status-line = HTTP-version SP status-code SP [reason-phrase]
	Although the request-line and status-line grammar rules require that		Although the status-line grammar rule requires that each of the
	each of the component elements be separated by a single SP octet,		component elements be separated by a single SP octet, recipients MAY
	recipients MAY instead parse on whitespace-delimited word boundaries		instead parse on whitespace-delimited word boundaries and, aside from
	and, aside from the CRLF terminator, treat any form of whitespace as		the line terminator, treat any form of whitespace as the SP separator
	the SP separator while ignoring preceding or trailing whitespace;		while ignoring preceding or trailing whitespace; such whitespace
	such whitespace includes one or more of the following octets: SP,		includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
	HTAB, VT (%x0B), FF (%x0C), or bare CR. However, lenient parsing can		(%x0C), or bare CR. However, lenient parsing can result in response
	result in security vulnerabilities if there are multiple recipients		splitting security vulnerabilities if there are multiple recipients
	of the message and each has its own unique interpretation of		of the message and each has its own unique interpretation of
	robustness (see Section 9.5).		robustness (see Section 11.1).
	The status-code element is a 3-digit integer code describing the		The status-code element is a 3-digit integer code describing the
	result of the server's attempt to understand and satisfy the client's		result of the server's attempt to understand and satisfy the client's
	corresponding request. The rest of the response message is to be		corresponding request. A recipient parses and interprets the
	interpreted in light of the semantics defined for that status code.		remainder of the response message in light of the semantics defined
	See Section 6 of [RFC7231] for information about the semantics of		for that status code, if the status code is recognized by that
	status codes, including the classes of status code (indicated by the		recipient, or in accordance with the class of that status code when
	first digit), the status codes defined by this specification,		the specific code is unrecognized.
	considerations for the definition of new status codes, and the IANA
	registry.
	status-code = 3DIGIT		status-code = 3DIGIT
			HTTP's core status codes are defined in Section 15 of [HTTP], along
			with the classes of status codes, considerations for the definition
			of new status codes, and the IANA registry for collecting such
			definitions.
	The reason-phrase element exists for the sole purpose of providing a		The reason-phrase element exists for the sole purpose of providing a
	textual description associated with the numeric status code, mostly		textual description associated with the numeric status code, mostly
	out of deference to earlier Internet application protocols that were		out of deference to earlier Internet application protocols that were
	more frequently used with interactive text clients. A client SHOULD		more frequently used with interactive text clients.
	ignore the reason-phrase content.
	reason-phrase = *( HTAB / SP / VCHAR / obs-text )		reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
			A client SHOULD ignore the reason-phrase content because it is not a
			reliable channel for information (it might be translated for a given
			locale, overwritten by intermediaries, or discarded when the message
			is forwarded via other versions of HTTP). A server MUST send the
			space that separates status-code from the reason-phrase even when the
			reason-phrase is absent (i.e., the status-line would end with the
			three octets SP CR LF).
	5. Field Syntax		5. Field Syntax
	Each header field consists of a case-insensitive field name followed		Each field line consists of a case-insensitive field name followed by
	by a colon (":"), optional leading whitespace, the field value, and		a colon (":"), optional leading whitespace, the field line value, and
	optional trailing whitespace.		optional trailing whitespace.
	header-field = field-name ":" OWS field-value OWS		field-line = field-name ":" OWS field-value OWS
	[new]		Most HTTP field names and the rules for parsing within field values
			are defined in Section 6.3 of [HTTP]. This section covers the
			generic syntax for header field inclusion within, and extraction
			from, HTTP/1.1 messages.
	5.1. Field 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 header field names. The contents within a given field		individual field names. The contents within a given field line value
	value are not parsed until a later stage of message interpretation		are not parsed until a later stage of message interpretation (usually
	(usually after the message's entire header section has been		after the message's entire field section has been processed).
	processed).
	No whitespace is allowed between the header field-name and colon. In		No whitespace is allowed between the field name and colon. In the
	the past, differences in the handling of such whitespace have led to		past, differences in the handling of such whitespace have led to
	security vulnerabilities in request routing and response handling. A		security vulnerabilities in request routing and response handling. A
	server MUST reject any received request message that contains		server MUST reject, with a response status code of 400 (Bad Request),
	whitespace between a header field-name and colon with a response code		any received request message that contains whitespace between a
	of 400 (Bad Request). A proxy MUST remove any such whitespace from a		header field name and colon. A proxy MUST remove any such whitespace
	response message before forwarding the message downstream.		from a response message before forwarding the message downstream.
	A field value might be preceded and/or followed by optional		A field line value might be preceded and/or followed by optional
	whitespace (OWS); a single SP preceding the field-value is preferred		whitespace (OWS); a single SP preceding the field line value is
	for consistent readability by humans. The field value does not		preferred for consistent readability by humans. The field line value
	include any leading or trailing whitespace: OWS occurring before the		does not include that leading or trailing whitespace: OWS occurring
	first non-whitespace octet of the field value or after the last		before the first non-whitespace octet of the field line value, or
	non-whitespace octet of the field value ought to be excluded by		after the last non-whitespace octet of the field line value, is
	parsers when extracting the field value from a header field.		excluded by parsers when extracting the field line value from a field
			line.
	5.2. Obsolete Line Folding		5.2. Obsolete Line Folding
	Historically, HTTP header field values could be extended over		Historically, HTTP/1.x field values could be extended over multiple
	multiple lines by preceding each extra line with at least one space		lines by preceding each extra line with at least one space or
	or horizontal tab (obs-fold). This specification deprecates such		horizontal tab (obs-fold). This specification deprecates such line
	line folding except within the message/http media type		folding except within the message/http media type (Section 10.1).
	(Section 8.3.1).
	obs-fold = CRLF 1*( SP / HTAB )		obs-fold = OWS CRLF RWS
	; obsolete line folding		; obsolete line folding
	; see Section 3.2.4
	A sender MUST NOT generate a message that includes		A sender MUST NOT generate a message that includes line folding
	line folding (i.e., that has any field-value that contains a match to		(i.e., that has any field line value that contains a match to the
	the obs-fold rule) unless the message is intended for packaging		obs-fold rule) unless the message is intended for packaging within
	within the message/http media type.		the message/http media type.
	A server that receives an obs-fold in a request message that is not		A server that receives an obs-fold in a request message that is not
	within a message/http container MUST either reject the message by		within a message/http container MUST either reject the message by
	sending a 400 (Bad Request), preferably with a representation		sending a 400 (Bad Request), preferably with a representation
	explaining that obsolete line folding is unacceptable, or replace		explaining that obsolete line folding is unacceptable, or replace
	each received obs-fold with one or more SP octets prior to		each received obs-fold with one or more SP octets prior to
	interpreting the field value or forwarding the message downstream.		interpreting the field value or forwarding the message downstream.
	A proxy or gateway that receives an obs-fold in a response message		A proxy or gateway that receives an obs-fold in a response message
	that is not within a message/http container MUST either discard the		that is not within a message/http container MUST either discard the
	skipping to change at line 766 ¶		skipping to change at page 17, line 45 ¶
	octets prior to interpreting the field value or forwarding the		octets prior to interpreting the field value or forwarding the
	message downstream.		message downstream.
	A user agent that receives an obs-fold in a response message that is		A user agent that receives an obs-fold in a response message that is
	not within a message/http container MUST replace each received		not within a message/http container MUST replace each received
	obs-fold with one or more SP octets prior to interpreting the field		obs-fold with one or more SP octets prior to interpreting the field
	value.		value.
	6. Message Body		6. Message Body
	The message body (if any) of an HTTP message is used to carry the		The message body (if any) of an HTTP/1.1 message is used to carry
	payload body of that request or response. The message body is		content (Section 6.4 of [HTTP]) for the request or response. The
	identical to the payload body unless a transfer coding has been		message body is identical to the content unless a transfer coding has
	applied, as described in Section 3.3.1.		been applied, as described in Section 6.1.
	message-body = *OCTET		message-body = *OCTET
	The rules for when a message body is allowed in a message differ for		The rules for determining when a message body is present in an
	requests and responses.		HTTP/1.1 message differ for requests and responses.
	The presence of a message body in a request is signaled by a		The presence of a message body in a request is signaled by a
	Content-Length or Transfer-Encoding header field. Request message		Content-Length or Transfer-Encoding header field. Request message
	framing is independent of method semantics, even if the method does		framing is independent of method semantics.
	not define any use for a message body.
	The presence of a message body in a response depends on both the		The presence of a message body in a response depends on both the
	request method to which it is responding and the response status code		request method to which it is responding and the response status code
	(Section 3.1.2).		(Section 4), and corresponds to when content is allowed; see
			Section 6.4 of [HTTP].
	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 content in order to form the message body.
	body. Transfer codings are defined in Section 4.		Transfer codings are defined in Section 7.
	Transfer-Encoding = 1#transfer-coding		Transfer-Encoding = #transfer-coding
			; defined in [HTTP], Section 10.1.4
	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 dynamically generated content. It also serves to distinguish
	encodings that are only applied for transport efficiency or security		encodings that are only applied in transit from the encodings that
	from those that are characteristics of the selected resource.		are a characteristic of the selected representation.
	A recipient MUST be able to parse the chunked transfer coding		A recipient MUST be able to parse the chunked transfer coding
	(Section 4.1) because it plays a crucial role in framing messages		(Section 7.1) because it plays a crucial role in framing messages
	when the payload body size is not known in advance. A sender MUST		when the content size is not known in advance. A sender MUST NOT
	NOT apply chunked more than once to a message body (i.e., chunking an		apply the chunked transfer coding more than once to a message body
	already chunked message is not allowed). If any transfer coding		(i.e., chunking an already chunked message is not allowed). If any
	other than chunked is applied to a request payload body, the sender		transfer coding other than chunked is applied to a request's content,
	MUST apply chunked as the final transfer coding to ensure that the		the sender MUST apply chunked as the final transfer coding to ensure
	message is properly framed. If any transfer coding other than		that the message is properly framed. If any transfer coding other
	chunked is applied to a response payload body, the sender MUST either		than chunked is applied to a response's content, the sender MUST
	apply chunked as the final transfer coding or terminate the message		either apply chunked as the final transfer coding or terminate the
	by closing the connection.		message by closing the connection.
	For example,		For example,
	Transfer-Encoding: gzip, chunked		Transfer-Encoding: gzip, chunked
			indicates that the content has been compressed using the gzip coding
	indicates that the payload body has been compressed using the gzip		and then chunked using the chunked coding while forming the message
	coding and then chunked using the chunked coding while forming the		body.
	message body.
	Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]),		Unlike Content-Encoding (Section 8.4.1 of [HTTP]), Transfer-Encoding
	Transfer-Encoding is a property of the message, not of the		is a property of the message, not of the representation, and any
	representation, and any recipient along the request/response chain		recipient along the request/response chain MAY decode the received
	MAY decode the received transfer coding(s) or apply additional		transfer coding(s) or apply additional transfer coding(s) to the
	transfer coding(s) to the message body, assuming that corresponding		message body, assuming that corresponding changes are made to the
	changes are made to the Transfer-Encoding field-value. Additional		Transfer-Encoding field value. Additional information about the
	information about the encoding parameters can be provided by other		encoding parameters can be provided by other header fields not
	header fields not defined by this specification.		defined by this specification.
	Transfer-Encoding MAY be sent in a response to a HEAD request or in a		Transfer-Encoding MAY be sent in a response to a HEAD request or in a
	304 (Not Modified) response (Section 4.1 of [RFC7232]) to a GET		304 (Not Modified) response (Section 15.4.5 of [HTTP]) to a GET
	request, neither of which includes a message body, to indicate that		request, neither of which includes a message body, to indicate that
	the origin server would have applied a transfer coding to the message		the origin server would have applied a transfer coding to the message
	body if the request had been an unconditional GET. This indication		body if the request had been an unconditional GET. This indication
	is not required, however, because any recipient on the response chain		is not required, however, because any recipient on the response chain
	(including the origin server) can remove transfer codings when they		(including the origin server) can remove transfer codings when they
	are not needed.		are not needed.
	A server MUST NOT send a Transfer-Encoding header field in any		A server MUST NOT send a Transfer-Encoding header field in any
	response with a status code of 1xx (Informational) or 204 (No		response with a status code of 1xx (Informational) or 204 (No
	Content). A server MUST NOT send a Transfer-Encoding header field in		Content). A server MUST NOT send a Transfer-Encoding header field in
	any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of		any 2xx (Successful) response to a CONNECT request (Section 9.3.6 of
	[RFC7231]).		[HTTP]).
			A server that receives a request message with a transfer coding it
			does not understand SHOULD respond with 501 (Not Implemented).
	Transfer-Encoding was added in HTTP/1.1. It is generally assumed		Transfer-Encoding was added in HTTP/1.1. It is generally assumed
	that implementations advertising only HTTP/1.0 support will not		that implementations advertising only HTTP/1.0 support will not
	understand how to process a transfer-encoded payload. A client MUST		understand how to process transfer-encoded content, and that an
	NOT send a request containing Transfer-Encoding unless it knows the		HTTP/1.0 message received with a Transfer-Encoding is likely to have
	server will handle HTTP/1.1 (or later) requests; such knowledge might		been forwarded without proper handling of the chunked encoding in
	be in the form of specific user configuration or by remembering the		transit.
	version of a prior received response. A server MUST NOT send a
	response containing Transfer-Encoding unless the corresponding
	request indicates HTTP/1.1 (or later).
	A server that receives a request message with a transfer coding it		A client MUST NOT send a request containing Transfer-Encoding unless
	does not understand SHOULD respond with 501 (Not Implemented).		it knows the server will handle HTTP/1.1 requests (or later minor
			revisions); such knowledge might be in the form of specific user
			configuration or by remembering the version of a prior received
			response. A server MUST NOT send a response containing Transfer-
			Encoding unless the corresponding request indicates HTTP/1.1 (or
			later minor revisions).
			Early implementations of Transfer-Encoding would occasionally send
			both a chunked encoding for message framing and an estimated Content-
			Length header field for use by progress bars. This is why Transfer-
			Encoding is defined as overriding Content-Length, as opposed to them
			being mutually incompatible. Unfortunately, forwarding such a
			message can lead to vulnerabilities regarding request smuggling
			(Section 11.2) or response splitting (Section 11.1) attacks if any
			downstream recipient fails to parse the message according to this
			specification, particularly when a downstream recipient only
			implements HTTP/1.0.
			A server MAY reject a request that contains both Content-Length and
			Transfer-Encoding or process such a request in accordance with the
			Transfer-Encoding alone. Regardless, the server MUST close the
			connection after responding to such a request to avoid the potential
			attacks.
			A server or client that receives an HTTP/1.0 message containing a
			Transfer-Encoding header field MUST treat the message as if the
			framing is faulty, even if a Content-Length is present, and close the
			connection after processing the message. The message sender might
			have retained a portion of the message, in buffer, that could be
			misinterpreted by further use of the connection.
	6.2. Content-Length		6.2. Content-Length
	When a message does not have a Transfer-Encoding header field, a		When a message does not have a Transfer-Encoding header field, a
	Content-Length header field can provide the anticipated size, as a		Content-Length header field (Section 8.6 of [HTTP]) can provide the
	decimal number of octets, for a potential payload body. For messages		anticipated size, as a decimal number of octets, for potential
	that do include a payload body, the Content-Length field-value		content. For messages that do include content, the Content-Length
	provides the framing information necessary for determining where the		field value provides the framing information necessary for
	body (and message) ends. For messages that do not include a payload		determining where the data (and message) ends. For messages that do
	body, the Content-Length indicates the size of the selected		not include content, the Content-Length indicates the size of the
	representation (Section 3 of [RFC7231]).		selected representation (Section 8.6 of [HTTP]).
	Note: HTTP's use of Content-Length for message framing differs		A sender MUST NOT send a Content-Length header field in any message
	significantly from the same field's use in MIME, where it is an		that contains a Transfer-Encoding header field.
	optional field used only within the "message/external-body"
	media-type.		| *Note:* HTTP's use of Content-Length for message framing
			| differs significantly from the same field's use in MIME, where
			| it is an optional field used only within the "message/external-
			| body" media-type.
	6.3. Message Body Length		6.3. Message Body Length
	The length of a message body is determined by one of the following		The length of a message body is determined by one of the following
	(in order of precedence):		(in order of precedence):
	1. Any response to a HEAD request and any response with a 1xx		1. Any response to a HEAD request and any response with a 1xx
	(Informational), 204 (No Content), or 304 (Not Modified) status		(Informational), 204 (No Content), or 304 (Not Modified) status
	code is always terminated by the first empty line after the		code is always terminated by the first empty line after the
	header fields, regardless of the header fields present in the		header fields, regardless of the header fields present in the
	message, and thus cannot contain a message body.		message, and thus cannot contain a message body or trailer
			section.
	2. Any 2xx (Successful) response to a CONNECT request implies that		2. Any 2xx (Successful) response to a CONNECT request implies that
	the connection will become a tunnel immediately after the empty		the connection will become a tunnel immediately after the empty
	line that concludes the header fields. A client MUST ignore any		line that concludes the header fields. A client MUST ignore any
	Content-Length or Transfer-Encoding header fields received in		Content-Length or Transfer-Encoding header fields received in
	such a message.		such a message.
	3. If a message is received with both a Transfer-Encoding and a		3. If a message is received with both a Transfer-Encoding and a
	Content-Length header field, the Transfer-Encoding overrides the		Content-Length header field, the Transfer-Encoding overrides the
	Content-Length. Such a message might indicate an attempt to		Content-Length. Such a message might indicate an attempt to
	perform request smuggling (Section 9.5) or response splitting		perform request smuggling (Section 11.2) or response splitting
	(Section 9.4) and ought to be handled as an error. A sender MUST		(Section 11.1) and ought to be handled as an error. An
	remove the received Content-Length field prior to forwarding such		intermediary that chooses to forward the message MUST first
	a message downstream.		remove the received Content-Length field and process the
			Transfer-Encoding (as described below) prior to forwarding the
			message downstream.
	4. If a Transfer-Encoding header field is present and the chunked		4. If a Transfer-Encoding header field is present and the chunked
	transfer coding (Section 4.1) is the final encoding, the message		transfer coding (Section 7.1) is the final encoding, the message
	body length is determined by reading and decoding the chunked		body length is determined by reading and decoding the chunked
	data until the transfer coding indicates the data is complete.		data until the transfer coding indicates the data is complete.
	If a Transfer-Encoding header field is present in a response and		If a Transfer-Encoding header field is present in a response and
	the chunked transfer coding is not the final encoding, the		the chunked transfer coding is not the final encoding, the
	message body length is determined by reading the connection until		message body length is determined by reading the connection until
	it is closed by the server.		it is closed by the server.
	If a Transfer-Encoding header field is present in a request and		If a Transfer-Encoding header field is present in a request and
	the chunked transfer coding is not the final encoding, the		the chunked transfer coding is not the final encoding, the
	message body length cannot be determined reliably; the server		message body length cannot be determined reliably; the server
	MUST respond with the 400 (Bad Request) status code and then		MUST respond with the 400 (Bad Request) status code and then
	close the connection.		close the connection.
	5. If a message is received without Transfer-Encoding and with		5. If a message is received without Transfer-Encoding and with an
	either multiple Content-Length header fields having differing		invalid Content-Length header field, then the message framing is
	field-values or a single Content-Length header field having an		invalid and the recipient MUST treat it as an unrecoverable
	invalid value, then the message framing is invalid and the		error, unless the field value can be successfully parsed as a
	recipient MUST treat it as an unrecoverable error. If this is a		comma-separated list (Section 5.6.1 of [HTTP]), all values in the
			list are valid, and all values in the list are the same (in which
			case the message is processed with that single value used as the
			Content-Length field value). If the unrecoverable error is in a
	request message, the server MUST respond with a 400 (Bad Request)		request message, the server MUST respond with a 400 (Bad Request)
	status code and then close the connection. If this is a response		status code and then close the connection. If it is in a
	message received by a proxy, the proxy MUST close the connection		response message received by a proxy, the proxy MUST close the
	to the server, discard the received response, and send a 502 (Bad		connection to the server, discard the received response, and send
	Gateway) response to the client. If this is a response message		a 502 (Bad Gateway) response to the client. If it is in a
	received by a user agent, the user agent MUST close the		response message received by a user agent, the user agent MUST
	connection to the server and discard the received response.		close the connection to the server and discard the received
			response.
	6. If a valid Content-Length header field is present without		6. If a valid Content-Length header field is present without
	Transfer-Encoding, its decimal value defines the expected message		Transfer-Encoding, its decimal value defines the expected message
	body length in octets. If the sender closes the connection or		body length in octets. If the sender closes the connection or
	the recipient times out before the indicated number of octets are		the recipient times out before the indicated number of octets are
	received, the recipient MUST consider the message to be		received, the recipient MUST consider the message to be
	incomplete and close the connection.		incomplete and close the connection.
	7. If this is a request message and none of the above are true, then		7. 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).
	8. Otherwise, this is a response message without a declared message		8. 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,		Since there is no way to distinguish a successfully completed, close-
	close-delimited message from a partially received message interrupted		delimited response message from a partially received message
	by network failure, a server SHOULD generate encoding or		interrupted by network failure, a server SHOULD generate encoding or
	length-delimited messages whenever possible. The close-delimiting		length-delimited messages whenever possible. The close-delimiting
	feature 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.
	This is typically because such services are implemented via a gateway		This is typically because such services are implemented via a gateway
	that requires a content-length in advance of being called and the		that requires a content-length in advance of being called and the
	server is unable or unwilling to buffer the entire request before		server is unable or unwilling to buffer the entire request before
	processing.		processing.
	A user agent that sends a request containing a message body MUST send		A user agent that sends a request that contains a message body MUST
	a valid Content-Length header field if it does not know the server		send either a valid Content-Length header field or use the chunked
	will handle HTTP/1.1 (or later) requests; such knowledge can be in		transfer coding. A client MUST NOT use the chunked transfer encoding
	the form of specific user configuration or by remembering the version		unless it knows the server will handle HTTP/1.1 (or later) requests;
	of a prior received response.		such knowledge can be in the form of specific user configuration or
			by remembering the version of a prior received response.
	If the final response to the last request on a connection has been		If the final response to the last request on a connection has been
	completely received and there remains additional data to read, a user		completely received and there remains additional data to read, a user
	agent MAY discard the remaining data or attempt to determine if that		agent MAY discard the remaining data or attempt to determine if that
	data belongs as part of the prior response body, which might be the		data belongs as part of the prior message body, which might be the
	case if the prior message's Content-Length value is incorrect. A		case if the prior message's Content-Length value is incorrect. A
	client MUST NOT process, cache, or forward such extra data as a		client MUST NOT process, cache, or forward such extra data as a
	separate response, since such behavior would be vulnerable to cache		separate response, since such behavior would be vulnerable to cache
	poisoning.		poisoning.
	7. Transfer Codings		7. Transfer Codings
	Transfer coding names are used to indicate an encoding transformation		Transfer coding names are used to indicate an encoding transformation
	that has been, can be, or might need to be applied to a payload body		that has been, can be, or might need to be applied to a message's
	in order to ensure "safe transport" through the network. This		content in order to ensure "safe transport" through the network.
	differs from a content coding in that the transfer coding is a		This differs from a content coding in that the transfer coding is a
	property of the message rather than a property of the representation		property of the message rather than a property of the representation
	that is being transferred.		that is being transferred.
	transfer-coding = "chunked" ; Section 4.1
	/ "compress" ; Section 4.2.1
	/ "deflate" ; Section 4.2.2
	/ "gzip" ; Section 4.2.3
	/ transfer-extension
	transfer-extension = token *( OWS ";" OWS transfer-parameter )
	Parameters are in the form of a name or name=value pair.
	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 8.4. They are used in the TE (Section 4.3) and		Section 7.3. They are used in the Transfer-Encoding (Section 6.1)
	Transfer-Encoding (Section 3.3.1) header fields.		and TE (Section 10.1.4 of [HTTP]) header fields (the latter also
			defining the "transfer-coding" grammar).
	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 content in order to transfer it as
	transfer it as a series of chunks, each with its own size indicator,		a series of chunks, each with its own size indicator, followed by an
	followed by an OPTIONAL trailer containing header fields. Chunked		OPTIONAL trailer section containing trailer fields. Chunked enables
	enables content streams of unknown size to be transferred as a		content streams of unknown size to be transferred as a sequence of
	sequence of length-delimited buffers, which enables the sender to		length-delimited buffers, which enables the sender to retain
	retain connection persistence and the recipient to know when it has		connection persistence and the recipient to know when it has received
	received the entire message.		the entire message.
	chunked-body = *chunk		chunked-body = *chunk
	last-chunk		last-chunk
	trailer-part		trailer-section
	CRLF		CRLF
	chunk = chunk-size [ chunk-ext ] CRLF		chunk = chunk-size [ chunk-ext ] CRLF
	chunk-data CRLF		chunk-data CRLF
	chunk-size = 1*HEXDIG		chunk-size = 1*HEXDIG
	last-chunk = 1*("0") [ chunk-ext ] CRLF		last-chunk = 1*("0") [ chunk-ext ] CRLF
	chunk-data = 1*OCTET ; a sequence of chunk-size octets		chunk-data = 1*OCTET ; a sequence of chunk-size octets
	The chunk-size field is a string of hex digits indicating the size of		The chunk-size field is a string of hex digits indicating the size of
	the chunk-data in octets. The chunked transfer coding is complete		the chunk-data in octets. The chunked transfer coding is complete
	when a chunk with a chunk-size of zero is received, possibly followed		when a chunk with a chunk-size of zero is received, possibly followed
	by a trailer, and finally terminated by an empty line.		by a trailer section, and finally terminated by an empty line.
	A recipient MUST be able to parse and decode the chunked transfer		A recipient MUST be able to parse and decode the chunked transfer
	coding.		coding.
			HTTP/1.1 does not define any means to limit the size of a chunked
			response such that an intermediary can be assured of buffering the
			entire response. Additionally, very large chunk sizes may cause
			overflows or loss of precision if their values are not represented
			accurately in a receiving implementation. Therefore, recipients MUST
			anticipate potentially large hexadecimal numerals and prevent parsing
			errors due to integer conversion overflows or precision loss due to
			integer representation.
			The chunked encoding does not define any parameters. Their presence
			SHOULD be treated as an error.
	7.1.1. Chunk Extensions		7.1.1. Chunk Extensions
	The chunked encoding allows each chunk to include zero or more chunk		The chunked encoding allows each chunk to include zero or more chunk
	extensions, immediately following the chunk-size, for the sake of		extensions, immediately following the chunk-size, for the sake of
	supplying per-chunk metadata (such as a signature or hash),		supplying per-chunk metadata (such as a signature or hash), mid-
	mid-message control information, or randomization of message body		message control information, or randomization of message body size.
	size.
	chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )		chunk-ext = *( BWS ";" BWS chunk-ext-name
			[ BWS "=" BWS chunk-ext-val ] )
	chunk-ext-name = token		chunk-ext-name = token
	chunk-ext-val = token / quoted-string		chunk-ext-val = token / quoted-string
	The chunked encoding is specific to each connection and is likely to		The chunked encoding is specific to each connection and is likely to
	be removed or recoded by each recipient (including intermediaries)		be removed or recoded by each recipient (including intermediaries)
	before any higher-level application would have a chance to inspect		before any higher-level application would have a chance to inspect
	the extensions. Hence, use of chunk extensions is generally limited		the extensions. Hence, use of chunk extensions is generally limited
	to specialized HTTP services such as "long polling" (where client and		to specialized HTTP services such as "long polling" (where client and
	server can have shared expectations regarding the use of chunk		server can have shared expectations regarding the use of chunk
	extensions) or for padding within an end-to-end secured connection.		extensions) or for padding within an end-to-end secured connection.
	A recipient MUST ignore unrecognized chunk extensions. A server		A recipient MUST ignore unrecognized chunk extensions. A server
	ought to limit the total length of chunk extensions received in a		ought to limit the total length of chunk extensions received in a
	request to an amount reasonable for the services provided, in the		request to an amount reasonable for the services provided, in the
	same way that it applies length limitations and timeouts for other		same way that it applies length limitations and timeouts for other
	parts of a message, and generate an appropriate 4xx (Client Error)		parts of a message, and generate an appropriate 4xx (Client Error)
	response if that amount is exceeded.		response if that amount is exceeded.
	7.1.2. Chunked Trailer Part		7.1.2. Chunked Trailer Section
	A trailer allows the sender to include additional fields at the end		A trailer section allows the sender to include additional fields at
	of a chunked message in order to supply metadata that might be		the end of a chunked message in order to supply metadata that might
	dynamically generated while the message body is sent, such as a		be dynamically generated while the content is sent, such as a message
	message integrity check, digital signature, or post-processing		integrity check, digital signature, or post-processing status. The
	status. The trailer fields are identical to header fields, except		proper use and limitations of trailer fields are defined in
	they are sent in a chunked trailer instead of the message's header		Section 6.5 of [HTTP].
	section.
	trailer-part = *( header-field CRLF )		trailer-section = *( field-line CRLF )
	When a chunked message containing a non-empty trailer is received,		A recipient that decodes and removes the chunked encoding from a
	the recipient MAY process the fields (aside from those forbidden		message (e.g., for storage or forwarding to a non-HTTP/1.1 peer) MUST
	above) as if they were appended to the message's header section. A		discard any received trailer fields, store/forward them separately
	recipient MUST ignore (or consider as an error) any fields that are		from the header fields, or selectively merge into the header section
	forbidden to be sent in a trailer, since processing them as if they		only those trailer fields corresponding to header field definitions
	were present in the header section might bypass external security		that are understood by the recipient to explicitly permit and define
	filters.		how their corresponding trailer field value can be safely merged.
	7.1.3. Decoding Chunked		7.1.3. Decoding Chunked
	A process for decoding the chunked transfer coding can be represented		A process for decoding the chunked transfer coding can be represented
	in pseudo-code as:		in pseudo-code as:
	length := 0		length := 0
	read chunk-size, chunk-ext (if any), and CRLF		read chunk-size, chunk-ext (if any), and CRLF
	while (chunk-size > 0) {		while (chunk-size > 0) {
	read chunk-data and CRLF		read chunk-data and CRLF
	append chunk-data to decoded-body		append chunk-data to content
	length := length + chunk-size		length := length + chunk-size
	read chunk-size, chunk-ext (if any), and CRLF		read chunk-size, chunk-ext (if any), and CRLF
	}		}
	read trailer field		read trailer field
	while (trailer field is not empty) {		while (trailer field is not empty) {
	if (trailer field is allowed to be sent in a trailer) {		if (trailer fields are stored/forwarded separately) {
	append trailer field to existing header fields		append trailer field to existing trailer fields
	}		}
	read trailer-field		else if (trailer field is understood and defined as mergeable) {
			merge trailer field with existing header fields
			}
			else {
			discard trailer field
			}
			read trailer field
	}		}
	Content-Length := length		Content-Length := length
	Remove "chunked" from Transfer-Encoding		Remove "chunked" from Transfer-Encoding
	Remove Trailer from existing header fields
	7.2. Compression Codings		7.2. Transfer Codings for Compression
	The codings defined below can be used to compress the payload of a		The following transfer coding names for compression are defined by
	message.		the same algorithm as their corresponding content coding:
			compress (and x-compress)
			See Section 8.4.1.1 of [HTTP].
			deflate
			See Section 8.4.1.2 of [HTTP].
			gzip (and x-gzip)
			See Section 8.4.1.3 of [HTTP].
			The compression codings do not define any parameters. The presence
			of parameters with any of these compression codings SHOULD be treated
			as an error.
	7.3. Transfer Coding Registry		7.3. Transfer Coding Registry
	The "HTTP Transfer Coding Registry" defines the namespace for		The "HTTP Transfer Coding Registry" defines the namespace for
	transfer coding names. It is maintained at		transfer coding names. It is maintained at
	<http://www.iana.org/assignments/http-parameters>.		<https://www.iana.org/assignments/http-parameters>.
	8.4.1. Procedure
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Name		* Name
	o Description		* Description
	o Pointer to specification text		* 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 3.1.2.1 of [RFC7231]) unless the encoding		codings (Section 8.4.1 of [HTTP]) unless the encoding transformation
	transformation is identical, as is the case for the compression		is identical, as is the case for the compression codings defined in
	codings defined in Section 4.2.		Section 7.2.
	Values to be added to this namespace require IETF Review (see Section		The TE header field (Section 10.1.4 of [HTTP]) uses a pseudo
	4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding		parameter named "q" as rank value when multiple transfer codings are
	defined in this specification.		acceptable. Future registrations of transfer codings SHOULD NOT
			define parameters called "q" (case-insensitively) in order to avoid
			ambiguities.
			Values to be added to this namespace require IETF Review (see
			Section 4.8 of [RFC8126]), and MUST conform to the purpose of
			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. Negotiating Transfer Codings		7.4. Negotiating Transfer Codings
			The TE field (Section 10.1.4 of [HTTP]) is used in HTTP/1.1 to
			indicate what transfer-codings, besides chunked, the client is
			willing to accept in the response, and whether the client is willing
			to preserve trailer fields in a chunked transfer coding.
			A client MUST NOT send the chunked transfer coding name in TE;
			chunked is always acceptable for HTTP/1.1 recipients.
	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, Section		(similar to the qvalues used in content negotiation fields,
	5.3.1 of [RFC7231]). The rank value is a real number in the range 0		Section 12.4.2 of [HTTP]). The rank value is a real number in the
	through 1, where 0.001 is the least preferred and 1 is the most		range 0 through 1, where 0.001 is the least preferred and 1 is the
	preferred; a value of 0 means "not acceptable".		most preferred; a value of 0 means "not acceptable".
	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 presence of the keyword "trailers" indicates that the client is		The keyword "trailers" indicates that the sender will not discard
	willing to accept trailer fields in a chunked transfer coding, as		trailer fields, as described in Section 6.5 of [HTTP].
	defined in Section 4.1.2, on behalf of itself and any downstream
	clients. For requests from an intermediary, this implies that
	either: (a) all downstream clients are willing to accept trailer
	fields in the forwarded response; or, (b) the intermediary will
	attempt to buffer the response on behalf of downstream recipients.
	Note that HTTP/1.1 does not define any means to limit the size of a
	chunked response such that an intermediary can be assured of
	buffering the entire response.
	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 6.1) in order to prevent the TE		Connection header field (Section 7.6.1 of [HTTP]) in order to prevent
	field from being forwarded by intermediaries that do not support its		the TE header 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
	incomplete. Cache requirements for incomplete responses are defined		incomplete. Cache requirements for incomplete responses are defined
	in Section 3 of [RFC7234].		in Section 3 of [CACHING].
	If a response terminates in the middle of the header section (before		If a response terminates in the middle of the header section (before
	the empty line is received) and the status code might rely on header		the empty line is received) and the status code might rely on header
	fields to convey the full meaning of the response, then the client		fields to convey the full meaning of the response, then the client
	cannot assume that meaning has been conveyed; the client might need		cannot assume that meaning has been conveyed; the client might need
	to repeat the request in order to determine what action to take next.		to repeat the request in order to determine what action to take next.
	A message body that uses the chunked transfer coding is incomplete if		A message body that uses the chunked transfer coding is incomplete if
	the zero-sized chunk that terminates the encoding has not been		the zero-sized chunk that terminates the encoding has not been
	received. A message that uses a valid Content-Length is incomplete		received. A message that uses a valid Content-Length is incomplete
	if the size of the message body received (in octets) is less than the		if the size of the message body received (in octets) is less than the
	value given by Content-Length. A response that has neither chunked		value given by Content-Length. A response that has neither chunked
	transfer coding nor Content-Length is terminated by closure of the		transfer coding nor Content-Length is terminated by closure of the
	connection and, thus, is considered complete regardless of the number		connection and, if the header section was received intact, is
	of message body octets received, provided that the header section was		considered complete unless an error was indicated by the underlying
	received intact.		connection (e.g., an "incomplete close" in TLS would leave the
			response incomplete, as described in Section 9.8).
	9. Connection Management		9. Connection Management
	HTTP messaging is independent of the underlying transport- or		HTTP messaging is independent of the underlying transport- or
	session-layer connection protocol(s). HTTP only presumes a reliable		session-layer connection protocol(s). HTTP only presumes a reliable
	transport with in-order delivery of requests and the corresponding		transport with in-order delivery of requests and the corresponding
	in-order delivery of responses. The mapping of HTTP request and		in-order delivery of responses. The mapping of HTTP request and
	response structures onto the data units of an underlying transport		response structures onto the data units of an underlying transport
	protocol is outside the scope of this specification.		protocol is outside the scope of this specification.
	As described in Section 5.2, the specific connection protocols to be		As described in Section 7.3 of [HTTP], the specific connection
	used for an HTTP interaction are determined by client configuration		protocols to be used for an HTTP interaction are determined by client
	and the target URI. For example, the "http" URI scheme		configuration and the target URI. For example, the "http" URI scheme
	(Section 2.7.1) indicates a default connection of TCP over IP, with a		(Section 4.2.1 of [HTTP]) indicates a default connection of TCP over
	default TCP port of 80, but the client might be configured to use a		IP, with a default TCP port of 80, but the client might be configured
	proxy via some other connection, port, or protocol.		to use a proxy via some other connection, port, or protocol.
	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.2. Establishment		9.1. 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 HTTP connection maps to one underlying transport
			connection.
	9.3. Associating a Response to a Request		9.2. Associating a Response to a Request
	HTTP does not include a request identifier for associating a given		HTTP/1.1 does not include a request identifier for associating a
	request message with its corresponding one or more response messages.		given request message with its corresponding one or more response
	Hence, it relies on the order of response arrival to correspond		messages. Hence, it relies on the order of response arrival to
	exactly to the order in which requests are made on the same		correspond exactly to the order in which requests are made on the
	connection. More than one response message per request only occurs		same connection. More than one response message per request only
	when one or more informational responses (1xx, see Section 6.2 of		occurs when one or more informational responses (1xx, see
	[RFC7231]) precede a final response to the same request.		Section 15.2 of [HTTP]) precede a final response to the same request.
	A client that has more than one outstanding request on a connection		A client that has more than one outstanding request on a connection
	MUST maintain a list of outstanding requests in the order sent and		MUST maintain a list of outstanding requests in the order sent and
	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		the first outstanding request that has not yet received a final (non-
	(non-1xx) response.		1xx) response.
			If a client receives data on a connection that doesn't have
			outstanding requests, the client MUST NOT consider that data to be a
			valid response; the client SHOULD close the connection, since message
			delimitation is now ambiguous, unless the data consists only of one
			or more CRLF (which can be discarded, as per Section 2.2).
	9.3. 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. HTTP implementations SHOULD support persistent
	connection will not persist after the current request/response. HTTP		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 protocol version and Connection header field
	Connection header field (if any):		(Section 7.6.1 of [HTTP]) in the most recently received message, if
			any:
	o If the "close" connection option is present, the connection will		* If the close connection option is present (Section 9.6), the
	not persist after the current response; else,		connection will not persist after the current response; else,
	o If the received protocol is HTTP/1.1 (or later), the connection		* 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		* If the received protocol is HTTP/1.0, the "keep-alive" connection
	option is present, the recipient is not a proxy, and the recipient		option is present, either the recipient is not a proxy or the
	wishes to honor the HTTP/1.0 "keep-alive" mechanism, the		message is a response, and the recipient wishes to honor the
	connection will persist after the current response; otherwise,		HTTP/1.0 "keep-alive" mechanism, the connection will persist after
			the current response; otherwise,
	o The connection will close after the current response.		* The connection will close after the current response.
	A client that does not support persistent connections MUST send the		A client that does not support persistent connections MUST send the
	"close" connection option in every request message.		close connection option in every request message.
	A server that does not support persistent connections MUST send the		A server that does not support persistent connections MUST send the
	"close" connection option in every response message that does not		close connection option in every response message that does not have
	have a 1xx (Informational) status code.		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 3.3. 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
	client MUST read the entire response message body if it intends to		client MUST read the entire response message body if it intends to
	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).
	[new]		See Appendix C.2.2 for more information on backwards compatibility
	See Appendix A.1.2 for more information on backwards compatibility
	with HTTP/1.0 clients.		with HTTP/1.0 clients.
	9.3.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.		asynchronous close events. The conditions under which a client can
			automatically retry a sequence of outstanding requests are defined in
	When an inbound connection is closed prematurely, a client MAY open a		Section 9.2.2 of [HTTP].
	new connection and automatically retransmit an aborted sequence of
	requests if all of those requests have idempotent methods (Section
	4.2.2 of [RFC7231]).
	9.3.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 4.2.1 of [RFC7231]),		parallel if they all have safe methods (Section 9.2.1 of [HTTP]), but
	but it MUST send the corresponding responses in the same order that		it MUST send the corresponding responses in the same order that the
	the requests were received.		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 6.6).		connection (see the TCP reset problem described in Section 9.6).
	Idempotent methods (Section 4.2.2 of [RFC7231]) are significant to		Idempotent methods (Section 9.2.2 of [HTTP]) 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.
	6.4. 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.
	Multiple connections are typically used to avoid the "head-of-line		Multiple connections are typically used to avoid the "head-of-line
	blocking" problem, wherein a request that takes significant		blocking" problem, wherein a request that takes significant server-
	server-side processing and/or has a large payload blocks subsequent		side processing and/or transfers very large content would block
	requests on the same connection. However, each connection consumes		subsequent requests on the same connection. However, each connection
	server resources. Furthermore, using multiple connections can cause		consumes server resources.
	undesirable side effects in congested networks.
			Furthermore, using multiple connections can cause undesirable side
			effects in congested networks. Using larger numbers of connections
			can also cause side effects in otherwise uncongested networks,
			because their aggregate and initially synchronized sending behavior
			can cause congestion that would not have been present if fewer
			parallel connections had been used.
	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.
	6.5. 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 line 1404 ¶		skipping to change at page 33, line 22 ¶
	time. For example, a client might have started to send a new request		time. For example, a client might have started to send a new request
	at the same time that the server has decided to close the "idle"		at the same time that the server has decided to close the "idle"
	connection. From the server's point of view, the connection is being		connection. From the server's point of view, the connection is being
	closed while it was idle, but from the client's point of view, a		closed while it was idle, but from the client's point of view, a
	request is in progress.		request is in progress.
	A server SHOULD sustain persistent connections, when possible, and		A server SHOULD sustain persistent connections, when possible, and
	allow the underlying transport's flow-control mechanisms to resolve		allow the underlying transport's flow-control mechanisms to resolve
	temporary overloads, rather than terminate connections with the		temporary overloads, rather than terminate connections with the
	expectation that clients will retry. The latter technique can		expectation that clients will retry. The latter technique can
	exacerbate network congestion.		exacerbate network congestion or server load.
	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.
	6.6. Tear-down		9.6. Tear-down
	The Connection header field (Section 6.1) provides a "close"		The "close" connection option is defined as a signal that the sender
	connection option that a sender SHOULD send when it wishes to close		will close this connection after completion of the response. A
	the connection after the current request/response pair.		sender SHOULD send a Connection header field (Section 7.6.1 of
			[HTTP]) containing the close connection option when it intends to
			close a connection. For example,
	A client that sends a "close" connection option MUST NOT send further		Connection: close
	requests on that connection (after the one containing "close") and
			as a request header field indicates that this is the last request
			that the client will send on this connection, while in a response the
			same field indicates that the server is going to close this
			connection after the response message is complete.
			Note that the field name "Close" is reserved, since using that name
			as a header field might conflict with the close connection option.
			A client that sends a close connection option MUST NOT send further
			requests on that connection (after the one containing the 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
	close of the connection (see below) after it sends the final response		closure of the connection (see below) after it sends the final
	to the request that contained "close". The server SHOULD send a		response to the request that contained the close connection option.
	"close" connection option in its final response on that connection.		The server SHOULD send a close connection option in its final
	The server MUST NOT process any further requests received on that		response on that connection. The server MUST NOT process any further
	connection.		requests received on that connection.
	A server that sends a "close" connection option MUST initiate a close		A server that sends a close connection option MUST initiate closure
	of the connection (see below) after it sends the response containing		of the connection (see below) after it sends the response containing
	"close". The server MUST NOT process any further requests received		the close connection option. The server MUST NOT process any further
	on that connection.		requests received on that connection.
	A client that receives a "close" connection option MUST cease sending		A client that receives a close connection option MUST cease sending
	requests on that connection and close the connection after reading		requests on that connection and close the connection after reading
	the response message containing the "close"; if additional pipelined		the response message containing the close connection option; if
	requests had been sent on the connection, the client SHOULD NOT		additional pipelined requests had been sent on the connection, the
	assume that they will be processed by the server.		client SHOULD NOT assume that they will be processed by the server.
	If a server performs an immediate close of a TCP connection, there is		If a server performs an immediate close of a TCP connection, there is
	a significant risk that the client will not be able to read the last		a significant risk that the client will not be able to read the last
	HTTP response. If the server receives additional data from the		HTTP response. If the server receives additional data from the
	client on a fully closed connection, such as another request that was		client on a fully closed connection, such as another request sent by
	sent by the client before receiving the server's response, the		the client before receiving the server's response, the server's TCP
	server's TCP stack will send a reset packet to the client;		stack will send a reset packet to the client; unfortunately, the
	unfortunately, the reset packet might erase the client's		reset packet might erase the client's unacknowledged input buffers
	unacknowledged input buffers before they can be read and interpreted		before they can be read and interpreted by the client's HTTP parser.
	by the client's HTTP parser.
	To avoid the TCP reset problem, servers typically close a connection		To avoid the TCP reset problem, servers typically close a connection
	in stages. First, the server performs a half-close by closing only		in stages. First, the server performs a half-close by closing only
	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.
	[new]		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		9.7. TLS Connection Initiation
	5.4.3. Initiating HTTP Over TLS [RFC2818]		Conceptually, HTTP/TLS is simply sending HTTP messages over a
			connection secured via TLS [TLS13].
	Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
	precisely as you would use HTTP over TCP.
	The agent acting as the HTTP client should also act as the TLS		The HTTP client also acts as the TLS client. It initiates a
	client. It should initiate a connection to the server on the		connection to the server on the appropriate port and sends the TLS
	appropriate port and then send the TLS ClientHello to begin the TLS		ClientHello to begin the TLS handshake. When the TLS handshake has
	handshake. When the TLS handshake has finished. The client may then		finished, the client may then initiate the first HTTP request. All
	initiate the first HTTP request. All HTTP data MUST be sent as TLS		HTTP data MUST be sent as TLS "application data", but is otherwise
	"application data". Normal HTTP behavior, including retained		treated like a normal connection for HTTP (including potential reuse
	connections should be followed.		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 through an
	closure alert is received, an implementation can be assured that no		exchange of closure alerts prior to closing a connection [TLS13].
	further data will be received on that connection. TLS		When a valid closure alert is received, an implementation can be
	implementations MUST initiate an exchange of closure alerts before		assured that no further data will be received on that connection.
	closing a connection. A TLS implementation MAY, after sending a
	closure alert, close the connection without waiting for the peer to
	send its closure alert, generating an "incomplete close". Note that
	an implementation which does this MAY choose to reuse the session.
	This SHOULD only be done when the application knows (typically
	through detecting HTTP message boundaries) that it has received all
	the message data that it cares about.
	As specified in [RFC2246], any implementation which receives a
	connection close without first receiving a valid closure alert (a
	"premature close") MUST NOT reuse that session. Note that a
	premature close does not call into question the security of the data
	already received, but simply indicates that subsequent data might
	have been truncated. Because TLS is oblivious to HTTP
	request/response boundaries, it is necessary to examine the HTTP data
	itself (specifically the Content-Length header) to determine whether
	the truncation occurred inside a message or between messages.
	2.2.1. Client Behavior
	Because HTTP uses connection closure to signal end of server data,
	client implementations MUST treat any premature closes as errors and
	the data received as potentially truncated. While in some cases the
	HTTP protocol allows the client to find out whether truncation took
	place so that, if it received the complete reply, it may tolerate
	such errors following the principle to "[be] strict when sending and
	tolerant when receiving" [RFC1958], often truncation does not show in
	the HTTP protocol data; two cases in particular deserve special note:
	A HTTP response without a Content-Length header. Since data length
	in this situation is signalled by connection close a premature
	close generated by the server cannot be distinguished from a
	spurious close generated by an attacker.
	A HTTP response with a valid Content-Length header closed before		When an implementation knows that it has sent or received all the
	all data has been read. Because TLS does not provide document		message data that it cares about, typically by detecting HTTP message
	oriented protection, it is impossible to determine whether the		boundaries, it might generate an "incomplete close" by sending a
	server has miscomputed the Content-Length or an attacker has		closure alert and then closing the connection without waiting to
	truncated the connection.		receive the corresponding closure alert from its peer.
	There is one exception to the above rule.		An incomplete close does not call into question the security of the
			data already received, but it could indicate that subsequent data
			might have been truncated. As TLS is not directly aware of HTTP
			message framing, it is necessary to examine the HTTP data itself to
			determine whether messages were complete. Handling of incomplete
			messages is defined in Section 8.
	When encountering a premature close, a client SHOULD treat as		When encountering an incomplete close, a client SHOULD treat as
	completed all requests for which it has received as much data as		completed all requests for which it has received as much data as
	specified in the Content-Length header.		specified in the Content-Length header or, when a Transfer-Encoding
			of chunked is used, for which the terminal zero-length chunk has been
			received. A response that has neither chunked transfer coding nor
			Content-Length is complete only if a valid closure alert has been
			received. Treating an incomplete message as complete could expose
			implementations to attack.
	A client detecting an incomplete close SHOULD recover gracefully. It		A client detecting an incomplete close SHOULD recover gracefully.
	MAY resume a TLS session closed in this fashion.
	Clients MUST send a closure alert before closing the connection.		Clients MUST send a closure alert before closing the connection.
	Clients which are unprepared to receive any more data MAY choose not		Clients that do not expect to receive any more data MAY choose not to
	to wait for the server's closure alert and simply close the		wait for the server's closure alert and simply close the connection,
	connection, thus generating an incomplete close on the server side.		thus generating an incomplete close on the server side.
	2.2.2. Server Behavior
	RFC 2616 permits an HTTP client to close the connection at any time,
	and requires servers to recover gracefully. In particular, servers
	SHOULD be prepared to receive an incomplete close from the client,
	since the client can often determine when the end of server data is.
	Servers SHOULD be willing to resume TLS sessions closed in this
	fashion.
	Implementation note: In HTTP implementations which do not use		Servers SHOULD be prepared to receive an incomplete close from the
	persistent connections, the server ordinarily expects to be able to		client, since the client can often determine when the end of server
	signal end of data by closing the connection. When Content-Length is		data is.
	used, however, the client may have already sent the closure alert and
	dropped the connection.
	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.
	X. Enclosing Messages as Data		10. Enclosing Messages as Data
	8.3.1. Internet Media Type message/http		10.1. Media Type message/http
	The message/http type can be used to enclose a single HTTP request or		The message/http media type can be used to enclose a single HTTP
	response message, provided that it obeys the MIME restrictions for		request or response message, provided that it obeys the MIME
	all "message" types regarding line length and encodings.		restrictions for all "message" types regarding line length and
			encodings. Because of the line length limitations, field values
			within message/http are allowed to use line folding (obs-fold), as
			described in Section 5.2, to convey the field value over multiple
			lines. A recipient of message/http data MUST replace any obsolete
			line folding with one or more SP characters when the message is
			consumed.
	Type name: message		Type name: message
	Subtype name: http		Subtype name: http
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: version, msgtype		Optional parameters: version, msgtype
	version: The HTTP-version number of the enclosed message (e.g.,		version: The HTTP-version number of the enclosed message (e.g.,
	"1.1"). If not present, the version can be determined from the		"1.1"). If not present, the version can be determined from the
	first line of the body.		first line of the body.
	msgtype: The message type -- "request" or "response". If not		msgtype: The message type - "request" or "response". If not
	present, the type can be determined from the first line of the		present, the type can be determined from the first line of the
	body.		body.
	Encoding considerations: only "7bit", "8bit", or "binary" are		Encoding considerations: only "7bit", "8bit", or "binary" are
	permitted		permitted
	Security considerations: see Section 9		Security considerations: see Section 11
	Interoperability considerations: N/A		Interoperability considerations: N/A
	Published specification: This specification (see Section 8.3.1).		Published specification: This specification (see Section 10.1).
	Applications that use this media type: N/A		Applications that use this media type: N/A
	Fragment identifier considerations: N/A		Fragment identifier considerations: N/A
	Additional information:		Additional information: Magic number(s): N/A
	Magic number(s): N/A
	Deprecated alias names for this type: N/A		Deprecated alias names for this type: N/A
	File extension(s): N/A		File extension(s): N/A
	Macintosh file type code(s): N/A		Macintosh file type code(s): N/A
	Person and email address to contact for further information:		Person and email address to contact for further information: See Aut
	See Authors' Addresses section.		hors' Addresses section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: N/A		Restrictions on usage: N/A
	Author: See Authors' Addresses section.		Author: See Authors' Addresses section.
	Change controller: IESG		Change controller: IESG
	8.3.2. Internet Media Type application/http		10.2. Media Type application/http
	The application/http type can be used to enclose a pipeline of one or		The application/http media type can be used to enclose a pipeline of
	more HTTP request or response messages (not intermixed).		one or more HTTP request or response messages (not intermixed).
	Type name: application		Type name: application
	Subtype name: http		Subtype name: http
	Required parameters: N/A		Required parameters: N/A
	Optional parameters: version, msgtype		Optional parameters: version, msgtype
	version: The HTTP-version number of the enclosed messages (e.g.,		version: The HTTP-version number of the enclosed messages (e.g.,
	"1.1"). If not present, the version can be determined from the		"1.1"). If not present, the version can be determined from the
	first line of the body.		first line of the body.
	msgtype: The message type -- "request" or "response". If not		msgtype: The message type - "request" or "response". If not
	present, the type can be determined from the first line of the		present, the type can be determined from the first line of the
	body.		body.
	Encoding considerations: HTTP messages enclosed by this type are in		Encoding considerations: HTTP messages enclosed by this type are in
	"binary" format; use of an appropriate Content-Transfer-Encoding		"binary" format; use of an appropriate Content-Transfer-Encoding
	is required when transmitted via email.		is required when transmitted via email.
	Security considerations: see Section 9		Security considerations: see Section 11
	Interoperability considerations: N/A		Interoperability considerations: N/A
	Published specification: This specification (see Section 8.3.2).		Published specification: This specification (see Section 10.2).
	Applications that use this media type: N/A		Applications that use this media type: N/A
	Fragment identifier considerations: N/A		Fragment identifier considerations: N/A
	Additional information:		Additional information: Deprecated alias names for this type: N/A
	Deprecated alias names for this type: N/A
	Magic number(s): N/A		Magic number(s): N/A
	File extension(s): N/A		File extension(s): N/A
	Macintosh file type code(s): N/A		Macintosh file type code(s): N/A
	Person and email address to contact for further information:		Person and email address to contact for further information: See Aut
	See Authors' Addresses section.		hors' Addresses section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: N/A		Restrictions on usage: N/A
	Author: See Authors' Addresses section.		Author: See Authors' Addresses section.
	Change controller: IESG		Change controller: IESG
	9. Security Considerations		11. Security Considerations
	This section is meant to inform developers, information providers,		This section is meant to inform developers, information providers,
	and users of known security considerations relevant to HTTP message		and users about known security considerations relevant to HTTP
	syntax, parsing, and routing. Security considerations about HTTP		message syntax and parsing. Security considerations about HTTP
	semantics and payloads are addressed in [RFC7231].		semantics, content, and routing are addressed in [HTTP].
	9.4. Response Splitting		11.1. Response Splitting
	Response splitting (a.k.a, CRLF injection) is a common technique,		Response splitting (a.k.a., CRLF injection) is a common technique,
	used in various attacks on Web usage, that exploits the line-based		used in various attacks on Web usage, that exploits the line-based
	nature of HTTP message framing and the ordered association of		nature of HTTP message framing and the ordered association of
	requests to responses on persistent connections [Klein]. This		requests to responses on persistent connections [Klein]. This
	technique can be particularly damaging when the requests pass through		technique can be particularly damaging when the requests pass through
	a shared cache.		a shared cache.
	Response splitting exploits a vulnerability in servers (usually		Response splitting exploits a vulnerability in servers (usually
	within an application server) where an attacker can send encoded data		within an application server) where an attacker can send encoded data
	within some parameter of the request that is later decoded and echoed		within some parameter of the request that is later decoded and echoed
	within any of the response header fields of the response. If the		within any of the response header fields of the response. If the
	skipping to change at line 1723 ¶		skipping to change at page 39, line 33 ¶
	However, that assumes the application server is only performing URI		However, that assumes the application server is only performing URI
	decoding, rather than more obscure data transformations like charset		decoding, rather than more obscure data transformations like charset
	transcoding, XML entity translation, base64 decoding, sprintf		transcoding, XML entity translation, base64 decoding, sprintf
	reformatting, etc. A more effective mitigation is to prevent		reformatting, etc. A more effective mitigation is to prevent
	anything other than the server's core protocol libraries from sending		anything other than the server's core protocol libraries from sending
	a CR or LF within the header section, which means restricting the		a CR or LF within the header section, which means restricting the
	output of header fields to APIs that filter for bad octets and not		output of header fields to APIs that filter for bad octets and not
	allowing application servers to write directly to the protocol		allowing application servers to write directly to the protocol
	stream.		stream.
	9.5. Request Smuggling		11.2. Request Smuggling
	Request smuggling ([Linhart]) is a technique that exploits		Request smuggling ([Linhart]) is a technique that exploits
	differences in protocol parsing among various recipients to hide		differences in protocol parsing among various recipients to hide
	additional requests (which might otherwise be blocked or disabled by		additional requests (which might otherwise be blocked or disabled by
	policy) within an apparently harmless request. Like response		policy) within an apparently harmless request. Like response
	splitting, request smuggling can lead to a variety of attacks on HTTP		splitting, request smuggling can lead to a variety of attacks on HTTP
	usage.		usage.
	This specification has introduced new requirements on request		This specification has introduced new requirements on request
	parsing, particularly with regard to message framing in		parsing, particularly with regard to message framing in Section 6.3,
	Section 3.3.3, to reduce the effectiveness of request smuggling.		to reduce the effectiveness of request smuggling.
	9.6. Message Integrity		11.3. Message Integrity
	HTTP does not define a specific mechanism for ensuring message		HTTP does not define a specific mechanism for ensuring message
	integrity, instead relying on the error-detection ability of		integrity, instead relying on the error-detection ability of
	underlying transport protocols and the use of length or		underlying transport protocols and the use of length or chunk-
	chunk-delimited framing to detect completeness. Additional integrity		delimited framing to detect completeness. Historically, the lack of
	mechanisms, such as hash functions or digital signatures applied to		a single integrity mechanism has been justified by the informal
	the content, can be selectively added to messages via extensible		nature of most HTTP communication. However, the prevalence of HTTP
	metadata header fields. Historically, the lack of a single integrity		as an information access mechanism has resulted in its increasing use
	mechanism has been justified by the informal nature of most HTTP		within environments where verification of message integrity is
	communication. However, the prevalence of HTTP as an information		crucial.
	access mechanism has resulted in its increasing use within
	environments where verification of message integrity is crucial.
	User agents are encouraged to implement configurable means for		The mechanisms provided with the "https" scheme, such as
	detecting and reporting failures of message integrity such that those		authenticated encryption, provide protection against modification of
	means can be enabled within environments for which integrity is		messages. Care is needed however to ensure that connection closure
	necessary. For example, a browser being used to view medical history		cannot be used to truncate messages (see Section 9.8). User agents
	or drug interaction information needs to indicate to the user when		might refuse to accept incomplete messages or treat them specially.
	such information is detected by the protocol to be incomplete,		For example, a browser being used to view medical history or drug
	expired, or corrupted during transfer. Such mechanisms might be		interaction information needs to indicate to the user when such
	selectively enabled via user agent extensions or the presence of		information is detected by the protocol to be incomplete, expired, or
	message integrity metadata in a response. At a minimum, user agents		corrupted during transfer. Such mechanisms might be selectively
	ought to provide some indication that allows a user to distinguish		enabled via user agent extensions or the presence of message
	between a complete and incomplete response message (Section 3.4) when		integrity metadata in a response.
	such verification is desired.
	9.7. Message Confidentiality		The "http" scheme provides no protection against accidental or
			malicious modification of messages.
			Extensions to the protocol might be used to mitigate the risk of
			unwanted modification of messages by intermediaries, even when the
			"https" scheme is used. Integrity might be assured by using message
			authentication codes or digital signatures that are selectively added
			to messages via extensible metadata fields.
			11.4. Message Confidentiality
	HTTP relies on underlying transport protocols to provide message		HTTP relies on underlying transport protocols to provide message
	confidentiality when that is desired. HTTP has been specifically		confidentiality when that is desired. HTTP has been specifically
	designed to be independent of the transport protocol, such that it		designed to be independent of the transport protocol, such that it
	can be used over many different forms of encrypted connection, with		can be used over many forms of encrypted connection, with the
	the selection of such transports being identified by the choice of		selection of such transports being identified by the choice of URI
	URI scheme or within user agent configuration.		scheme or within user agent configuration.
	The "https" scheme can be used to identify resources that require a		The "https" scheme can be used to identify resources that require a
	confidential connection, as described in Section 2.7.2.		confidential connection, as described in Section 4.2.2 of [HTTP].
	12. IANA Considerations		12. IANA Considerations
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller for the following registrations is: "IETF
	Engineering Task Force".		(iesg@ietf.org) - Internet Engineering Task Force".
	12.1. Header Field Registration
	HTTP header fields are registered within the "Message Headers"		12.1. Field Name Registration
	registry maintained at
	<http://www.iana.org/assignments/message-headers/>.
	, so the
	"Permanent Message Header Field Names" registry has been updated
	accordingly (see [BCP90])
	This document defines the following HTTP header fields.		First, introduce the new "Hypertext Transfer Protocol (HTTP) Field
			Name Registry" at <https://www.iana.org/assignments/http-fields> as
			described in Section 18.4 of [HTTP].
	+-------------------+----------+----------+---------------+		Then, please update the registry with the field names listed in the
	| Header Field Name | Protocol | Status | Reference |		table below:
	+-------------------+----------+----------+---------------+
	| MIME-Version | http | standard | Appendix A.1 |
	| Transfer-Encoding | http | standard | Section 3.3.1 |
	+-------------------+----------+----------+---------------+
	Furthermore, the header field-name "Close" has been registered as		+===================+==========+======+============+
	"reserved", since using that name as an HTTP header field might		| Field Name | Status | Ref. | Comments |
	conflict with the "close" connection option of the Connection header		+===================+==========+======+============+
	field (Section 6.1).		| Close | standard | 9.6 | (reserved) |
			+-------------------+----------+------+------------+
			| MIME-Version | standard | B.1 | |
			+-------------------+----------+------+------------+
			| Transfer-Encoding | standard | 6.1 | |
			+-------------------+----------+------+------------+
	+-------------------+----------+----------+------------+		Table 1
	| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+------------+
	| Close | http | reserved | Section 8.1 |
	+-------------------+----------+----------+------------+
	12.2. Media Type Registration		12.2. Media Type Registration
	IANA maintains the registry of Internet media types [BCP13] at		Please update the "Media Types" registry at
	<http://www.iana.org/assignments/media-types>.		<https://www.iana.org/assignments/media-types> with the registration
			information in Section 10.1 and Section 10.2 for the media types
	This document serves as the specification for the Internet media		"message/http" and "application/http", respectively.
	types "message/http" and "application/http". The following has been
	registered with IANA.
	12.3. Transfer Coding Registration		12.3. Transfer Coding Registration
	The "HTTP Transfer Coding Registry" has been updated with the		Please update the "HTTP Transfer Coding Registry" at
	registrations below:		<https://www.iana.org/assignments/http-parameters/> with the
			registration procedure of Section 7.3 and the content coding names
			summarized in the table below.
	+------------+--------------------------------------+---------------+		+============+===============================+===========+
	| Name | Description | Reference |		| Name | Description | Reference |
	+------------+--------------------------------------+---------------+		+============+===============================+===========+
	| chunked | Transfer in a series of chunks | Section 4.1 |		| chunked | Transfer in a series of | Section |
	| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |		| | chunks | 7.1 |
	| deflate | "deflate" compressed data | Section 4.2.2 |		+------------+-------------------------------+-----------+
	| | ([RFC1951]) inside the "zlib" data | |		| compress | UNIX "compress" data format | Section |
	| | format ([RFC1950]) | |		| | [Welch] | 7.2 |
	| gzip | GZIP file format [RFC1952] | Section 4.2.3 |		+------------+-------------------------------+-----------+
	| x-compress | Deprecated (alias for compress) | Section 4.2.1 |		| deflate | "deflate" compressed data | Section |
	| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |		| | ([RFC1951]) inside the "zlib" | 7.2 |
	+------------+--------------------------------------+---------------+		| | data format ([RFC1950]) | |
			+------------+-------------------------------+-----------+
			| gzip | GZIP file format [RFC1952] | Section |
			| | | 7.2 |
			+------------+-------------------------------+-----------+
			| trailers | (reserved) | Section |
			| | | 12.3 |
			+------------+-------------------------------+-----------+
			| x-compress | Deprecated (alias for | Section |
			| | compress) | 7.2 |
			+------------+-------------------------------+-----------+
			| x-gzip | Deprecated (alias for gzip) | Section |
			| | | 7.2 |
			+------------+-------------------------------+-----------+
	12.4. [new]		Table 2
	[new]		| *Note:* the coding name "trailers" is reserved because its use
			| would conflict with the keyword "trailers" in the TE header
			| field (Section 10.1.4 of [HTTP]).
	[new]		12.4. ALPN Protocol ID Registration
	[new]		Please update the "TLS Application-Layer Protocol Negotiation (ALPN)
			Protocol IDs" registry at <https://www.iana.org/assignments/tls-
			extensiontype-values/tls-extensiontype-values.xhtml> with the
			registration below:
			+==========+=============================+================+
			| Protocol | Identification Sequence | Reference |
			+==========+=============================+================+
			| HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | (this |
			| | 0x31 0x2e 0x31 ("http/1.1") | specification) |
			+----------+-----------------------------+----------------+
			Table 3
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data		[CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Format Specification version 3.3", RFC 1950, May 1996.		Ed., "HTTP Caching", Work in Progress, Internet-Draft,
			draft-ietf-httpbis-cache-18, 18 August 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
			cache-18>.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Specification version 1.3", RFC 1951, May 1996.		Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
			draft-ietf-httpbis-semantics-18, 18 August 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
			semantics-18>.
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and		[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
	G. Randers-Pehrson, "GZIP file format specification		Format Specification version 3.3", RFC 1950,
	version 4.3", RFC 1952, May 1996.		DOI 10.17487/RFC1950, May 1996,
			<https://www.rfc-editor.org/info/rfc1950>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	Requirement Levels", BCP 14, RFC 2119, March 1997.		version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
			<https://www.rfc-editor.org/info/rfc1951>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P., and
	"Uniform Resource Identifier (URI): Generic Syntax",		G. Randers-Pehrson, "GZIP file format specification
	STD 66, RFC 3986, January 2005.		version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996,
			<https://www.rfc-editor.org/info/rfc1952>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Syntax Specifications: ABNF", STD 68, RFC 5234,		Requirement Levels", BCP 14, RFC 2119,
	January 2008.		DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Transfer Protocol (HTTP/1.1): Semantics and Content",		Specifications: ABNF", STD 68, RFC 5234,
	RFC 7231, June 2014.		DOI 10.17487/RFC5234, January 2008,
			<https://www.rfc-editor.org/info/rfc5234>.
	[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
	Transfer Protocol (HTTP/1.1): Conditional Requests",		RFC 7405, DOI 10.17487/RFC7405, December 2014,
	RFC 7232, June 2014.		<https://www.rfc-editor.org/info/rfc7405>.
	[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	"Hypertext Transfer Protocol (HTTP/1.1): Range		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	Requests", RFC 7233, June 2014.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	RFC 7234, June 2014.		<https://www.rfc-editor.org/info/rfc8446>.
	[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Transfer Protocol (HTTP/1.1): Authentication",		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 7235, June 2014.		RFC 3986, DOI 10.17487/RFC3986, January 2005,
			<https://www.rfc-editor.org/info/rfc3986>.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	[Welch] Welch, T., "A Technique for High-Performance Data		[Welch] Welch, T. A., "A Technique for High-Performance Data
	Compression", IEEE Computer 17(6), June 1984.		Compression", IEEE Computer 17(6), June 1984.
	13.2. Informative References		13.2. Informative References
	[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type		[Err4667] RFC Errata, Erratum ID 4667, RFC 7230,
	Specifications and Registration Procedures", BCP 13,		<https://www.rfc-editor.org/errata/eid4667>.
	RFC 6838, January 2013.
	[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90,
	RFC 3864, September 2004.
	[ISO-8859-1] International Organization for Standardization,
	"Information technology -- 8-bit single-byte coded
	graphic character sets -- Part 1: Latin alphabet No.
	1", ISO/IEC 8859-1:1998, 1998.
	[Klein] Klein, A., "Divide and Conquer - HTTP Response
	Splitting, Web Cache Poisoning Attacks, and Related
	Topics", March 2004, <http://packetstormsecurity.com/
	papers/general/whitepaper_httpresponse.pdf>.
	[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and		[HTTP/1.0] Berners-Lee, T., Fielding, R.T., and H.F. Nielsen,
	Politics", ACM Transactions on Internet		"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
	Technology 1(2), November 2001,		DOI 10.17487/RFC1945, May 1996,
	<http://arxiv.org/abs/cs.SE/0105018>.		<https://www.rfc-editor.org/info/rfc1945>.
	[Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP		[Klein] Klein, A., "Divide and Conquer - HTTP Response Splitting,
	Request Smuggling", June 2005,		Web Cache Poisoning Attacks, and Related Topics", March
	<http://www.watchfire.com/news/whitepapers.aspx>.		2004, <https://packetstormsecurity.com/papers/general/
			whitepaper_httpresponse.pdf>.
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,		[Linhart] Linhart, C., Klein, A., Heled, R., and S. Orrin, "HTTP
	"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,		Request Smuggling", June 2005,
	May 1996.		<https://www.cgisecurity.com/lib/HTTP-Request-
			Smuggling.pdf>.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet		[RFC2045] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail
	Mail Extensions (MIME) Part One: Format of Internet		Extensions (MIME) Part One: Format of Internet Message
	Message Bodies", RFC 2045, November 1996.		Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
			<https://www.rfc-editor.org/info/rfc2045>.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		DOI 10.17487/RFC2046, November 1996,
			<https://www.rfc-editor.org/info/rfc2046>.
	[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
	Extensions) Part Three: Message Header Extensions for
	Non-ASCII Text", RFC 2047, November 1996.
	[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2049] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Five: Conformance Criteria and		Extensions (MIME) Part Five: Conformance Criteria and
	Examples", RFC 2049, November 1996.		Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
			<https://www.rfc-editor.org/info/rfc2049>.
	[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and		[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
	T. Berners-Lee, "Hypertext Transfer Protocol --		Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
	HTTP/1.1", RFC 2068, January 1997.		RFC 2068, DOI 10.17487/RFC2068, January 1997,
			<https://www.rfc-editor.org/info/rfc2068>.
	[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,		[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
	"MIME Encapsulation of Aggregate Documents, such as HTML		"MIME Encapsulation of Aggregate Documents, such as HTML
	(MHTML)", RFC 2557, March 1999.		(MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
			<https://www.rfc-editor.org/info/rfc2557>.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
	HTTP/1.1", RFC 2817, May 2000.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
	an IANA Considerations Section in RFCs", BCP 26,
	RFC 5226, May 2008.
	[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
	October 2008.		DOI 10.17487/RFC5322, October 2008,
			<https://www.rfc-editor.org/info/rfc5322>.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC7230] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
	April 2011.		Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
			RFC 7230, DOI 10.17487/RFC7230, June 2014,
			<https://www.rfc-editor.org/info/rfc7230>.
	[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Codes", RFC 6585, April 2012.		Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	Appendix A. Collected ABNF		Appendix A. Collected ABNF
	BWS = OWS		In the collected ABNF below, list rules are expanded as per
			Section 5.6.1.1 of [HTTP].
	Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
	connection-option ] )
	Content-Length = 1*DIGIT		BWS = <BWS, see [HTTP], Section 5.6.3>
	HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body		HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [
	]		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
	Host = uri-host [ ":" port ]
	OWS = *( SP / HTAB )
	RWS = 1*( SP / HTAB )
	TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]		OWS = <OWS, see [HTTP], Section 5.6.3>
	Trailer = *( "," OWS ) field-name *( OWS "," [ OWS field-name ] )
	Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
	transfer-coding ] )
	URI-reference = <URI-reference, see [RFC3986], Section 4.1>		RWS = <RWS, see [HTTP], Section 5.6.3>
	Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
	Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment		Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding
	] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS		) ]
	comment ] ) ] )
	absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>		absolute-URI = <absolute-URI, see [URI], Section 4.3>
	absolute-form = absolute-URI		absolute-form = absolute-URI
	absolute-path = 1*( "/" segment )		absolute-path = <absolute-path, see [HTTP], Section 4>
	asterisk-form = "*"		asterisk-form = "*"
	authority = <authority, see [RFC3986], Section 3.2>		authority = <authority, see [URI], Section 3.2>
	authority-form = authority		authority-form = uri-host ":" port
	chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF		chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
	chunk-data = 1*OCTET		chunk-data = 1*OCTET
	chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )		chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val
			] )
	chunk-ext-name = token		chunk-ext-name = token
	chunk-ext-val = token / quoted-string		chunk-ext-val = token / quoted-string
	chunk-size = 1*HEXDIG		chunk-size = 1*HEXDIG
	chunked-body = *chunk last-chunk trailer-part CRLF		chunked-body = *chunk last-chunk trailer-section CRLF
	comment = "(" *( ctext / quoted-pair / comment ) ")"
	connection-option = token
	ctext = HTAB / SP / %x21-27 ; '!'-'''
	/ %x2A-5B ; '*'-'['
	/ %x5D-7E ; ']'-'~'
	/ obs-text
	field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
	field-name = token
	field-value = *( field-content / obs-fold )
	field-vchar = VCHAR / obs-text
	fragment = <fragment, see [RFC3986], Section 3.5>
	header-field = field-name ":" OWS field-value OWS		field-line = field-name ":" OWS field-value OWS
	http-URI = "http://" authority path-abempty [ "?" query ] [ "#"		field-name = <field-name, see [HTTP], Section 5.1>
	fragment ]		field-value = <field-value, see [HTTP], Section 5.5>
	https-URI = "https://" authority path-abempty [ "?" query ] [ "#"
	fragment ]
	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 = CRLF 1*( SP / HTAB )		obs-fold = OWS CRLF RWS
	obs-text = %x80-FF		obs-text = <obs-text, see [HTTP], Section 5.6.4>
	origin-form = absolute-path [ "?" query ]		origin-form = absolute-path [ "?" query ]
	partial-URI = relative-part [ "?" query ]		port = <port, see [URI], Section 3.2.3>
	path-abempty = <path-abempty, see [RFC3986], Section 3.3>
	port = <port, see [RFC3986], Section 3.2.3>
	protocol = protocol-name [ "/" protocol-version ]
	protocol-name = token
	protocol-version = token
	pseudonym = token
	qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['		query = <query, see [URI], Section 3.4>
	/ %x5D-7E ; ']'-'~'		quoted-string = <quoted-string, see [HTTP], Section 5.6.4>
	/ obs-text
	query = <query, see [RFC3986], Section 3.4>
	quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
	quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
	rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )		reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
	reason-phrase = *( HTAB / SP / VCHAR / obs-text )		request-line = method SP request-target SP HTTP-version
	received-by = ( uri-host [ ":" port ] ) / pseudonym
	received-protocol = [ protocol-name "/" ] protocol-version
	relative-part = <relative-part, see [RFC3986], Section 4.2>
	request-line = method SP request-target SP HTTP-version CRLF
	request-target = origin-form / absolute-form / authority-form /		request-target = origin-form / absolute-form / authority-form /
	asterisk-form		asterisk-form
	scheme = <scheme, see [RFC3986], Section 3.1>
	segment = <segment, see [RFC3986], Section 3.3>
	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 CRLF		status-line = HTTP-version SP status-code SP [ reason-phrase ]
	t-codings = "trailers" / ( transfer-coding [ t-ranking ] )		token = <token, see [HTTP], Section 5.6.2>
	t-ranking = OWS ";" OWS "q=" rank		trailer-section = *( field-line CRLF )
	tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /		transfer-coding = <transfer-coding, see [HTTP], Section 10.1.4>
	"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
	token = 1*tchar
	trailer-part = *( header-field CRLF )
	transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
	transfer-extension
	transfer-extension = token *( OWS ";" OWS transfer-parameter )
	transfer-parameter = token BWS "=" BWS ( token / quoted-string )
	uri-host = <host, see [RFC3986], Section 3.2.2>		uri-host = <host, see [URI], 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
	Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)		Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
	[RFC2045] to allow a message body to be transmitted in an open		[RFC2045] to allow a message body to be transmitted in an open
	variety of representations and with extensible header fields.		variety of representations and with extensible fields. However, RFC
	However, RFC 2045 is focused only on email; applications of HTTP have		2045 is focused only on email; applications of HTTP have many
	many characteristics that differ from email; hence, HTTP has features		characteristics that differ from email; hence, HTTP has features that
	that differ from MIME. These differences were carefully chosen to		differ from MIME. These differences were carefully chosen to
	optimize performance over binary connections, to allow greater		optimize performance over binary connections, to allow greater
	freedom in the use of new media types, to make date comparisons		freedom in the use of new media types, to make date comparisons
	easier, and to acknowledge the practice of some early HTTP servers		easier, and to acknowledge the practice of some early HTTP servers
	and clients.		and clients.
	This appendix describes specific areas where HTTP differs from MIME.		This appendix describes specific areas where HTTP differs from MIME.
	Proxies and gateways to and from strict MIME environments need to be		Proxies and gateways to and from strict MIME environments need to be
	aware of these differences and provide the appropriate conversions		aware of these differences and provide the appropriate conversions
	where necessary.		where necessary.
	B.1. MIME-Version		B.1. MIME-Version
	HTTP is not a MIME-compliant protocol. However, messages can include		HTTP is not a MIME-compliant protocol. However, messages can include
	a single MIME-Version header field to indicate what version of the		a single MIME-Version header field to indicate what version of the
	MIME protocol was used to construct the message. Use of the		MIME protocol was used to construct the message. Use of the MIME-
	MIME-Version header field indicates that the message is in full		Version header field indicates that the message is in full
	conformance with the MIME protocol (as defined in [RFC2045]).		conformance with the MIME protocol (as defined in [RFC2045]).
	Senders are responsible for ensuring full conformance (where		Senders are responsible for ensuring full conformance (where
	possible) when exporting HTTP messages to strict MIME environments.		possible) when exporting HTTP messages to strict MIME environments.
	B.2. Conversion to Canonical Form		B.2. Conversion to Canonical Form
	MIME requires that an Internet mail body part be converted to		MIME requires that an Internet mail body part be converted to
	canonical form prior to being transferred, as described in Section 4		canonical form prior to being transferred, as described in Section 4
	of [RFC2049]. Section 3.1.1.3 of this document describes the forms		of [RFC2049], and that content with a type of "text" represent line
	allowed for subtypes of the "text" media type when transmitted over		breaks as CRLF, forbidding the use of CR or LF outside of line break
	HTTP. [RFC2046] requires that content with a type of "text"		sequences [RFC2046]. In contrast, HTTP does not care whether CRLF,
	represent line breaks as CRLF and forbids the use of CR or LF outside		bare CR, or bare LF are used to indicate a line break within content.
	of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
	indicate a line break within text content.
	A proxy or gateway from HTTP to a strict MIME environment ought to		A proxy or gateway from HTTP to a strict MIME environment ought to
	translate all line breaks within the text media types described in		translate all line breaks within text media types to the RFC 2049
	Section 3.1.1.3 of this document to the RFC 2049 canonical form of		canonical form of CRLF. Note, however, this might be complicated by
	CRLF. Note, however, this might be complicated by the presence of a		the presence of a Content-Encoding and by the fact that HTTP allows
	Content-Encoding and by the fact that HTTP allows the use of some		the use of some charsets that do not use octets 13 and 10 to
	charsets that do not use octets 13 and 10 to represent CR and LF,		represent CR and LF, respectively.
	respectively.
	Conversion will break any cryptographic checksums applied to the		Conversion will break any cryptographic checksums applied to the
	original content unless the original content is already in canonical		original content unless the original content is already in canonical
	form. Therefore, the canonical form is recommended for any content		form. Therefore, the canonical form is recommended for any content
	that uses such checksums in HTTP.		that uses such checksums in HTTP.
	B.3. Conversion of Date Formats		B.3. Conversion of Date Formats
	HTTP/1.1 uses a restricted set of date formats (Section 7.1.1.1) to		HTTP/1.1 uses a restricted set of date formats (Section 5.6.7 of
	simplify the process of date comparison. Proxies and gateways from		[HTTP]) to simplify the process of date comparison. Proxies and
	other protocols ought to ensure that any Date header field present in		gateways from other protocols ought to ensure that any Date header
	a message conforms to one of the HTTP/1.1 formats and rewrite the		field present in a message conforms to one of the HTTP/1.1 formats
	date if necessary.		and rewrite the date if necessary.
	B.4. Conversion of Content-Encoding		B.4. Conversion of Content-Encoding
	MIME does not include any concept equivalent to HTTP/1.1's		MIME does not include any concept equivalent to HTTP/1.1's Content-
	Content-Encoding header field. Since this acts as a modifier on the		Encoding header field. Since this acts as a modifier on the media
	media type, proxies and gateways from HTTP to MIME-compliant		type, proxies and gateways from HTTP to MIME-compliant protocols
	protocols ought to either change the value of the Content-Type header		ought to either change the value of the Content-Type header field or
	field or decode the representation before forwarding the message.		decode the representation before forwarding the message. (Some
	(Some experimental applications of Content-Type for Internet mail		experimental applications of Content-Type for Internet mail have used
	have used a media-type parameter of ";conversions=<content-coding>"		a media-type parameter of ";conversions=<content-coding>" to perform
	to perform a function equivalent to Content-Encoding. However, this		a function equivalent to Content-Encoding. However, this parameter
	parameter is not part of the MIME standards).		is not part of the MIME standards).
	B.5. Conversion of Content-Transfer-Encoding		B.5. Conversion of Content-Transfer-Encoding
	HTTP does not use the Content-Transfer-Encoding field of MIME.		HTTP does not use the Content-Transfer-Encoding field of MIME.
	Proxies and gateways from MIME-compliant protocols to HTTP need to		Proxies and gateways from MIME-compliant protocols to HTTP need to
	remove any Content-Transfer-Encoding prior to delivering the response		remove any Content-Transfer-Encoding prior to delivering the response
	message to an HTTP client.		message to an HTTP client.
	Proxies and gateways from HTTP to MIME-compliant protocols are		Proxies and gateways from HTTP to MIME-compliant protocols are
	responsible for ensuring that the message is in the correct format		responsible for ensuring that the message is in the correct format
	skipping to change at line 2184 ¶		skipping to change at page 48, line 52 ¶
	appropriate Content-Transfer-Encoding if doing so will improve the		appropriate Content-Transfer-Encoding if doing so will improve the
	likelihood of safe transport over the destination protocol.		likelihood of safe transport over the destination protocol.
	B.6. MHTML and Line Length Limitations		B.6. MHTML and Line Length Limitations
	HTTP implementations that share code with MHTML [RFC2557]		HTTP implementations that share code with MHTML [RFC2557]
	implementations need to be aware of MIME line length limitations.		implementations need to be aware of MIME line length limitations.
	Since HTTP does not have this limitation, HTTP does not fold long		Since HTTP does not have this limitation, HTTP does not fold long
	lines. MHTML messages being transported by HTTP follow all		lines. MHTML messages being transported by HTTP follow all
	conventions of MHTML, including line length limitations and folding,		conventions of MHTML, including line length limitations and folding,
	canonicalization, etc., since HTTP transfers message-bodies as		canonicalization, etc., since HTTP transfers message-bodies without
	payload and, aside from the "multipart/byteranges" type (Appendix A		modification and, aside from the "multipart/byteranges" type
	of [RFC7233]), does not interpret the content or any MIME header		(Section 14.6 of [HTTP]), does not interpret the content or any MIME
	lines that might be contained therein.		header lines that might be contained therein.
	Appendix C. HTTP Version History
	HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
	requirements that enable reliable implementations, adding only those
	features that can either be safely ignored by an HTTP/1.0 recipient
	or only be sent when communicating with a party advertising
	conformance with HTTP/1.1.
	HTTP/1.1 has been designed to make supporting previous versions easy.		Appendix C. Changes from previous RFCs
	A general-purpose HTTP/1.1 server ought to be able to understand any
	valid request in the format of HTTP/1.0, responding appropriately
	with an HTTP/1.1 message that only uses features understood (or
	safely ignored) by HTTP/1.0 clients. Likewise, an HTTP/1.1 client
	can be expected to understand any valid HTTP/1.0 response.
	C.1. Changes from HTTP/0.9		C.1. Changes from HTTP/0.9
	Since HTTP/0.9 did not support header fields in a request, there is		Since HTTP/0.9 did not support header fields in a request, there is
	no mechanism for it to support name-based virtual hosts (selection of		no mechanism for it to support name-based virtual hosts (selection of
	resource by inspection of the Host header field). Any server that		resource by inspection of the Host header field). Any server that
	implements name-based virtual hosts ought to disable support for		implements name-based virtual hosts ought to disable support for
	HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,		HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
	badly constructed HTTP/1.x requests caused by a client failing to		badly constructed HTTP/1.x requests caused by a client failing to
	properly encode the request-target.		properly encode the request-target.
	C.2. Changes from HTTP/1.0		C.2. Changes from HTTP/1.0
	This section summarizes major differences between versions HTTP/1.0
	and HTTP/1.1.
	C.2.1. Multihomed Web Servers		C.2.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 5.4), report an error if it is missing from an		field (Section 7.2 of [HTTP]), report an error if it is missing from
	HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among		an HTTP/1.1 request, and accept absolute URIs (Section 3.2) are among
	the most important changes defined by HTTP/1.1.		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
	complete adoption. At the time of this writing, most HTTP-based		complete adoption. At the time of this writing, most HTTP-based
	services are dependent upon the Host header field for targeting		services are dependent upon the Host header field for targeting
	requests.		requests.
	C.2.2. Keep-Alive Connections		C.2.2. Keep-Alive Connections
	In HTTP/1.0, each connection is established by the client prior to		In HTTP/1.0, each connection is established by the client prior to
	the request and closed by the server after sending the response.		the request and closed by the server after sending the response.
	However, some implementations implement the explicitly negotiated		However, some implementations implement the explicitly negotiated
	("Keep-Alive") version of persistent connections described in Section		("Keep-Alive") version of persistent connections described in
	19.7.1 of [RFC2068].		Section 19.7.1 of [RFC2068].
	Some clients and servers might wish to be compatible with these		Some clients and servers might wish to be compatible with these
	previous approaches to persistent connections, by explicitly		previous approaches to persistent connections, by explicitly
	negotiating for them with a "Connection: keep-alive" request header		negotiating for them with a "Connection: keep-alive" request header
	field. However, some experimental implementations of HTTP/1.0		field. However, some experimental implementations of HTTP/1.0
	persistent connections are faulty; for example, if an HTTP/1.0 proxy		persistent connections are faulty; for example, if an HTTP/1.0 proxy
	server doesn't understand Connection, it will erroneously forward		server doesn't understand Connection, it will erroneously forward
	that header field to the next inbound server, which would result in a		that header field to the next inbound server, which would result in a
	hung connection.		hung connection.
	One attempted solution was the introduction of a Proxy-Connection		One attempted solution was the introduction of a Proxy-Connection
	header field, targeted specifically at proxies. In practice, this		header field, targeted specifically at proxies. In practice, this
	was also unworkable, because proxies are often deployed in multiple		was also unworkable, because proxies are often deployed in multiple
	layers, bringing about the same problem discussed above.		layers, bringing about the same problem discussed above.
	As a result, clients are encouraged not to send the Proxy-Connection		As a result, clients are encouraged not to send the Proxy-Connection
	header field in any requests.		header field in any requests.
	Clients are also encouraged to consider the use of Connection:		Clients are also encouraged to consider the use of Connection: keep-
	keep-alive in requests carefully; while they can enable persistent		alive in requests carefully; while they can enable persistent
	connections with HTTP/1.0 servers, clients using them will need to		connections with HTTP/1.0 servers, clients using them will need to
	monitor the connection for "hung" requests (which indicate that the		monitor the connection for "hung" requests (which indicate that the
	client ought stop sending the header field), and this mechanism ought		client ought to stop sending the header field), and this mechanism
	not be used by clients at all when a proxy is being used.		ought not be used by clients at all when a proxy is being used.
	C.2.3. Introduction of Transfer-Encoding		C.2.3. Introduction of Transfer-Encoding
	HTTP/1.1 introduces the Transfer-Encoding header field		HTTP/1.1 introduces the Transfer-Encoding header field (Section 6.1).
	(Section 3.3.1). Transfer codings need to be decoded prior to		Transfer codings need to be decoded prior to forwarding an HTTP
	forwarding an HTTP message over a MIME-compliant protocol.		message over a MIME-compliant protocol.
	C.3. Changes from RFC 2616		C.3. Changes from RFC 7230
	[elided]		Most of the sections introducing HTTP's design goals, history,
			architecture, conformance criteria, protocol versioning, URIs,
			message routing, and header fields have been moved to [HTTP]. This
			document has been reduced to just the messaging syntax and connection
			management requirements specific to HTTP/1.1.
			Bare CRs have been prohibited outside of content. (Section 2.2)
			The ABNF definition of authority-form has changed from the more
			general authority component of a URI (in which port is optional) to
			the specific host:port format that is required by CONNECT.
			(Section 3.2.3)
			Required recipients to avoid smuggling/splitting attacks when
			processing an ambiguous message framing. (Section 6.1)
			In the ABNF for chunked extensions, re-introduced (bad) whitespace
			around ";" and "=". Whitespace was removed in [RFC7230], but that
			change was found to break existing implementations (see [Err4667]).
			(Section 7.1.1)
			Trailer field semantics now transcend the specifics of chunked
			encoding. The decoding algorithm for chunked (Section 7.1.3) has
			been updated to encourage storage/forwarding of trailer fields
			separately from the header section, to only allow merging into the
			header section if the recipient knows the corresponding field
			definition permits and defines how to merge, and otherwise to discard
			the trailer fields instead of merging. The trailer part is now
			called the trailer section to be more consistent with the header
			section and more distinct from a body part. (Section 7.1.2)
			Disallowed transfer coding parameters called "q" in order to avoid
			conflicts with the use of ranks in the TE header field.
			(Section 7.3)
	Appendix D. Change Log		Appendix D. Change Log
			This section is to be removed before publishing as an RFC.
	D.1. Between RFC7230 and draft 00		D.1. Between RFC7230 and draft 00
			The changes were purely editorial:
			* Change boilerplate and abstract to indicate the "draft" status,
			and update references to ancestor specifications.
			* Adjust historical notes.
			* Update links to sibling specifications.
			* Replace sections listing changes from RFC 2616 by new empty
			sections referring to RFC 723x.
			* Remove acknowledgements specific to RFC 723x.
			* Move "Acknowledgements" to the very end and make them unnumbered.
	D.2. Since draft-ietf-httpbis-messaging-00		D.2. Since draft-ietf-httpbis-messaging-00
			The changes in this draft are editorial, with respect to HTTP as a
			whole, to move all core HTTP semantics into [HTTP]:
			* Moved introduction, architecture, conformance, and ABNF extensions
			from RFC 7230 (Messaging) to semantics [HTTP].
			* Moved discussion of MIME differences from RFC 7231 (Semantics) to
			Appendix B since they mostly cover transforming 1.1 messages.
			* Moved all extensibility tips, registration procedures, and
			registry tables from the IANA considerations to normative
			sections, reducing the IANA considerations to just instructions
			that will be removed prior to publication as an RFC.
	D.3. Since draft-ietf-httpbis-messaging-01		D.3. Since draft-ietf-httpbis-messaging-01
			* Cite RFC 8126 instead of RFC 5226 (<https://github.com/httpwg/
			http-core/issues/75>)
			* Resolved erratum 4779, no change needed here
			(<https://github.com/httpwg/http-core/issues/87>,
			<https://www.rfc-editor.org/errata/eid4779>)
			* In Section 7, fixed prose claiming transfer parameters allow bare
			names (<https://github.com/httpwg/http-core/issues/88>,
			<https://www.rfc-editor.org/errata/eid4839>)
			* Resolved erratum 4225, no change needed here
			(<https://github.com/httpwg/http-core/issues/90>,
			<https://www.rfc-editor.org/errata/eid4225>)
			* Replace "response code" with "response status code"
			(<https://github.com/httpwg/http-core/issues/94>,
			<https://www.rfc-editor.org/errata/eid4050>)
			* In Section 9.3, clarify statement about HTTP/1.0 keep-alive
			(<https://github.com/httpwg/http-core/issues/96>,
			<https://www.rfc-editor.org/errata/eid4205>)
			* In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="
			(<https://github.com/httpwg/http-core/issues/101>,
			<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-
			editor.org/errata/eid4825>)
			* In Section 7.3, state that transfer codings should not use
			parameters named "q" (<https://github.com/httpwg/http-core/
			issues/15>, <https://www.rfc-editor.org/errata/eid4683>)
			* In Section 7, mark coding name "trailers" as reserved in the IANA
			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
			* In Section 4, explain why the reason phrase should be ignored by
			clients (<https://github.com/httpwg/http-core/issues/60>).
			* Add Section 9.2 to explain how request/response correlation is
			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
			* In Section 9.2, caution against treating data on a connection as
			part of a not-yet-issued request (<https://github.com/httpwg/http-
			core/issues/26>)
			* In Section 7, remove the predefined codings from the ABNF and make
			it generic instead (<https://github.com/httpwg/http-core/
			issues/66>)
			* Use RFC 7405 ABNF notation for case-sensitive string constants
			(<https://github.com/httpwg/http-core/issues/133>)
	D.6. Since draft-ietf-httpbis-messaging-04		D.6. Since draft-ietf-httpbis-messaging-04
			* In Section 7.8 of [HTTP], clarify that protocol-name is to be
			matched case-insensitively (<https://github.com/httpwg/http-core/
			issues/8>)
			* In Section 5.2, add leading optional whitespace to obs-fold ABNF
			(<https://github.com/httpwg/http-core/issues/19>,
			<https://www.rfc-editor.org/errata/eid4189>)
			* In Section 4, add clarifications about empty reason phrases
			(<https://github.com/httpwg/http-core/issues/197>)
			* Move discussion of retries from Section 9.3.1 into [HTTP]
			(<https://github.com/httpwg/http-core/issues/230>)
	D.7. Since draft-ietf-httpbis-messaging-05		D.7. Since draft-ietf-httpbis-messaging-05
			* In Section 7.1.2, the trailer part has been renamed the trailer
			section (for consistency with the header section) and trailers are
			no longer merged as header fields by default, but rather can be
			discarded, kept separate from header fields, or merged with header
			fields only if understood and defined as being mergeable
			(<https://github.com/httpwg/http-core/issues/16>)
			* In Section 2.1 and related Sections, move the trailing CRLF from
			the line grammars into the message format
			(<https://github.com/httpwg/http-core/issues/62>)
			* Moved Section 2.3 down (<https://github.com/httpwg/http-core/
			issues/68>)
			* In Section 7.8 of [HTTP], use 'websocket' instead of 'HTTP/2.0' in
			examples (<https://github.com/httpwg/http-core/issues/112>)
			* Move version non-specific text from Section 6 into semantics as
			"payload" (<https://github.com/httpwg/http-core/issues/159>)
			* In Section 9.8, add text from RFC 2818
			(<https://github.com/httpwg/http-core/issues/236>)
	D.8. Since draft-ietf-httpbis-messaging-06		D.8. Since draft-ietf-httpbis-messaging-06
			* In Section 12.4, update the ALPN protocol ID for HTTP/1.1
			(<https://github.com/httpwg/http-core/issues/49>)
			* In Section 5, align with updates to field terminology in semantics
			(<https://github.com/httpwg/http-core/issues/111>)
			* In Section 7.6.1 of [HTTP], clarify that new connection options
			indeed need to be registered (<https://github.com/httpwg/http-
			core/issues/285>)
			* In Section 1.1, reference RFC 8174 as well
			(<https://github.com/httpwg/http-core/issues/303>)
	D.9. Since draft-ietf-httpbis-messaging-07		D.9. Since draft-ietf-httpbis-messaging-07
			* Move TE: trailers into [HTTP] (<https://github.com/httpwg/http-
			core/issues/18>)
			* In Section 6.3, adjust requirements for handling multiple content-
			length values (<https://github.com/httpwg/http-core/issues/59>)
			* Throughout, replace "effective request URI" with "target URI"
			(<https://github.com/httpwg/http-core/issues/259>)
			* In Section 6.1, don't claim Transfer-Encoding is supported by
			HTTP/2 or later (<https://github.com/httpwg/http-core/issues/297>)
	D.10. Since draft-ietf-httpbis-messaging-08		D.10. Since draft-ietf-httpbis-messaging-08
			* In Section 2.2, disallow bare CRs (<https://github.com/httpwg/
			http-core/issues/31>)
			* Appendix A now uses the sender variant of the "#" list expansion
			(<https://github.com/httpwg/http-core/issues/192>)
			* In Section 5, adjust IANA "Close" entry for new registry format
			(<https://github.com/httpwg/http-core/issues/273>)
	D.11. Since draft-ietf-httpbis-messaging-09		D.11. Since draft-ietf-httpbis-messaging-09
			* Switch to xml2rfc v3 mode for draft generation
			(<https://github.com/httpwg/http-core/issues/394>)
	D.12. Since draft-ietf-httpbis-messaging-10		D.12. Since draft-ietf-httpbis-messaging-10
			* 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>)
			* Moved requirements specific to HTTP/1.1 from [HTTP] into
			Section 3.2 (<https://github.com/httpwg/http-core/issues/182>)
			* In Section 6.1 (Transfer-Encoding), adjust ABNF to allow empty
			lists (<https://github.com/httpwg/http-core/issues/210>)
			* In Section 9.7, add text from RFC 2818
			(<https://github.com/httpwg/http-core/issues/236>)
			* Moved definitions of "TE" and "Upgrade" into [HTTP]
			(<https://github.com/httpwg/http-core/issues/392>)
			* Moved definition of "Connection" into [HTTP]
			(<https://github.com/httpwg/http-core/issues/407>)
	D.13. Since draft-ietf-httpbis-messaging-11		D.13. Since draft-ietf-httpbis-messaging-11
			* Move IANA Upgrade Token Registry instructions to [HTTP]
			(<https://github.com/httpwg/http-core/issues/450>)
	D.14. Since draft-ietf-httpbis-messaging-12		D.14. Since draft-ietf-httpbis-messaging-12
			* Moved content of history appendix to Semantics
			(<https://github.com/httpwg/http-core/issues/451>)
			* Moved note about "close" being reserved as field name to
			Section 9.3 (<https://github.com/httpwg/http-core/issues/500>)
			* Moved table of transfer codings into Section 12.3
			(<https://github.com/httpwg/http-core/issues/506>)
			* In Section 13.2, updated the URI for the [Linhart] paper
			(<https://github.com/httpwg/http-core/issues/517>)
			* Changed document title to just "HTTP/1.1"
			(<https://github.com/httpwg/http-core/issues/524>)
			* In Section 7, moved transfer-coding ABNF to Section 10.1.4 of
			[HTTP] (<https://github.com/httpwg/http-core/issues/531>)
			* Changed to using "payload data" when defining requirements about
			the data being conveyed within a message, instead of the terms
			"payload body" or "response body" or "representation body", since
			they often get confused with the HTTP/1.1 message body (which
			includes transfer coding) (<https://github.com/httpwg/http-core/
			issues/553>)
	D.15. Since draft-ietf-httpbis-messaging-13		D.15. Since draft-ietf-httpbis-messaging-13
			* In Section 6.3, clarify that a message needs to be checked for
			both Content-Length and Transfer-Encoding, before processing
			Transfer-Encoding, and that ought to be treated as an error, but
			an intermediary can choose to forward the message downstream after
			removing the Content-Length and processing the Transfer-Encoding
			(<https://github.com/httpwg/http-core/issues/617>)
			* Changed to using "content" instead of "payload" or "payload data"
			to avoid confusion with the payload of version-specific messaging
			frames (<https://github.com/httpwg/http-core/issues/654>)
	D.16. Since draft-ietf-httpbis-messaging-14		D.16. Since draft-ietf-httpbis-messaging-14
			* In Section 9.6, define the close connection option, since its
			definition was removed from the Connection header field for being
			specific to 1.1 (<https://github.com/httpwg/http-core/issues/678>)
			* In Section 3.3, clarify how the target URI is reconstructed when
			the request-target is not in absolute-form and highlight risk in
			selecting a default host (<https://github.com/httpwg/http-core/
			issues/722>)
			* In Section 7.1, clarify large chunk handling issues
			(<https://github.com/httpwg/http-core/issues/749>)
			* In Section 2.2, explicitly close the connection after sending a
			400 (<https://github.com/httpwg/http-core/issues/750>)
			* In Section 2.3, refine version requirements for intermediaries
			(<https://github.com/httpwg/http-core/issues/751>)
			* In Section 7.1.3, don't remove the Trailer header field
			(<https://github.com/httpwg/http-core/issues/793>)
			* In Section 3.2.3, changed the ABNF definition of authority-form
			from the authority component (in which port is optional) to the
			host:port format that has always been required by CONNECT
			(<https://github.com/httpwg/http-core/issues/806>)
	D.17. Since draft-ietf-httpbis-messaging-15		D.17. Since draft-ietf-httpbis-messaging-15
			* None.
	D.18. Since draft-ietf-httpbis-messaging-16		D.18. Since draft-ietf-httpbis-messaging-16
			This draft addresses mostly editorial issues raised during or past
			IETF Last Call; see <https://github.com/httpwg/http-core/
			issues?q=label%3Ah1-messaging+created%3A%3E2021-05-26> for a summary.
			Furthermore:
			* In Section 6.1, require recipients to avoid smuggling/splitting
			attacks when processing an ambiguous message framing
			(<https://github.com/httpwg/http-core/issues/879>)
	D.19. Since draft-ietf-httpbis-messaging-17		D.19. Since draft-ietf-httpbis-messaging-17
	Acknowledgments		* In Section 4, rephrase text about status code definitions in
			[HTTP] (<https://github.com/httpwg/http-core/issues/915>)
	This edition of HTTP/1.1 builds on the many contributions that went		* In Section 9.2, clarify how to match responses to requests
	into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including		(<https://github.com/httpwg/http-core/issues/915>)
	substantial contributions made by the previous authors, editors, and
	Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
	Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
	and Paul J. Leach. Mark Nottingham oversaw this effort as Working
	Group Chair.
	Since 1999, the following contributors have helped improve the HTTP		* Made reference to [RFC5322] normative, as it is referenced from
	specification by reporting bugs, asking smart questions, drafting or		the ABNF (for "From" header field) (<https://github.com/httpwg/
	reviewing text, and evaluating open issues:		http-core/issues/915>)
	Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrian Cole,		* In Section 5.2, include text about message/http that previously
	Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek		was in [HTTP] (<https://github.com/httpwg/http-core/issues/923>)
	Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha
	Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier,
	Andreas Petersson, Andrei Popov, Anil Sharma, Anne van Kesteren,
	Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander
	Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin
	Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern
	Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell,
	Brian McBarron, Brian Pane, Brian Raymor, Brian Smith, Bruce Perens,
	Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann,
	Charles Fry, Chris Burdess, Chris Newman, Christian Huitema, Cyrus
	Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg,
	Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, Dave
	Thaler, David Booth, David Singer, David W. Morris, Diwakar Shetty,
	Dmitry Kurochkin, Drummond Reed, Duane Wessels, Edward Lee, Eitan
	Adler, Eliot Lear, Emile Stephan, Eran Hammer-Lahav, Eric D.
	Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik
	Aronesty, EungJun Yi, Evan Prodromou, Felix Geisendoerfer, Florian
	Weimer, Frank Ellermann, Fred Akalin, Fred Bohle, Frederic Kayser,
	Gabor Molnar, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham,
	Gili Tzabari, Grahame Grieve, Greg Slepak, Greg Wilkins, Grzegorz
	Calkowski, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik
	Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel,
	Herve Ruellan, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido
	Safruti, Ilari Liusvaara, Ilya Grigorik, Ingo Struck, J. Ross Nicoll,
	James Cloos, James H. Manger, James Lacey, James M. Snell, Jamie
	Lokier, Jan Algermissen, Jari Arkko, Jeff Hodges (who came up with
	the term 'effective Request-URI'), Jeff Pinner, Jeff Walden, Jim
	Luther, Jitu Padhye, Joe D. Williams, Joe Gregorio, Joe Orton, Joel
	Jaeggli, John C. Klensin, John C. Mallery, John Cowan, John Kemp,
	John Panzer, John Schneider, John Stracke, John Sullivan, Jonas
	Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore,
	Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien
	Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin
	James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith
	Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin
	Voronkov, Kris Zyp, Leif Hedstrom, Lionel Morand, Lisa Dusseault,
	Maciej Stachowiak, Manu Sporny, Marc Schneider, Marc Slemko, Mark
	Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler,
	Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson,
	Matt Lynch, Matthew Cox, Matthew Kerwin, Max Clark, Menachem Dodge,
	Meral Shirazipour, Michael Burrows, Michael Hausenblas, Michael
	Scharf, Michael Sweet, Michael Tuexen, Michael Welzl, Mike Amundsen,
	Mike Belshe, Mike Bishop, Mike Kelly, Mike Schinkel, Miles Sabin,
	Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas
	Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater,
	Osama Mazahir, Pablo Castro, Pat Hayes, Patrick R. McManus, Paul E.
	Jones, Paul Hoffman, Paul Marquess, Pete Resnick, Peter Lepeska,
	Peter Occil, Peter Saint-Andre, Peter Watkins, Phil Archer, Phil
	Hunt, Philippe Mougin, Phillip Hallam-Baker, Piotr Dobrogost, Poul-
	Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto
	Bachmann-Gmuer, Richard Barnes, Richard Cyganiak, Rob Trace, Robby
	Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert
	O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de
	Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny
	Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam
	Johnston, Sam Pullara, Sam Ruby, Saurabh Kulkarni, Scott Lawrence
	(who maintained the original issues list), Sean B. Palmer, Sean
	Turner, Sebastien Barnoud, Shane McCarron, Shigeki Ohtsu, Simon
	Yarde, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane
	Bortzmeyer, Stephen Farrell, Stephen Kent, Stephen Ludin, Stuart
	Williams, Subbu Allamaraju, Subramanian Moonesamy, Susan Hares,
	Sylvain Hellegouarch, Tapan Divekar, Tatsuhiro Tsujikawa, Tatsuya
	Hayashi, Ted Hardie, Ted Lemon, Thomas Broyer, Thomas Fossati, Thomas
	Maslen, Thomas Nadeau, Thomas Nordin, Thomas Roessler, Tim Bray, Tim
	Morgan, Tim Olsen, Tom Zhou, Travis Snoozy, Tyler Close, Vincent
	Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez
	Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang,
	Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang,
	Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the
	editor team), Zed A. Shaw, and Zhong Yu.
	See Section 16 of [RFC2616] for additional acknowledgements from		* Throughout, disambiguate "selected representation" and "selected
	prior revisions.		response" (now "chosen response") (<https://github.com/httpwg/
			http-core/issues/958>)
			Acknowledgements
			See Appendix "Acknowledgements" of [HTTP].
			Index
			A C D F G H M O R T X
			A
			absolute-form (of request-target) Section 3.2.2
			application/http Media Type Section 10.2
			asterisk-form (of request-target) Section 3.2.4
			authority-form (of request-target) Section 3.2.3
			C
			Connection header field Section 9.6
			Content-Length header field Section 6.2
			Content-Transfer-Encoding header field Appendix B.5
			chunked (Coding Format) Section 6.1; Section 6.3
			chunked (transfer coding) Section 7.1
			close Section 9.3; Section 9.6
			compress (transfer coding) Section 7.2
			D
			deflate (transfer coding) Section 7.2
			F
			Fields
			Close Section 9.6, Paragraph 4
			MIME-Version Appendix B.1
			Transfer-Encoding Section 6.1
			G
			Grammar
			ALPHA Section 1.2
			CR Section 1.2
			CRLF Section 1.2
			CTL Section 1.2
			DIGIT Section 1.2
			DQUOTE Section 1.2
			HEXDIG Section 1.2
			HTAB Section 1.2
			HTTP-message Section 2.1
			HTTP-name Section 2.3
			HTTP-version Section 2.3
			LF Section 1.2
			OCTET Section 1.2
			SP Section 1.2
			Transfer-Encoding Section 6.1
			VCHAR Section 1.2
			absolute-form Section 3.2; Section 3.2.2
			asterisk-form Section 3.2; Section 3.2.4
			authority-form Section 3.2; Section 3.2.3
			chunk Section 7.1
			chunk-data Section 7.1
			chunk-ext Section 7.1; Section 7.1.1
			chunk-ext-name Section 7.1.1
			chunk-ext-val Section 7.1.1
			chunk-size Section 7.1
			chunked-body Section 7.1
			field-line Section 5; Section 7.1.2
			field-name Section 5
			field-value Section 5
			last-chunk Section 7.1
			message-body Section 6
			method Section 3.1
			obs-fold Section 5.2
			origin-form Section 3.2; Section 3.2.1
			reason-phrase Section 4
			request-line Section 3
			request-target Section 3.2
			start-line Section 2.1
			status-code Section 4
			status-line Section 4
			trailer-section Section 7.1; Section 7.1.2
			gzip (transfer coding) Section 7.2
			H
			Header Fields
			MIME-Version Appendix B.1
			Transfer-Encoding Section 6.1
			header line Section 2.1
			header section Section 2.1
			headers Section 2.1
			M
			MIME-Version header field Appendix B.1
			Media Type
			application/http Section 10.2
			message/http Section 10.1
			message/http Media Type Section 10.1
			method Section 3.1
			O
			origin-form (of request-target) Section 3.2.1
			R
			request-target Section 3.2
			T
			Transfer-Encoding header field Section 6.1
			X
			x-compress (transfer coding) Section 7.2
			x-gzip (transfer coding) Section 7.2
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		United States of America
	EMail: fielding@gbiv.com		Email: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: https://roy.gbiv.com/
	Julian F. Reschke (editor)		Mark Nottingham (editor)
			Fastly
			Prahran VIC
			Australia
			Email: mnot@mnot.net
			URI: https://www.mnot.net/
			Julian Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		48155 Münster
	Germany		Germany
	EMail: julian.reschke@greenbytes.de		Email: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: https://greenbytes.de/tech/webdav/
End of changes. 358 change blocks.
	1197 lines changed or deleted		1578 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/