draft-ietf-httpbis-messaging-03.txt		draft-ietf-httpbis-messaging-04.txt
	HTTP Working Group R. Fielding, Ed.		HTTP Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 7230 (if approved) M. Nottingham, Ed.		Obsoletes: 7230 (if approved) M. Nottingham, Ed.
	Intended status: Standards Track Fastly		Intended status: Standards Track Fastly
	Expires: April 21, 2019 J. Reschke, Ed.		Expires: September 10, 2019 J. Reschke, Ed.
	greenbytes		greenbytes
	October 18, 2018		March 9, 2019
	HTTP/1.1 Messaging		HTTP/1.1 Messaging
	draft-ietf-httpbis-messaging-03		draft-ietf-httpbis-messaging-04
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level protocol for distributed, collaborative, hypertext information		level protocol for distributed, collaborative, hypertext information
	systems. This document specifies the HTTP/1.1 message syntax,		systems. This document specifies the HTTP/1.1 message syntax,
	message parsing, connection management, and related security		message parsing, connection management, and related security
	concerns.		concerns.
	This document obsoletes portions of RFC 7230.		This document obsoletes portions of RFC 7230.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<https://lists.w3.org/Archives/Public/ietf-http-wg/>.		<https://lists.w3.org/Archives/Public/ietf-http-wg/>.
	Working Group information can be found at <https://httpwg.org/>;		Working Group information can be found at <https://httpwg.org/>;
	source code and issues list for this draft can be found at		source code and issues list for this draft can be found at
	<https://github.com/httpwg/http-core>.		<https://github.com/httpwg/http-core>.
	The changes in this draft are summarized in Appendix D.4.		The changes in this draft are summarized in Appendix D.5.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 21, 2019.		This Internet-Draft will expire on September 10, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15		5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15
	5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15		5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15
	6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16		6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17		6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
	6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18		6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18
	6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19		6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19
	7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21		7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22		7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22
	7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23		7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 22
	7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23		7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23
	7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24		7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24
	7.2. Transfer Codings for Compression . . . . . . . . . . . . 25		7.2. Transfer Codings for Compression . . . . . . . . . . . . 24
	7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25		7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
	7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27		8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 26
	9. Connection Management . . . . . . . . . . . . . . . . . . . . 28		9. Connection Management . . . . . . . . . . . . . . . . . . . . 27
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28		9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
	9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30		9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 29
	9.3. Associating a Response to a Request . . . . . . . . . . . 30		9.3. Associating a Response to a Request . . . . . . . . . . . 29
	9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30		9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
	9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31		9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
	9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32		9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31
	9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32		9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
	9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33		9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32
	9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34		9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33
	9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35		9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37		9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36
	9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37		9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37
	10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 38		10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37
	10.1. Media Type message/http . . . . . . . . . . . . . . . . 38		10.1. Media Type message/http . . . . . . . . . . . . . . . . 38
	10.2. Media Type application/http . . . . . . . . . . . . . . 39		10.2. Media Type application/http . . . . . . . . . . . . . . 39
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 40		11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40		11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40
	11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41		11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41
	11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42		11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 41
	11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42		11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	12.1. Header Field Registration . . . . . . . . . . . . . . . 43		12.1. Header Field Registration . . . . . . . . . . . . . . . 42
	12.2. Media Type Registration . . . . . . . . . . . . . . . . 43		12.2. Media Type Registration . . . . . . . . . . . . . . . . 42
	12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43		12.3. Transfer Coding Registration . . . . . . . . . . . . . . 43
	12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43		12.4. Upgrade Token Registration . . . . . . . . . . . . . . . 43
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	13.1. Normative References . . . . . . . . . . . . . . . . . . 43		13.1. Normative References . . . . . . . . . . . . . . . . . . 43
	13.2. Informative References . . . . . . . . . . . . . . . . . 44		13.2. Informative References . . . . . . . . . . . . . . . . . 44
	Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 47		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46
	Appendix B. Differences between HTTP and MIME . . . . . . . . . 48		Appendix B. Differences between HTTP and MIME . . . . . . . . . 47
	B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 49		B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 48
	B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 49		B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 48
	B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 49		B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 48
	B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 50		B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 49
	B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 50		B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 49
	B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 50		B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 49
	Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 50		Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 49
	C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 51		C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 50
	C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 51		C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 50
	C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 52		C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 51
	C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 52		C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 51
	C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 53		C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 51
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 52
	D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 53		D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 52
	D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 53		D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 52
	D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 54		D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 53
	D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 55		D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 53
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55		D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 54
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level request/response protocol that uses extensible semantics and		level request/response protocol that uses extensible semantics and
	self-descriptive messages for flexible interaction with network-based		self-descriptive messages for flexible interaction with network-based
	hypertext information systems. HTTP is defined by a series of		hypertext information systems. HTTP is defined by a series of
	documents that collectively form the HTTP/1.1 specification:		documents that collectively form the HTTP/1.1 specification:
	o "HTTP Semantics" [Semantics]		o "HTTP Semantics" [Semantics]
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Conformance criteria and considerations regarding error handling are		Conformance criteria and considerations regarding error handling are
	defined in Section 3 of [Semantics].		defined in Section 3 of [Semantics].
	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 11 of		notation of [RFC5234], extended with the notation for case-
	[Semantics], that allows for compact definition of comma-separated		sensitivity in strings defined in [RFC7405].
	lists using a '#' operator (similar to how the '*' operator indicates
	repetition). Appendix A shows the collected grammar with all list		It also uses a list extension, defined in Section 11 of [Semantics],
	operators expanded to standard ABNF notation.		that allows for compact definition of comma-separated lists using a
			'#' operator (similar to how the '*' operator indicates repetition).
			Appendix A shows the collected grammar with all list operators
			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).
	skipping to change at page 6, line 49 ¶		skipping to change at page 6, line 49 ¶
	HTTP uses a "<major>.<minor>" numbering scheme to indicate versions		HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
	of the protocol. This specification defines version "1.1".		of the protocol. This specification defines version "1.1".
	Section 3.5 of [Semantics] specifies the semantics of HTTP version		Section 3.5 of [Semantics] specifies the semantics of HTTP version
	numbers.		numbers.
	The version of an HTTP/1.x message is indicated by an HTTP-version		The version of an HTTP/1.x message is indicated by an HTTP-version
	field in the start-line. HTTP-version is case-sensitive.		field in the start-line. HTTP-version is case-sensitive.
	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 [RFC1945]
	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.
	skipping to change at page 14, line 44 ¶		skipping to change at page 14, line 40 ¶
	header-field = field-name ":" OWS field-value OWS		header-field = field-name ":" OWS field-value OWS
	Most HTTP field names and the rules for parsing within field values		Most HTTP field names and the rules for parsing within field values
	are defined in Section 4 of [Semantics]. This section covers the		are defined in Section 4 of [Semantics]. This section covers the
	generic syntax for header field inclusion within, and extraction		generic syntax for header field inclusion within, and extraction
	from, HTTP/1.1 messages. In addition, the following header fields		from, HTTP/1.1 messages. In addition, the following header fields
	are defined by this document because they are specific to HTTP/1.1		are defined by this document because they are specific to HTTP/1.1
	message processing:		message processing:
	+-------------------+----------+----------+---------------+		+-------------------+----------+---------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Status | Reference |
	+-------------------+----------+----------+---------------+		+-------------------+----------+---------------+
	| Connection | http | standard | Section 9.1 |		| Connection | standard | Section 9.1 |
	| MIME-Version | http | standard | Appendix B.1 |		| MIME-Version | standard | Appendix B.1 |
	| TE | http | standard | Section 7.4 |		| TE | standard | Section 7.4 |
	| Transfer-Encoding | http | standard | Section 6.1 |		| Transfer-Encoding | standard | Section 6.1 |
	| Upgrade | http | standard | Section 9.8 |		| Upgrade | standard | Section 9.8 |
	+-------------------+----------+----------+---------------+		+-------------------+----------+---------------+
	Furthermore, the field name "Close" is reserved, since using that		Furthermore, the field name "Close" is reserved, since using that
	name as an HTTP header field might conflict with the "close"		name as an HTTP header field might conflict with the "close"
	connection option of the Connection header field (Section 9.1).		connection option of the Connection header field (Section 9.1).
	+-------------------+----------+----------+------------+		+-------------------+----------+----------+------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+------------+		+-------------------+----------+----------+------------+
	| Close | http | reserved | Section 5 |		| Close | http | reserved | Section 5 |
	+-------------------+----------+----------+------------+		+-------------------+----------+----------+------------+
	skipping to change at page 21, line 19 ¶		skipping to change at page 21, line 19 ¶
	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 payload body
	in order to ensure "safe transport" through the network. This		in order to ensure "safe transport" through the network. This
	differs from a content coding in that the transfer coding is a		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 7.1		transfer-coding = token *( OWS ";" OWS transfer-parameter )
	/ "compress" ; [Semantics], Section 6.1.2.1
	/ "deflate" ; [Semantics], Section 6.1.2.2
	/ "gzip" ; [Semantics], Section 6.1.2.3
	/ transfer-extension
	transfer-extension = token *( OWS ";" OWS transfer-parameter )
	Parameters are in the form of a name=value pair.		Parameters are in the form of a name=value pair.
	transfer-parameter = token BWS "=" BWS ( token / quoted-string )		transfer-parameter = token BWS "=" BWS ( token / quoted-string )
	All transfer-coding names are case-insensitive and ought to be		All transfer-coding names are case-insensitive and ought to be
	registered within the HTTP Transfer Coding registry, as defined in		registered within the HTTP Transfer Coding registry, as defined in
	Section 7.3. They are used in the TE (Section 7.4) and Transfer-		Section 7.3. They are used in the TE (Section 7.4) and Transfer-
	Encoding (Section 6.1) header fields.		Encoding (Section 6.1) header fields.
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	| Name | Description | Reference |		| Name | Description | Reference |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	| chunked | Transfer in a series of chunks | Section 7 |		| chunked | Transfer in a series of chunks | Section |
	| | | .1 |		| | | 7.1 |
	| compress | UNIX "compress" data format [Welch] | Section 7 |		| compress | UNIX "compress" data format [Welch] | Section |
	| | | .2 |		| | | 7.2 |
	| deflate | "deflate" compressed data ([RFC1951]) | Section 7 |		| deflate | "deflate" compressed data ([RFC1951]) | Section |
	| | inside the "zlib" data format | .2 |		| | inside the "zlib" data format | 7.2 |
	| | ([RFC1950]) | |		| | ([RFC1950]) | |
	| gzip | GZIP file format [RFC1952] | Section 7 |		| gzip | GZIP file format [RFC1952] | Section |
	| | | .2 |		| | | 7.2 |
	| trailers | (reserved) | Section 7 |		| trailers | (reserved) | Section 7 |
	| x-compress | Deprecated (alias for compress) | Section 7 |		| x-compress | Deprecated (alias for compress) | Section |
	| | | .2 |		| | | 7.2 |
	| x-gzip | Deprecated (alias for gzip) | Section 7 |		| x-gzip | Deprecated (alias for gzip) | Section |
	| | | .2 |		| | | 7.2 |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
	Note: the coding name "trailers" is reserved because it would		Note: the coding name "trailers" is reserved because it would
	clash with the use of the keyword "trailers" in the TE header		clash with the use of the keyword "trailers" in the TE header
	field (Section 7.4).		field (Section 7.4).
	7.1. Chunked Transfer Coding		7.1. Chunked Transfer Coding
	The chunked transfer coding wraps the payload body in order to		The chunked transfer coding wraps the payload body in order to
	transfer it as a series of chunks, each with its own size indicator,		transfer it as a series of chunks, each with its own size indicator,
	skipping to change at page 23, line 10 ¶		skipping to change at page 22, line 35 ¶
	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, 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.
			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), mid-		supplying per-chunk metadata (such as a signature or hash), mid-
	message control information, or randomization of message body size.		message control information, or randomization of message body size.
	chunk-ext = *( BWS ";" BWS chunk-ext-name		chunk-ext = *( BWS ";" BWS chunk-ext-name
	[ BWS "=" BWS chunk-ext-val ] )		[ BWS "=" BWS chunk-ext-val ] )
	skipping to change at page 25, line 38 ¶		skipping to change at page 25, line 6 ¶
	compress (and x-compress)		compress (and x-compress)
	See Section 6.1.2.1 of [Semantics].		See Section 6.1.2.1 of [Semantics].
	deflate		deflate
	See Section 6.1.2.2 of [Semantics].		See Section 6.1.2.2 of [Semantics].
	gzip (and x-gzip)		gzip (and x-gzip)
	See Section 6.1.2.3 of [Semantics].		See Section 6.1.2.3 of [Semantics].
			The compression codings do not define any parameters. Their presence
			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
	<https://www.iana.org/assignments/http-parameters>.		<https://www.iana.org/assignments/http-parameters>.
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Name		o Name
	skipping to change at page 30, line 31 ¶		skipping to change at page 29, line 49 ¶
	same connection. More than one response message per request only		same connection. More than one response message per request only
	occurs when one or more informational responses (1xx, see Section 9.2		occurs when one or more informational responses (1xx, see Section 9.2
	of [Semantics]) precede a final response to the same request.		of [Semantics]) 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 (non-		the highest ordered request that has not yet received a final (non-
	1xx) response.		1xx) response.
			If an HTTP/1.1 client receives data on a connection that doesn't have
			any outstanding requests, it MUST NOT consider them to be a response
			to a not-yet-issued request; it 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.3).
	9.4. Persistence		9.4. Persistence
	HTTP/1.1 defaults to the use of "persistent connections", allowing		HTTP/1.1 defaults to the use of "persistent connections", allowing
	multiple requests and responses to be carried over a single		multiple requests and responses to be carried over a single
	connection. The "close" connection option is used to signal that a		connection. The "close" connection option is used to signal that a
	connection will not persist after the current request/response. HTTP		connection will not persist after the current request/response. HTTP
	implementations SHOULD support persistent connections.		implementations SHOULD support persistent connections.
	A recipient determines whether a connection is persistent or not		A recipient determines whether a connection is persistent or not
	based on the most recently received message's protocol version and		based on the most recently received message's protocol version and
	skipping to change at page 43, line 7 ¶		skipping to change at page 42, line 38 ¶
	confidential connection, as described in Section 2.5.2 of		confidential connection, as described in Section 2.5.2 of
	[Semantics].		[Semantics].
	12. IANA Considerations		12. IANA Considerations
	The change controller for the following registrations is: "IETF		The change controller for the following registrations is: "IETF
	(iesg@ietf.org) - Internet Engineering Task Force".		(iesg@ietf.org) - Internet Engineering Task Force".
	12.1. Header Field Registration		12.1. Header Field Registration
	Please update the "Message Headers" registry of "Permanent Message		Please update the "Hypertext Transfer Protocol (HTTP) Header Field
	Header Field Names" at <https://www.iana.org/assignments/message-		Registry" registry at <https://www.iana.org/assignments/http-headers>
	headers> with the header field names listed in the two tables of		with the header field names listed in the two tables of Section 5.
	Section 5.
	12.2. Media Type Registration		12.2. Media Type Registration
	Please update the "Media Types" registry at		Please update the "Media Types" registry at
	<https://www.iana.org/assignments/media-types> with the registration		<https://www.iana.org/assignments/media-types> with the registration
	information in Section 10.1 and Section 10.2 for the media types		information in Section 10.1 and Section 10.2 for the media types
	"message/http" and "application/http", respectively.		"message/http" and "application/http", respectively.
	12.3. Transfer Coding Registration		12.3. Transfer Coding Registration
	skipping to change at page 43, line 38 ¶		skipping to change at page 43, line 24 ¶
	Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token		Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token
	Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>		Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>
	with the registration procedure of Section 9.8.2 and the upgrade		with the registration procedure of Section 9.8.2 and the upgrade
	token names summarized in the table of Section 9.8.1.		token names summarized in the table of Section 9.8.1.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Caching", draft-ietf-httpbis-cache-03 (work in		Ed., "HTTP Caching", draft-ietf-httpbis-cache-04 (work in
	progress), October 2018.		progress), March 2019.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
	Specification version 3.3", RFC 1950,		Specification version 3.3", RFC 1950,
	DOI 10.17487/RFC1950, May 1996,		DOI 10.17487/RFC1950, May 1996,
	<https://www.rfc-editor.org/info/rfc1950>.		<https://www.rfc-editor.org/info/rfc1950>.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
	version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,		version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
	<https://www.rfc-editor.org/info/rfc1951>.		<https://www.rfc-editor.org/info/rfc1951>.
	skipping to change at page 44, line 25 ¶		skipping to change at page 44, line 10 ¶
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
			[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
			RFC 7405, DOI 10.17487/RFC7405, December 2014,
			<https://www.rfc-editor.org/info/rfc7405>.
	[Semantics]		[Semantics]
	Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-03		Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-04
	(work in progress), October 2018.		(work in progress), March 2019.
	[USASCII] American National Standards Institute, "Coded Character		[USASCII] American National Standards Institute, "Coded Character
	Set -- 7-bit American Standard Code for Information		Set -- 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	[Welch] Welch, T., "A Technique for High-Performance Data		[Welch] Welch, T., "A Technique for High-Performance Data
	Compression", IEEE Computer 17(6), June 1984.		Compression", IEEE Computer 17(6), June 1984.
	13.2. Informative References		13.2. Informative References
	skipping to change at page 48, line 35 ¶		skipping to change at page 47, line 35 ¶
	asterisk-form		asterisk-form
	start-line = request-line / status-line		start-line = request-line / status-line
	status-code = 3DIGIT		status-code = 3DIGIT
	status-line = HTTP-version SP status-code SP reason-phrase CRLF		status-line = HTTP-version SP status-code SP reason-phrase CRLF
	t-codings = "trailers" / ( transfer-coding [ t-ranking ] )		t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
	t-ranking = OWS ";" OWS "q=" rank		t-ranking = OWS ";" OWS "q=" rank
	token = <token, see [Semantics], Section 4.2.3>		token = <token, see [Semantics], Section 4.2.3>
	trailer-part = *( header-field CRLF )		trailer-part = *( header-field CRLF )
	transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /		transfer-coding = token *( OWS ";" OWS transfer-parameter )
	transfer-extension
	transfer-extension = token *( OWS ";" OWS transfer-parameter )
	transfer-parameter = token BWS "=" BWS ( token / quoted-string )		transfer-parameter = token BWS "=" BWS ( token / quoted-string )
	uri-host = <host, see [RFC3986], Section 3.2.2>		uri-host = <host, see [RFC3986], Section 3.2.2>
	Appendix B. Differences between HTTP and MIME		Appendix B. Differences between HTTP and MIME
	HTTP/1.1 uses many of the constructs defined for the Internet Message		HTTP/1.1 uses many of the constructs defined for the Internet Message
	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 header fields.
	skipping to change at page 55, line 13 ¶		skipping to change at page 54, line 5 ¶
	registry (<https://github.com/httpwg/http-core/issues/108>)		registry (<https://github.com/httpwg/http-core/issues/108>)
	D.4. Since draft-ietf-httpbis-messaging-02		D.4. Since draft-ietf-httpbis-messaging-02
	o In Section 4, explain why the reason phrase should be ignored by		o In Section 4, explain why the reason phrase should be ignored by
	clients (<https://github.com/httpwg/http-core/issues/60>).		clients (<https://github.com/httpwg/http-core/issues/60>).
	o Add Section 9.3 to explain how request/response correlation is		o Add Section 9.3 to explain how request/response correlation is
	performed (<https://github.com/httpwg/http-core/issues/145>)		performed (<https://github.com/httpwg/http-core/issues/145>)
			D.5. Since draft-ietf-httpbis-messaging-03
			o In Section 9.3, caution against treating data on a connection as
			part of a not-yet-issued request (<https://github.com/httpwg/http-
			core/issues/26>)
			o In Section 7, remove the predefined codings from the ABNF and make
			it generic instead (<https://github.com/httpwg/http-core/
			issues/66>)
			o Use RFC 7405 ABNF notation for case-sensitive string constants
			(<https://github.com/httpwg/http-core/issues/133>)
	Index		Index
	A		A
	absolute-form (of request-target) 10		absolute-form (of request-target) 10
	application/http Media Type 39		application/http Media Type 39
	asterisk-form (of request-target) 11		asterisk-form (of request-target) 11
	authority-form (of request-target) 11		authority-form (of request-target) 11
	C		C
	Connection header field 28, 34		Connection header field 28, 33
	Content-Length header field 18		Content-Length header field 18
	Content-Transfer-Encoding header field 50		Content-Transfer-Encoding header field 49
	chunked (Coding Format) 17, 19		chunked (Coding Format) 17, 19
	chunked (transfer coding) 22		chunked (transfer coding) 22
	close 28, 34		close 28, 33
	compress (transfer coding) 25		compress (transfer coding) 24
	D		D
	deflate (transfer coding) 25		deflate (transfer coding) 24
	E		E
	effective request URI 12		effective request URI 12
	G		G
	Grammar		Grammar
	absolute-form 9-10		absolute-form 9-10
	ALPHA 5		ALPHA 5
	asterisk-form 9, 11		asterisk-form 9, 11
	authority-form 9, 11		authority-form 9, 11
	chunk 22		chunk 22
	chunk-data 22		chunk-data 22
	chunk-ext 22-23		chunk-ext 22
	chunk-ext-name 23		chunk-ext-name 22
	chunk-ext-val 23		chunk-ext-val 22
	chunk-size 22		chunk-size 22
	chunked-body 22-23		chunked-body 22
	Connection 29		Connection 28
	connection-option 29		connection-option 28
	CR 5		CR 5
	CRLF 5		CRLF 5
	CTL 5		CTL 5
	DIGIT 5		DIGIT 5
	DQUOTE 5		DQUOTE 5
	field-name 14		field-name 14
	field-value 14		field-value 14
	header-field 14, 23		header-field 14, 23
	HEXDIG 5		HEXDIG 5
	HTAB 5		HTAB 5
	skipping to change at page 56, line 36 ¶		skipping to change at page 55, line 41 ¶
	SP 5		SP 5
	start-line 6		start-line 6
	status-code 14		status-code 14
	status-line 13		status-line 13
	t-codings 26		t-codings 26
	t-ranking 26		t-ranking 26
	TE 26		TE 26
	trailer-part 22-23		trailer-part 22-23
	transfer-coding 21		transfer-coding 21
	Transfer-Encoding 17		Transfer-Encoding 17
	transfer-extension 21
	transfer-parameter 21		transfer-parameter 21
	Upgrade 35		Upgrade 35
	VCHAR 5		VCHAR 5
	gzip (transfer coding) 25		gzip (transfer coding) 24
	H		H
	header field 6		header field 6
	header section 6		header section 6
	headers 6		headers 6
	M		M
	MIME-Version header field 49		MIME-Version header field 48
	Media Type		Media Type
	application/http 39		application/http 39
	message/http 38		message/http 38
	message/http Media Type 38		message/http Media Type 38
	method 9		method 9
	O		O
	origin-form (of request-target) 10		origin-form (of request-target) 10
	R		R
	request-target 9		request-target 9
	T		T
	TE header field 26		TE header field 25
	Transfer-Encoding header field 17		Transfer-Encoding header field 17
	U		U
	Upgrade header field 35		Upgrade header field 34
	X		X
	x-compress (transfer coding) 25		x-compress (transfer coding) 24
	x-gzip (transfer coding) 25		x-gzip (transfer coding) 24
	Acknowledgments		Acknowledgments
	See Appendix "Acknowledgments" of [Semantics].		See Appendix "Acknowledgments" of [Semantics].
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe		Adobe
	345 Park Ave		345 Park Ave
End of changes. 45 change blocks.
	107 lines changed or deleted		130 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/