draft-ietf-httpbis-messaging-04.txt		draft-ietf-httpbis-messaging-05.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: September 10, 2019 J. Reschke, Ed.		Expires: January 9, 2020 J. Reschke, Ed.
	greenbytes		greenbytes
	March 9, 2019		July 8, 2019
	HTTP/1.1 Messaging		HTTP/1.1 Messaging
	draft-ietf-httpbis-messaging-04		draft-ietf-httpbis-messaging-05
	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.5.		The changes in this draft are summarized in Appendix D.6.
	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 September 10, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5		1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
	2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Message . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6		2.1. Message Format . . . . . . . . . . . . . . . . . . . . . 6
	2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 6		2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 7
	2.3. Message Parsing . . . . . . . . . . . . . . . . . . . . . 7		2.3. Message Parsing . . . . . . . . . . . . . . . . . . . . . 8
	3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Request Line . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 9		3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10		3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
	3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 10		3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 11
	3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11		3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11
	3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11		3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 12
	3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12		3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12
	4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15		5.1. Header Field Parsing . . . . . . . . . . . . . . . . . . 15
	5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 15		5.2. Obsolete Line Folding . . . . . . . . . . . . . . . . . . 16
	6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 16		6. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17		6.1. Transfer-Encoding . . . . . . . . . . . . . . . . . . . . 17
	6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 18		6.2. Content-Length . . . . . . . . . . . . . . . . . . . . . 19
	6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19		6.3. Message Body Length . . . . . . . . . . . . . . . . . . . 19
	7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21		7. Transfer Codings . . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22		7.1. Chunked Transfer Coding . . . . . . . . . . . . . . . . . 22
	7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 22		7.1.1. Chunk Extensions . . . . . . . . . . . . . . . . . . 23
	7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 23		7.1.2. Chunked Trailer Part . . . . . . . . . . . . . . . . 24
	7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 24		7.1.3. Decoding Chunked . . . . . . . . . . . . . . . . . . 25
	7.2. Transfer Codings for Compression . . . . . . . . . . . . 24		7.2. Transfer Codings for Compression . . . . . . . . . . . . 25
	7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25		7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 26
	7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 26		8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
	9. Connection Management . . . . . . . . . . . . . . . . . . . . 27		9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28		9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 29
	9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 29		9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
	9.3. Associating a Response to a Request . . . . . . . . . . . 29		9.3. Associating a Response to a Request . . . . . . . . . . . 30
	9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30		9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 31
	9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31		9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 32
	9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31		9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32
	9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32		9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 33
	9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 32		9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33
	9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33		9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34		9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35
	9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36		9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37
	9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37		9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 38
	10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37		10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 38
	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 . . . . . . . . . . . . . . 40
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 40		11. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 40		11.1. Response Splitting . . . . . . . . . . . . . . . . . . . 41
	11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 41		11.2. Request Smuggling . . . . . . . . . . . . . . . . . . . 42
	11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 41		11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42
	11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42		11.4. Message Confidentiality . . . . . . . . . . . . . . . . 43
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
	12.1. Header Field Registration . . . . . . . . . . . . . . . 42		12.1. Header Field Registration . . . . . . . . . . . . . . . 43
	12.2. Media Type Registration . . . . . . . . . . . . . . . . 42		12.2. Media Type Registration . . . . . . . . . . . . . . . . 43
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 44
	13.1. Normative References . . . . . . . . . . . . . . . . . . 43		13.1. Normative References . . . . . . . . . . . . . . . . . . 44
	13.2. Informative References . . . . . . . . . . . . . . . . . 44		13.2. Informative References . . . . . . . . . . . . . . . . . 45
	Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 46		Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 47
	Appendix B. Differences between HTTP and MIME . . . . . . . . . 47		Appendix B. Differences between HTTP and MIME . . . . . . . . . 48
	B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 48		B.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 49
	B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 48		B.2. Conversion to Canonical Form . . . . . . . . . . . . . . 49
	B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 48		B.3. Conversion of Date Formats . . . . . . . . . . . . . . . 49
	B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 49		B.4. Conversion of Content-Encoding . . . . . . . . . . . . . 50
	B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 49		B.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 50
	B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 49		B.6. MHTML and Line Length Limitations . . . . . . . . . . . . 50
	Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 49		Appendix C. HTTP Version History . . . . . . . . . . . . . . . . 50
	C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 50		C.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 51
	C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 50		C.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . 51
	C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 51		C.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . 52
	C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 51		C.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 52
	C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 51		C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 52
	Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 52		Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 53
	D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 52		D.1. Between RFC7230 and draft 00 . . . . . . . . . . . . . . 53
	D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 52		D.2. Since draft-ietf-httpbis-messaging-00 . . . . . . . . . . 53
	D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 53		D.3. Since draft-ietf-httpbis-messaging-01 . . . . . . . . . . 54
	D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 53		D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 54
	D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 54		D.5. Since draft-ietf-httpbis-messaging-03 . . . . . . . . . . 55
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54		D.6. Since draft-ietf-httpbis-messaging-04 . . . . . . . . . . 55
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 57
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level request/response protocol that uses extensible semantics and		level request/response protocol that uses extensible semantics and
	self-descriptive messages for flexible interaction with network-based		self-descriptive messages for flexible interaction with network-based
	hypertext information systems. HTTP is defined by a series of		hypertext information systems. HTTP is defined by a series of
	documents that collectively form the HTTP/1.1 specification:		documents that collectively form the HTTP/1.1 specification:
	o "HTTP Semantics" [Semantics]		o "HTTP Semantics" [Semantics]
	skipping to change at page 13, line 34 ¶		skipping to change at page 14, line 9 ¶
	Recipients of an HTTP/1.0 request that lacks a Host header field		Recipients of an HTTP/1.0 request that lacks a Host header field
	might need to use heuristics (e.g., examination of the URI path for		might need to use heuristics (e.g., examination of the URI path for
	something unique to a particular host) in order to guess the		something unique to a particular host) in order to guess the
	effective request URI's authority component.		effective request URI's authority component.
	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, an OPTIONAL textual phrase describing the status code, and
	and ending with CRLF.		ending with CRLF.
	status-line = HTTP-version SP status-code SP reason-phrase CRLF		status-line = HTTP-version SP status-code SP [reason-phrase] CRLF
	Although the status-line grammar rule requires that each of the		Although the status-line grammar rule requires that each of the
	component elements be separated by a single SP octet, recipients MAY		component elements be separated by a single SP octet, recipients MAY
	instead parse on whitespace-delimited word boundaries and, aside from		instead parse on whitespace-delimited word boundaries and, aside from
	the line terminator, treat any form of whitespace as the SP separator		the line terminator, treat any form of whitespace as the SP separator
	while ignoring preceding or trailing whitespace; such whitespace		while ignoring preceding or trailing whitespace; such whitespace
	includes one or more of the following octets: SP, HTAB, VT (%x0B), FF		includes one or more of the following octets: SP, HTAB, VT (%x0B), FF
	(%x0C), or bare CR. However, lenient parsing can result in response		(%x0C), or bare CR. However, lenient parsing can result in response
	splitting 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
	skipping to change at page 14, line 18 ¶		skipping to change at page 14, line 42 ¶
	considerations for the definition of new status codes, and the IANA		considerations for the definition of new status codes, and the IANA
	registry.		registry.
	status-code = 3DIGIT		status-code = 3DIGIT
	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.		more frequently used with interactive text clients.
	A client SHOULD ignore the reason-phrase content because it is not a		reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
	reliable channel for information (it might be discarded or
	overwritten by intermediaries, and it is not transmitted in other
	versions of HTTP).
	reason-phrase = *( 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. Header Fields		5. Header Fields
	Each header field consists of a case-insensitive field name followed		Each header field consists of a case-insensitive field name followed
	by a colon (":"), optional leading whitespace, the field value, and		by a colon (":"), optional leading whitespace, the field value, and
	optional trailing whitespace.		optional trailing whitespace.
	header-field = field-name ":" OWS field-value OWS		header-field = field-name ":" OWS field-value OWS
	Most HTTP field names and the rules for parsing within field values		Most HTTP field names and the rules for parsing within field values
	skipping to change at page 15, line 4 ¶		skipping to change at page 15, line 29 ¶
	+-------------------+----------+---------------+		+-------------------+----------+---------------+
	| Header Field Name | Status | Reference |		| Header Field Name | Status | Reference |
	+-------------------+----------+---------------+		+-------------------+----------+---------------+
	| Connection | standard | Section 9.1 |		| Connection | standard | Section 9.1 |
	| MIME-Version | standard | Appendix B.1 |		| MIME-Version | standard | Appendix B.1 |
	| TE | standard | Section 7.4 |		| TE | standard | Section 7.4 |
	| Transfer-Encoding | standard | Section 6.1 |		| Transfer-Encoding | standard | Section 6.1 |
	| Upgrade | standard | Section 9.8 |		| Upgrade | standard | Section 9.8 |
	+-------------------+----------+---------------+		+-------------------+----------+---------------+
			Table 1
	Furthermore, the field name "Close" is reserved, since using that		Furthermore, the field name "Close" is reserved, since using that
	name as an HTTP header field might conflict with the "close"		name as an HTTP header field might conflict with the "close"
	connection option of the Connection header field (Section 9.1).		connection option of the Connection header field (Section 9.1).
	+-------------------+----------+----------+------------+		+-------------------+----------+----------+------------+
	| 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 15, line 47 ¶		skipping to change at page 16, line 26 ¶
	when extracting the field value from a header field.		when extracting the field value from a header field.
	5.2. Obsolete Line Folding		5.2. Obsolete Line Folding
	Historically, HTTP header field values could be extended over		Historically, HTTP header field values could be extended over
	multiple lines by preceding each extra line with at least one space		multiple lines by preceding each extra line with at least one space
	or horizontal tab (obs-fold). This specification deprecates such		or horizontal tab (obs-fold). This specification deprecates such
	line folding except within the message/http media type		line folding except within the message/http media type
	(Section 10.1).		(Section 10.1).
	obs-fold = CRLF 1*( SP / HTAB )		obs-fold = OWS CRLF RWS
	; obsolete line folding		; obsolete line folding
	A sender MUST NOT generate a message that includes line folding		A sender MUST NOT generate a message that includes line folding
	(i.e., that has any field-value that contains a match to the obs-fold		(i.e., that has any field-value that contains a match to the obs-fold
	rule) unless the message is intended for packaging within the		rule) unless the message is intended for packaging within the
	message/http media type.		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
	skipping to change at page 21, line 49 ¶		skipping to change at page 22, line 31 ¶
	| | ([RFC1950]) | |		| | ([RFC1950]) | |
	| gzip | GZIP file format [RFC1952] | Section |		| gzip | GZIP file format [RFC1952] | Section |
	| | | 7.2 |		| | | 7.2 |
	| trailers | (reserved) | Section 7 |		| trailers | (reserved) | Section 7 |
	| x-compress | Deprecated (alias for compress) | Section |		| x-compress | Deprecated (alias for compress) | Section |
	| | | 7.2 |		| | | 7.2 |
	| x-gzip | Deprecated (alias for gzip) | Section |		| x-gzip | Deprecated (alias for gzip) | Section |
	| | | 7.2 |		| | | 7.2 |
	+------------+------------------------------------------+-----------+		+------------+------------------------------------------+-----------+
			Table 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,
	followed by an OPTIONAL trailer containing header fields. Chunked		followed by an OPTIONAL trailer containing header fields. Chunked
	enables content streams of unknown size to be transferred as a		enables content streams of unknown size to be transferred as a
	skipping to change at page 31, line 17 ¶		skipping to change at page 32, line 17 ¶
	9.4.1. Retrying Requests		9.4.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.
	When an inbound connection is closed prematurely, a client MAY open a		When an inbound connection is closed prematurely, a client MAY open a
	new connection and automatically retransmit an aborted sequence of		new connection and automatically retransmit an aborted sequence of
	requests if all of those requests have idempotent methods		requests if all of those requests have idempotent methods
	(Section 7.2.2 of [Semantics]). A proxy MUST NOT automatically retry		(Section 7.2.2 of [Semantics]).
	non-idempotent requests.
	A user agent MUST NOT automatically retry a request with a non-
	idempotent method unless it has some means to know that the request
	semantics are actually idempotent, regardless of the method, or some
	means to detect that the original request was never applied. For
	example, a user agent that knows (through design or configuration)
	that a POST request to a given resource is safe can repeat that
	request automatically. Likewise, a user agent designed specifically
	to operate on a version control repository might be able to recover
	from partial failure conditions by checking the target resource
	revision(s) after a failed connection, reverting or fixing any
	changes that were partially applied, and then automatically retrying
	the requests that failed.
	A client SHOULD NOT automatically retry a failed automatic retry.
	9.4.2. Pipelining		9.4.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 7.2.1 of		parallel if they all have safe methods (Section 7.2.1 of
	[Semantics]), but it MUST send the corresponding responses in the		[Semantics]), but it MUST send the corresponding responses in the
	same order that the requests were received.		same order that the requests were received.
	skipping to change at page 34, line 42 ¶		skipping to change at page 35, line 24 ¶
	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.
	9.8. Upgrade		9.8. Upgrade
	The "Upgrade" header field is intended to provide a simple mechanism		The "Upgrade" header field is intended to provide a simple mechanism
	for transitioning from HTTP/1.1 to some other protocol on the same		for transitioning from HTTP/1.1 to some other protocol on the same
	connection. A client MAY send a list of protocols in the Upgrade		connection.
	header field of a request to invite the server to switch to one or
	more of those protocols, in order of descending preference, before		A client MAY send a list of protocol names in the Upgrade header
			field of a request to invite the server to switch to one or more of
			the named protocols, in order of descending preference, before
	sending the final response. A server MAY ignore a received Upgrade		sending the final response. A server MAY ignore a received Upgrade
	header field if it wishes to continue using the current protocol on		header field if it wishes to continue using the current protocol on
	that connection. Upgrade cannot be used to insist on a protocol		that connection. Upgrade cannot be used to insist on a protocol
	change.		change.
	Upgrade = 1#protocol		Upgrade = 1#protocol
	protocol = protocol-name ["/" protocol-version]		protocol = protocol-name ["/" protocol-version]
	protocol-name = token		protocol-name = token
	protocol-version = token		protocol-version = token
			Although protocol names are registered with a preferred case,
			recipients SHOULD use case-insensitive comparison when matching each
			protocol-name to supported protocols.
	A server that sends a 101 (Switching Protocols) response MUST send an		A server that sends a 101 (Switching Protocols) response MUST send an
	Upgrade header field to indicate the new protocol(s) to which the		Upgrade header field to indicate the new protocol(s) to which the
	connection is being switched; if multiple protocol layers are being		connection is being switched; if multiple protocol layers are being
	switched, the sender MUST list the protocols in layer-ascending		switched, the sender MUST list the protocols in layer-ascending
	order. A server MUST NOT switch to a protocol that was not indicated		order. A server MUST NOT switch to a protocol that was not indicated
	by the client in the corresponding request's Upgrade header field. A		by the client in the corresponding request's Upgrade header field. A
	server MAY choose to ignore the order of preference indicated by the		server MAY choose to ignore the order of preference indicated by the
	client and select the new protocol(s) based on other factors, such as		client and select the new protocol(s) based on other factors, such as
	the nature of the request or the current load on the server.		the nature of the request or the current load on the server.
	skipping to change at page 37, line 29 ¶		skipping to change at page 38, line 21 ¶
	Each registered protocol name is associated with contact information		Each registered protocol name is associated with contact information
	and an optional set of specifications that details how the connection		and an optional set of specifications that details how the connection
	will be processed after it has been upgraded.		will be processed after it has been upgraded.
	Registrations happen on a "First Come First Served" basis (see		Registrations happen on a "First Come First Served" basis (see
	Section 4.4 of [RFC8126]) and are subject to the following rules:		Section 4.4 of [RFC8126]) and are subject to the following rules:
	1. A protocol-name token, once registered, stays registered forever.		1. A protocol-name token, once registered, stays registered forever.
	2. The registration MUST name a responsible party for the		2. A protocol-name token is case-insensitive and registered with the
			preferred case to be generated by senders.
			3. The registration MUST name a responsible party for the
	registration.		registration.
	3. The registration MUST name a point of contact.		4. The registration MUST name a point of contact.
	4. The registration MAY name a set of specifications associated with		5. The registration MAY name a set of specifications associated with
	that token. Such specifications need not be publicly available.		that token. Such specifications need not be publicly available.
	5. The registration SHOULD name a set of expected "protocol-version"		6. The registration SHOULD name a set of expected "protocol-version"
	tokens associated with that token at the time of registration.		tokens associated with that token at the time of registration.
	6. The responsible party MAY change the registration at any time.		7. The responsible party MAY change the registration at any time.
	The IANA will keep a record of all such changes, and make them		The IANA will keep a record of all such changes, and make them
	available upon request.		available upon request.
	7. The IESG MAY reassign responsibility for a protocol token. This		8. The IESG MAY reassign responsibility for a protocol token. This
	will normally only be used in the case when a responsible party		will normally only be used in the case when a responsible party
	cannot be contacted.		cannot be contacted.
	10. Enclosing Messages as Data		10. Enclosing Messages as Data
	10.1. Media Type message/http		10.1. Media Type message/http
	The message/http media type can be used to enclose a single HTTP		The message/http media type can be used to enclose a single HTTP
	request or response message, provided that it obeys the MIME		request or response message, provided that it obeys the MIME
	restrictions for all "message" types regarding line length and		restrictions for all "message" types regarding line length and
	encodings.		encodings.
	Type name: message		Type name: message
	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.
	skipping to change at page 43, line 24 ¶		skipping to change at page 44, line 10 ¶
	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-04 (work in		Ed., "HTTP Caching", draft-ietf-httpbis-cache-05 (work in
	progress), March 2019.		progress), July 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 16 ¶		skipping to change at page 44, line 48 ¶
	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",		[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
	RFC 7405, DOI 10.17487/RFC7405, December 2014,		RFC 7405, DOI 10.17487/RFC7405, December 2014,
	<https://www.rfc-editor.org/info/rfc7405>.		<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-04		Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-05
	(work in progress), March 2019.		(work in progress), July 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 46, line 12 ¶		skipping to change at page 47, line 12 ¶
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	Appendix A. Collected ABNF		Appendix A. Collected ABNF
	In the collected ABNF below, list rules are expanded as per		In the collected ABNF below, list rules are expanded as per
	Section 11 of [Semantics].		Section 11 of [Semantics].
	BWS = <BWS, see [Semantics], Section 4.3>		BWS = <BWS, see [Semantics], Section 4.3>
	Connection = *( "," OWS ) connection-option *( OWS "," [ OWS		Connection = [ connection-option ] *( OWS "," OWS [ connection-option
	connection-option ] )		] )
	HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body		HTTP-message = start-line *( header-field 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
	OWS = <OWS, see [Semantics], Section 4.3>		OWS = <OWS, see [Semantics], Section 4.3>
	RWS = <RWS, see [Semantics], Section 4.3>		RWS = <RWS, see [Semantics], Section 4.3>
	TE = [ ( "," / t-codings ) *( OWS "," [ OWS t-codings ] ) ]		TE = [ t-codings ] *( OWS "," OWS [ t-codings ] )
	Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS		Transfer-Encoding = [ transfer-coding ] *( OWS "," OWS [
	transfer-coding ] )		transfer-coding ] )
	Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )		Upgrade = [ protocol ] *( OWS "," OWS [ protocol ] )
	absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>		absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
	absolute-form = absolute-URI		absolute-form = absolute-URI
	absolute-path = <absolute-path, see [Semantics], Section 2.4>		absolute-path = <absolute-path, see [Semantics], Section 2.4>
	asterisk-form = "*"		asterisk-form = "*"
	authority = <authority, see [RFC3986], Section 3.2>		authority = <authority, see [RFC3986], Section 3.2>
	authority-form = authority		authority-form = authority
	chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF		chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
	chunk-data = 1*OCTET		chunk-data = 1*OCTET
	skipping to change at page 47, line 9 ¶		skipping to change at page 48, line 9 ¶
	field-name = <field-name, see [Semantics], Section 4.2>		field-name = <field-name, see [Semantics], Section 4.2>
	field-value = <field-value, see [Semantics], Section 4.2>		field-value = <field-value, see [Semantics], Section 4.2>
	header-field = field-name ":" OWS field-value OWS		header-field = field-name ":" OWS field-value OWS
	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 = <obs-text, see [Semantics], Section 4.2.3>		obs-text = <obs-text, see [Semantics], Section 4.2.3>
	origin-form = absolute-path [ "?" query ]		origin-form = absolute-path [ "?" query ]
	port = <port, see [RFC3986], Section 3.2.3>		port = <port, see [RFC3986], Section 3.2.3>
	protocol = protocol-name [ "/" protocol-version ]		protocol = protocol-name [ "/" protocol-version ]
	protocol-name = token		protocol-name = token
	protocol-version = token		protocol-version = token
	query = <query, see [RFC3986], Section 3.4>		query = <query, see [RFC3986], Section 3.4>
	quoted-string = <quoted-string, see [Semantics], Section 4.2.3>		quoted-string = <quoted-string, see [Semantics], Section 4.2.3>
	rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )		rank = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
	reason-phrase = *( HTAB / SP / VCHAR / obs-text )		reason-phrase = 1*( HTAB / SP / VCHAR / obs-text )
	request-line = method SP request-target SP HTTP-version CRLF		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
	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 = token *( OWS ";" OWS transfer-parameter )		transfer-coding = token *( OWS ";" OWS transfer-parameter )
	transfer-parameter = token BWS "=" BWS ( token / quoted-string )		transfer-parameter = token BWS "=" BWS ( token / quoted-string )
	uri-host = <host, see [RFC3986], Section 3.2.2>		uri-host = <host, see [RFC3986], Section 3.2.2>
	skipping to change at page 54, line 18 ¶		skipping to change at page 55, line 18 ¶
	part of a not-yet-issued request (<https://github.com/httpwg/http-		part of a not-yet-issued request (<https://github.com/httpwg/http-
	core/issues/26>)		core/issues/26>)
	o In Section 7, remove the predefined codings from the ABNF and make		o In Section 7, remove the predefined codings from the ABNF and make
	it generic instead (<https://github.com/httpwg/http-core/		it generic instead (<https://github.com/httpwg/http-core/
	issues/66>)		issues/66>)
	o Use RFC 7405 ABNF notation for case-sensitive string constants		o Use RFC 7405 ABNF notation for case-sensitive string constants
	(<https://github.com/httpwg/http-core/issues/133>)		(<https://github.com/httpwg/http-core/issues/133>)
			D.6. Since draft-ietf-httpbis-messaging-04
			o In Section 9.8, clarify that protocol-name is to be matched case-
			insensitively (<https://github.com/httpwg/http-core/issues/8>)
			o In Section 5.2, add leading optional whitespace to obs-fold ABNF
			(<https://github.com/httpwg/http-core/issues/19>,
			<https://www.rfc-editor.org/errata/eid4189>)
			o In Section 4, add clarifications about empty reason phrases
			(<https://github.com/httpwg/http-core/issues/197>)
			o Move discussion of retries from Section 9.4.1 into [Semantics]
			(<https://github.com/httpwg/http-core/issues/230>)
	Index		Index
	A		A
	absolute-form (of request-target) 10		absolute-form (of request-target) 11
	application/http Media Type 39		application/http Media Type 40
	asterisk-form (of request-target) 11		asterisk-form (of request-target) 12
	authority-form (of request-target) 11		authority-form (of request-target) 11
	C		C
	Connection header field 28, 33		Connection header field 29, 34
	Content-Length header field 18		Content-Length header field 19
	Content-Transfer-Encoding header field 49		Content-Transfer-Encoding header field 50
	chunked (Coding Format) 17, 19		chunked (Coding Format) 17, 19
	chunked (transfer coding) 22		chunked (transfer coding) 22
	close 28, 33		close 29, 34
	compress (transfer coding) 24		compress (transfer coding) 25
	D		D
	deflate (transfer coding) 24		deflate (transfer coding) 25
	E		E
	effective request URI 12		effective request URI 12
	G		G
	Grammar		Grammar
	absolute-form 9-10		absolute-form 10-11
	ALPHA 5		ALPHA 5
	asterisk-form 9, 11		asterisk-form 10, 12
	authority-form 9, 11		authority-form 10-11
	chunk 22		chunk 23
	chunk-data 22		chunk-data 23
	chunk-ext 22		chunk-ext 23
	chunk-ext-name 22		chunk-ext-name 23
	chunk-ext-val 22		chunk-ext-val 23
	chunk-size 22		chunk-size 23
	chunked-body 22		chunked-body 23
	Connection 28		Connection 29
	connection-option 28		connection-option 29
	CR 5		CR 5
	CRLF 5		CRLF 5
	CTL 5		CTL 5
	DIGIT 5		DIGIT 5
	DQUOTE 5		DQUOTE 5
	field-name 14		field-name 15
	field-value 14		field-value 15
	header-field 14, 23		header-field 15, 24
	HEXDIG 5		HEXDIG 5
	HTAB 5		HTAB 5
	HTTP-message 6		HTTP-message 6
	HTTP-name 6		HTTP-name 7
	HTTP-version 6		HTTP-version 7
	last-chunk 22		last-chunk 23
	LF 5		LF 5
	message-body 16		message-body 17
	method 9		method 9
	obs-fold 15		obs-fold 16
	OCTET 5		OCTET 5
	origin-form 9-10		origin-form 10
	rank 26		rank 27
	reason-phrase 14		reason-phrase 14
	request-line 8		request-line 9
	request-target 9		request-target 10
	SP 5		SP 5
	start-line 6		start-line 6
	status-code 14		status-code 14
	status-line 13		status-line 14
	t-codings 26		t-codings 27
	t-ranking 26		t-ranking 27
	TE 26		TE 27
	trailer-part 22-23		trailer-part 23-24
	transfer-coding 21		transfer-coding 21
	Transfer-Encoding 17		Transfer-Encoding 17
	transfer-parameter 21		transfer-parameter 22
	Upgrade 35		Upgrade 35
	VCHAR 5		VCHAR 5
	gzip (transfer coding) 24		gzip (transfer coding) 25
	H		H
	header field 6		header field 6
	header section 6		header section 6
	headers 6		headers 6
	M		M
	MIME-Version header field 48		MIME-Version header field 49
	Media Type		Media Type
	application/http 39		application/http 40
	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 10
	T		T
	TE header field 25		TE header field 26
	Transfer-Encoding header field 17		Transfer-Encoding header field 17
	U		U
	Upgrade header field 34		Upgrade header field 35
	X		X
	x-compress (transfer coding) 24		x-compress (transfer coding) 25
	x-gzip (transfer coding) 24		x-gzip (transfer coding) 25
	Acknowledgments		Acknowledgments
	See Appendix "Acknowledgments" of [Semantics].		See Appendix "Acknowledgments" of [Semantics].
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe		Adobe
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: https://roy.gbiv.com/		URI: https://roy.gbiv.com/
	Mark Nottingham (editor)		Mark Nottingham (editor)
End of changes. 64 change blocks.
	168 lines changed or deleted		184 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/