draft-ietf-httpbis-messaging-02.txt		draft-ietf-httpbis-messaging-03.txt
	HTTP Working Group R. Fielding, Ed.		HTTP Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 7230 (if approved) M. Nottingham, Ed.		Obsoletes: 7230 (if approved) M. Nottingham, Ed.
	Intended status: Standards Track Fastly		Intended status: Standards Track Fastly
	Expires: January 3, 2019 J. Reschke, Ed.		Expires: April 21, 2019 J. Reschke, Ed.
	greenbytes		greenbytes
	July 2, 2018		October 18, 2018
	HTTP/1.1 Messaging		HTTP/1.1 Messaging
	draft-ietf-httpbis-messaging-02		draft-ietf-httpbis-messaging-03
	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.3.		The changes in this draft are summarized in Appendix D.4.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 3, 2019.		This Internet-Draft will expire on April 21, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 3, line 8 ¶		skipping to change at page 3, line 8 ¶
	3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Method . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 9		3.2. Request Target . . . . . . . . . . . . . . . . . . . . . 9
	3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10		3.2.1. origin-form . . . . . . . . . . . . . . . . . . . . . 10
	3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 10		3.2.2. absolute-form . . . . . . . . . . . . . . . . . . . . 10
	3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11		3.2.3. authority-form . . . . . . . . . . . . . . . . . . . 11
	3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11		3.2.4. asterisk-form . . . . . . . . . . . . . . . . . . . . 11
	3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12		3.3. Effective Request URI . . . . . . . . . . . . . . . . . . 12
	4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Status Line . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Header Fields . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. 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 . . . . . . . . . . . . . . . . . . 23
	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 . . . . . . . . . . . . 25
	7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25		7.3. Transfer Coding Registry . . . . . . . . . . . . . . . . 25
	7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26		7.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27		8. Handling Incomplete Messages . . . . . . . . . . . . . . . . 27
	9. Connection Management . . . . . . . . . . . . . . . . . . . . 28		9. Connection Management . . . . . . . . . . . . . . . . . . . . 28
	9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28		9.1. Connection . . . . . . . . . . . . . . . . . . . . . . . 28
	9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30		9.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 30
	9.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30		9.3. Associating a Response to a Request . . . . . . . . . . . 30
	9.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31		9.4. Persistence . . . . . . . . . . . . . . . . . . . . . . . 30
	9.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 31		9.4.1. Retrying Requests . . . . . . . . . . . . . . . . . . 31
	9.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32		9.4.2. Pipelining . . . . . . . . . . . . . . . . . . . . . 32
	9.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33		9.5. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 32
	9.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 33		9.6. Failures and Timeouts . . . . . . . . . . . . . . . . . . 33
	9.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 34		9.7. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.7.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 36		9.8. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 35
	9.7.2. Upgrade Token Registry . . . . . . . . . . . . . . . 37		9.8.1. Upgrade Protocol Names . . . . . . . . . . . . . . . 37
	10. Enclosing Messages as Data . . . . . . . . . . . . . . . . . 37		9.8.2. Upgrade Token Registry . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 41		11.3. Message Integrity . . . . . . . . . . . . . . . . . . . 42
	11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42		11.4. Message Confidentiality . . . . . . . . . . . . . . . . 42
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	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 . . . . . . . . . . . . . . 42		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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 52		C.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 53
	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
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54		D.4. Since draft-ietf-httpbis-messaging-02 . . . . . . . . . . 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 11, line 6 ¶		skipping to change at page 11, line 6 ¶
	When making a request to a proxy, other than a CONNECT or server-wide		When making a request to a proxy, other than a CONNECT or server-wide
	OPTIONS request (as detailed below), a client MUST send the target		OPTIONS request (as detailed below), a client MUST send the target
	URI in absolute-form as the request-target.		URI in absolute-form as the request-target.
	absolute-form = absolute-URI		absolute-form = absolute-URI
	The proxy is requested to either service that request from a valid		The proxy is requested to either service that request from a valid
	cache, if possible, or make the same request on the client's behalf		cache, if possible, or make the same request on the client's behalf
	to either the next inbound proxy server or directly to the origin		to either the next inbound proxy server or directly to the origin
	server indicated by the request-target. Requirements on such		server indicated by the request-target. Requirements on such
	"forwarding" of messages are defined in Section 5.6 of [Semantics].		"forwarding" of messages are defined in Section 5.5 of [Semantics].
	An example absolute-form of request-line would be:		An example absolute-form of request-line would be:
	GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1		GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
	To allow for transition to the absolute-form for all requests in some		To allow for transition to the absolute-form for all requests in some
	future version of HTTP, a server MUST accept the absolute-form in		future version of HTTP, a server MUST accept the absolute-form in
	requests, even though HTTP/1.1 clients will only send them in		requests, even though HTTP/1.1 clients will only send them in
	requests to proxies.		requests to proxies.
	skipping to change at page 14, line 20 ¶		skipping to change at page 14, line 20 ¶
	status codes, including the classes of status code (indicated by the		status codes, including the classes of status code (indicated by the
	first digit), the status codes defined by this specification,		first digit), the status codes defined by this specification,
	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. A client SHOULD		more frequently used with interactive text clients.
	ignore the reason-phrase content.
			A client SHOULD ignore the reason-phrase content because it is not a
			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 )		reason-phrase = *( HTAB / SP / VCHAR / obs-text )
	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
	skipping to change at page 14, line 47 ¶		skipping to change at page 14, line 51 ¶
	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 | Protocol | Status | Reference |
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	| Connection | http | standard | Section 9.1 |		| Connection | http | standard | Section 9.1 |
	| MIME-Version | http | standard | Appendix B.1 |		| MIME-Version | http | standard | Appendix B.1 |
	| TE | http | standard | Section 7.4 |		| TE | http | standard | Section 7.4 |
	| Transfer-Encoding | http | standard | Section 6.1 |		| Transfer-Encoding | http | standard | Section 6.1 |
	| Upgrade | http | standard | Section 9.7 |		| Upgrade | http | 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 15, line 11 ¶		skipping to change at page 15, line 14 ¶
	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 |
	+-------------------+----------+----------+------------+		+-------------------+----------+----------+------------+
	5.1. Field Parsing		5.1. Header Field Parsing
	Messages are parsed using a generic algorithm, independent of the		Messages are parsed using a generic algorithm, independent of the
	individual header field names. The contents within a given field		individual header field names. The contents within a given field
	value are not parsed until a later stage of message interpretation		value are not parsed until a later stage of message interpretation
	(usually after the message's entire header section has been		(usually after the message's entire header section has been
	processed).		processed).
	No whitespace is allowed between the header field-name and colon. In		No whitespace is allowed between the header field-name and colon. In
	the past, differences in the handling of such whitespace have led to		the past, differences in the handling of such whitespace have led to
	security vulnerabilities in request routing and response handling. A		security vulnerabilities in request routing and response handling. A
	skipping to change at page 15, line 45 ¶		skipping to change at page 15, line 48 ¶
	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 = CRLF 1*( SP / HTAB )
	; 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
	explaining that obsolete line folding is unacceptable, or replace		explaining that obsolete line folding is unacceptable, or replace
	skipping to change at page 29, line 49 ¶		skipping to change at page 29, line 49 ¶
	that field-name for anything else.		that field-name for anything else.
	The "close" connection option is defined for a sender to signal that		The "close" connection option is defined for a sender to signal that
	this connection will be closed after completion of the response. For		this connection will be closed after completion of the response. For
	example,		example,
	Connection: close		Connection: close
	in either the request or the response header fields indicates that		in either the request or the response header fields indicates that
	the sender is going to close the connection after the current		the sender is going to close the connection after the current
	request/response is complete (Section 9.6).		request/response is complete (Section 9.7).
	A client that does not support persistent connections MUST send the		A client that does not support persistent connections MUST send the
	"close" connection option in every request message.		"close" connection option in every request message.
	A server that does not support persistent connections MUST send the		A server that does not support persistent connections MUST send the
	"close" connection option in every response message that does not		"close" connection option in every response message that does not
	have a 1xx (Informational) status code.		have a 1xx (Informational) status code.
	9.2. Establishment		9.2. Establishment
	It is beyond the scope of this specification to describe how		It is beyond the scope of this specification to describe how
	connections are established via various transport- or session-layer		connections are established via various transport- or session-layer
	protocols. Each connection applies to only one transport link.		protocols. Each connection applies to only one transport link.
	9.3. Persistence		9.3. Associating a Response to a Request
			HTTP/1.1 does not include a request identifier for associating a
			given request message with its corresponding one or more response
			messages. Hence, it relies on the order of response arrival to
			correspond exactly to the order in which requests are made on the
			same connection. More than one response message per request only
			occurs when one or more informational responses (1xx, see Section 9.2
			of [Semantics]) precede a final response to the same request.
			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 associate each received response message on that connection to
			the highest ordered request that has not yet received a final (non-
			1xx) response.
			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
	Connection header field (if any):		Connection header field (if any):
	skipping to change at page 31, line 13 ¶		skipping to change at page 31, line 30 ¶
	reuse the same connection for a subsequent request.		reuse the same connection for a subsequent request.
	A proxy server MUST NOT maintain a persistent connection with an		A proxy server MUST NOT maintain a persistent connection with an
	HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and		HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
	discussion of the problems with the Keep-Alive header field		discussion of the problems with the Keep-Alive header field
	implemented by many HTTP/1.0 clients).		implemented by many HTTP/1.0 clients).
	See Appendix C.1.2 for more information on backwards compatibility		See Appendix C.1.2 for more information on backwards compatibility
	with HTTP/1.0 clients.		with HTTP/1.0 clients.
	9.3.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]). A proxy MUST NOT automatically retry
	non-idempotent requests.		non-idempotent requests.
	skipping to change at page 31, line 40 ¶		skipping to change at page 32, line 9 ¶
	that a POST request to a given resource is safe can repeat that		that a POST request to a given resource is safe can repeat that
	request automatically. Likewise, a user agent designed specifically		request automatically. Likewise, a user agent designed specifically
	to operate on a version control repository might be able to recover		to operate on a version control repository might be able to recover
	from partial failure conditions by checking the target resource		from partial failure conditions by checking the target resource
	revision(s) after a failed connection, reverting or fixing any		revision(s) after a failed connection, reverting or fixing any
	changes that were partially applied, and then automatically retrying		changes that were partially applied, and then automatically retrying
	the requests that failed.		the requests that failed.
	A client SHOULD NOT automatically retry a failed automatic retry.		A client SHOULD NOT automatically retry a failed automatic retry.
	9.3.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.
	A client that pipelines requests SHOULD retry unanswered requests if		A client that pipelines requests SHOULD retry unanswered requests if
	the connection closes before it receives all of the corresponding		the connection closes before it receives all of the corresponding
	responses. When retrying pipelined requests after a failed		responses. When retrying pipelined requests after a failed
	connection (a connection not explicitly closed by the server in its		connection (a connection not explicitly closed by the server in its
	last complete response), a client MUST NOT pipeline immediately after		last complete response), a client MUST NOT pipeline immediately after
	connection establishment, since the first remaining request in the		connection establishment, since the first remaining request in the
	prior pipeline might have caused an error response that can be lost		prior pipeline might have caused an error response that can be lost
	again if multiple requests are sent on a prematurely closed		again if multiple requests are sent on a prematurely closed
	connection (see the TCP reset problem described in Section 9.6).		connection (see the TCP reset problem described in Section 9.7).
	Idempotent methods (Section 7.2.2 of [Semantics]) are significant to		Idempotent methods (Section 7.2.2 of [Semantics]) are significant to
	pipelining because they can be automatically retried after a		pipelining because they can be automatically retried after a
	connection failure. A user agent SHOULD NOT pipeline requests after		connection failure. A user agent SHOULD NOT pipeline requests after
	a non-idempotent method, until the final response status code for		a non-idempotent method, until the final response status code for
	that method has been received, unless the user agent has a means to		that method has been received, unless the user agent has a means to
	detect and recover from partial failure conditions involving the		detect and recover from partial failure conditions involving the
	pipelined sequence.		pipelined sequence.
	An intermediary that receives pipelined requests MAY pipeline those		An intermediary that receives pipelined requests MAY pipeline those
	requests when forwarding them inbound, since it can rely on the		requests when forwarding them inbound, since it can rely on the
	outbound user agent(s) to determine what requests can be safely		outbound user agent(s) to determine what requests can be safely
	pipelined. If the inbound connection fails before receiving a		pipelined. If the inbound connection fails before receiving a
	response, the pipelining intermediary MAY attempt to retry a sequence		response, the pipelining intermediary MAY attempt to retry a sequence
	of requests that have yet to receive a response if the requests all		of requests that have yet to receive a response if the requests all
	have idempotent methods; otherwise, the pipelining intermediary		have idempotent methods; otherwise, the pipelining intermediary
	SHOULD forward any received responses and then close the		SHOULD forward any received responses and then close the
	corresponding outbound connection(s) so that the outbound user		corresponding outbound connection(s) so that the outbound user
	agent(s) can recover accordingly.		agent(s) can recover accordingly.
	9.4. Concurrency		9.5. Concurrency
	A client ought to limit the number of simultaneous open connections		A client ought to limit the number of simultaneous open connections
	that it maintains to a given server.		that it maintains to a given server.
	Previous revisions of HTTP gave a specific number of connections as a		Previous revisions of HTTP gave a specific number of connections as a
	ceiling, but this was found to be impractical for many applications.		ceiling, but this was found to be impractical for many applications.
	As a result, this specification does not mandate a particular maximum		As a result, this specification does not mandate a particular maximum
	number of connections but, instead, encourages clients to be		number of connections but, instead, encourages clients to be
	conservative when opening multiple connections.		conservative when opening multiple connections.
	skipping to change at page 33, line 5 ¶		skipping to change at page 33, line 22 ¶
	blocking" problem, wherein a request that takes significant server-		blocking" problem, wherein a request that takes significant server-
	side processing and/or has a large payload blocks subsequent requests		side processing and/or has a large payload blocks subsequent requests
	on the same connection. However, each connection consumes server		on the same connection. However, each connection consumes server
	resources. Furthermore, using multiple connections can cause		resources. Furthermore, using multiple connections can cause
	undesirable side effects in congested networks.		undesirable side effects in congested networks.
	Note that a server might reject traffic that it deems abusive or		Note that a server might reject traffic that it deems abusive or
	characteristic of a denial-of-service attack, such as an excessive		characteristic of a denial-of-service attack, such as an excessive
	number of open connections from a single client.		number of open connections from a single client.
	9.5. Failures and Timeouts		9.6. Failures and Timeouts
	Servers will usually have some timeout value beyond which they will		Servers will usually have some timeout value beyond which they will
	no longer maintain an inactive connection. Proxy servers might make		no longer maintain an inactive connection. Proxy servers might make
	this a higher value since it is likely that the client will be making		this a higher value since it is likely that the client will be making
	more connections through the same proxy server. The use of		more connections through the same proxy server. The use of
	persistent connections places no requirements on the length (or		persistent connections places no requirements on the length (or
	existence) of this timeout for either the client or the server.		existence) of this timeout for either the client or the server.
	A client or server that wishes to time out SHOULD issue a graceful		A client or server that wishes to time out SHOULD issue a graceful
	close on the connection. Implementations SHOULD constantly monitor		close on the connection. Implementations SHOULD constantly monitor
	skipping to change at page 33, line 40 ¶		skipping to change at page 34, line 8 ¶
	expectation that clients will retry. The latter technique can		expectation that clients will retry. The latter technique can
	exacerbate network congestion.		exacerbate network congestion.
	A client sending a message body SHOULD monitor the network connection		A client sending a message body SHOULD monitor the network connection
	for an error response while it is transmitting the request. If the		for an error response while it is transmitting the request. If the
	client sees a response that indicates the server does not wish to		client sees a response that indicates the server does not wish to
	receive the message body and is closing the connection, the client		receive the message body and is closing the connection, the client
	SHOULD immediately cease transmitting the body and close its side of		SHOULD immediately cease transmitting the body and close its side of
	the connection.		the connection.
	9.6. Tear-down		9.7. Tear-down
	The Connection header field (Section 9.1) provides a "close"		The Connection header field (Section 9.1) provides a "close"
	connection option that a sender SHOULD send when it wishes to close		connection option that a sender SHOULD send when it wishes to close
	the connection after the current request/response pair.		the connection after the current request/response pair.
	A client that sends a "close" connection option MUST NOT send further		A client that sends a "close" connection option MUST NOT send further
	requests on that connection (after the one containing "close") and		requests on that connection (after the one containing "close") and
	MUST close the connection after reading the final response message		MUST close the connection after reading the final response message
	corresponding to this request.		corresponding to this request.
	skipping to change at page 34, line 42 ¶		skipping to change at page 35, line 11 ¶
	the write side of the read/write connection. The server then		the write side of the read/write connection. The server then
	continues to read from the connection until it receives a		continues to read from the connection until it receives a
	corresponding close by the client, or until the server is reasonably		corresponding close by the client, or until the server is reasonably
	certain that its own TCP stack has received the client's		certain that its own TCP stack has received the client's
	acknowledgement of the packet(s) containing the server's last		acknowledgement of the packet(s) containing the server's last
	response. Finally, the server fully closes the connection.		response. Finally, the server fully closes the connection.
	It is unknown whether the reset problem is exclusive to TCP or might		It is unknown whether the reset problem is exclusive to TCP or might
	also be found in other transport connection protocols.		also be found in other transport connection protocols.
	9.7. 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. A client MAY send a list of protocols in the Upgrade
	header field of a request to invite the server to switch to one or		header field of a request to invite the server to switch to one or
	more of those protocols, in order of descending preference, before		more of those 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.
	skipping to change at page 36, line 44 ¶		skipping to change at page 37, line 17 ¶
	server MUST send a 100 (Continue) response before sending a 101		server MUST send a 100 (Continue) response before sending a 101
	(Switching Protocols) response.		(Switching Protocols) response.
	The Upgrade header field only applies to switching protocols on top		The Upgrade header field only applies to switching protocols on top
	of the existing connection; it cannot be used to switch the		of the existing connection; it cannot be used to switch the
	underlying connection (transport) protocol, nor to switch the		underlying connection (transport) protocol, nor to switch the
	existing communication to a different connection. For those		existing communication to a different connection. For those
	purposes, it is more appropriate to use a 3xx (Redirection) response		purposes, it is more appropriate to use a 3xx (Redirection) response
	(Section 9.4 of [Semantics]).		(Section 9.4 of [Semantics]).
	9.7.1. Upgrade Protocol Names		9.8.1. Upgrade Protocol Names
	This specification only defines the protocol name "HTTP" for use by		This specification only defines the protocol name "HTTP" for use by
	the family of Hypertext Transfer Protocols, as defined by the HTTP		the family of Hypertext Transfer Protocols, as defined by the HTTP
	version rules of Section 3.5 of [Semantics] and future updates to		version rules of Section 3.5 of [Semantics] and future updates to
	this specification. Additional protocol names ought to be registered		this specification. Additional protocol names ought to be registered
	using the registration procedure defined in Section 9.7.2.		using the registration procedure defined in Section 9.8.2.
	+------+-------------------+--------------------+-------------------+		+------+-------------------+--------------------+-------------------+
	| Name | Description | Expected Version | Reference |		| Name | Description | Expected Version | Reference |
	| | | Tokens | |		| | | Tokens | |
	+------+-------------------+--------------------+-------------------+		+------+-------------------+--------------------+-------------------+
	| HTTP | Hypertext | any DIGIT.DIGIT | Section 3.5 of |		| HTTP | Hypertext | any DIGIT.DIGIT | Section 3.5 of |
	| | Transfer Protocol | (e.g, "2.0") | [Semantics] |		| | Transfer Protocol | (e.g, "2.0") | [Semantics] |
	+------+-------------------+--------------------+-------------------+		+------+-------------------+--------------------+-------------------+
	9.7.2. Upgrade Token Registry		9.8.2. Upgrade Token Registry
	The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"		The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
	defines the namespace for protocol-name tokens used to identify		defines the namespace for protocol-name tokens used to identify
	protocols in the Upgrade header field. The registry is maintained at		protocols in the Upgrade header field. The registry is maintained at
	<https://www.iana.org/assignments/http-upgrade-tokens>.		<https://www.iana.org/assignments/http-upgrade-tokens>.
	Each registered protocol name is associated with contact information		Each registered protocol name is associated with contact information
	and an optional set of specifications that details how the connection		and an optional set of specifications that details how the connection
	will be processed after it has been upgraded.		will be processed after it has been upgraded.
	skipping to change at page 43, line 9 ¶		skipping to change at page 43, line 30 ¶
	Please update the "HTTP Transfer Coding Registry" at		Please update the "HTTP Transfer Coding Registry" at
	<https://www.iana.org/assignments/http-parameters/> with the		<https://www.iana.org/assignments/http-parameters/> with the
	registration procedure of Section 7.3 and the content coding names		registration procedure of Section 7.3 and the content coding names
	summarized in the table of Section 7.		summarized in the table of Section 7.
	12.4. Upgrade Token Registration		12.4. Upgrade Token Registration
	Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token		Please update the "Hypertext Transfer Protocol (HTTP) Upgrade Token
	Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>		Registry" at <https://www.iana.org/assignments/http-upgrade-tokens>
	with the registration procedure of Section 9.7.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.7.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-02 (work in		Ed., "HTTP Caching", draft-ietf-httpbis-cache-03 (work in
	progress), July 2018.		progress), October 2018.
	[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 43, line 51 ¶		skipping to change at page 44, line 27 ¶
	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>.
	[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-02		Ed., "HTTP Semantics", draft-ietf-httpbis-semantics-03
	(work in progress), July 2018.		(work in progress), October 2018.
	[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 53, line 34 ¶		skipping to change at page 54, line 34 ¶
	<https://www.rfc-editor.org/errata/eid4839>)		<https://www.rfc-editor.org/errata/eid4839>)
	o Resolved erratum 4225, no change needed here		o Resolved erratum 4225, no change needed here
	(<https://github.com/httpwg/http-core/issues/90>,		(<https://github.com/httpwg/http-core/issues/90>,
	<https://www.rfc-editor.org/errata/eid4225>)		<https://www.rfc-editor.org/errata/eid4225>)
	o Replace "response code" with "response status code"		o Replace "response code" with "response status code"
	(<https://github.com/httpwg/http-core/issues/94>,		(<https://github.com/httpwg/http-core/issues/94>,
	<https://www.rfc-editor.org/errata/eid4050>)		<https://www.rfc-editor.org/errata/eid4050>)
	o In Section 9.3, clarify statement about HTTP/1.0 keep-alive		o In Section 9.4, clarify statement about HTTP/1.0 keep-alive
	(<https://github.com/httpwg/http-core/issues/96>,		(<https://github.com/httpwg/http-core/issues/96>,
	<https://www.rfc-editor.org/errata/eid4205>)		<https://www.rfc-editor.org/errata/eid4205>)
	o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="		o In Section 7.1.1, re-introduce (bad) whitespace around ";" and "="
	(<https://github.com/httpwg/http-core/issues/101>,		(<https://github.com/httpwg/http-core/issues/101>,
	<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-		<https://www.rfc-editor.org/errata/eid4667>, <https://www.rfc-
	editor.org/errata/eid4825>)		editor.org/errata/eid4825>)
	o In Section 7.3, state that transfer codings should not use		o In Section 7.3, state that transfer codings should not use
	parameters named "q" (<https://github.com/httpwg/http-core/		parameters named "q" (<https://github.com/httpwg/http-core/
	issues/15>, <https://www.rfc-editor.org/errata/eid4683>)		issues/15>, <https://www.rfc-editor.org/errata/eid4683>)
	o In Section 7, mark coding name "trailers" as reserved in the IANA		o In Section 7, mark coding name "trailers" as reserved in the IANA
	registry (<https://github.com/httpwg/http-core/issues/108>)		registry (<https://github.com/httpwg/http-core/issues/108>)
			D.4. Since draft-ietf-httpbis-messaging-02
			o In Section 4, explain why the reason phrase should be ignored by
			clients (<https://github.com/httpwg/http-core/issues/60>).
			o Add Section 9.3 to explain how request/response correlation is
			performed (<https://github.com/httpwg/http-core/issues/145>)
	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, 33		Connection header field 28, 34
	Content-Length header field 18		Content-Length header field 18
	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 28, 34
	compress (transfer coding) 25		compress (transfer coding) 25
	D		D
	deflate (transfer coding) 25		deflate (transfer coding) 25
	E		E
	effective request URI 12		effective request URI 12
	G		G
	Grammar		Grammar
	skipping to change at page 55, line 40 ¶		skipping to change at page 56, line 48 ¶
	Upgrade 35		Upgrade 35
	VCHAR 5		VCHAR 5
	gzip (transfer coding) 25		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 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
	skipping to change at page 56, line 10 ¶		skipping to change at page 57, line 19 ¶
	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 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) 25		x-compress (transfer coding) 25
	x-gzip (transfer coding) 25		x-gzip (transfer coding) 25
	Acknowledgments		Acknowledgments
	See Appendix "Acknowledgments" of [Semantics].		See Appendix "Acknowledgments" of [Semantics].
	Authors' Addresses		Authors' Addresses
End of changes. 39 change blocks.
	72 lines changed or deleted		102 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/