p1-messaging.unpg.txt		rfc7230-to-be.unpg.txt
	HTTPbis Working Group R. Fielding, Ed.		Internet Engineering Task Force (IETF) R. Fielding, Ed.
	Internet-Draft Adobe		Request for Comments: 7230 Adobe
	Obsoletes: 2145, 2616 J. Reschke, Ed.		Obsoletes: 2145, 2616 J. Reschke, Ed.
	(if approved) greenbytes		Updates: 2817, 2818 greenbytes
	Updates: 2817, 2818 (if approved) May 7, 2014		Category: Standards Track May 2014
	Intended status: Standards Track		ISSN: 2070-1721
	Expires: November 8, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing		Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
	draft-ietf-httpbis-p1-messaging-latest
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is a stateless application-		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	level protocol for distributed, collaborative, hypertext information		level protocol for distributed, collaborative, hypertext information
	systems. This document provides an overview of HTTP architecture and		systems. This document provides an overview of HTTP architecture and
	its associated terminology, defines the "http" and "https" Uniform		its associated terminology, defines the "http" and "https" Uniform
	Resource Identifier (URI) schemes, defines the HTTP/1.1 message		Resource Identifier (URI) schemes, defines the HTTP/1.1 message
	syntax and parsing requirements, and describes related security		syntax and parsing requirements, and describes related security
	concerns for implementations.		concerns for implementations.
	Editorial Note (To be removed by RFC Editor)
	Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.
	_This is a temporary document for the purpose of tracking the
	editorial changes made during the AUTH48 (RFC publication) phase._
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 5741.
	This Internet-Draft will expire on November 8, 2014.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7230.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 4, line 4		skipping to change at page 3, line 32
	5.6. Associating a Response to a Request . . . . . . . . . . . 46		5.6. Associating a Response to a Request . . . . . . . . . . . 46
	5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46		5.7. Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
	5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47		5.7.1. Via . . . . . . . . . . . . . . . . . . . . . . . . . 47
	5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48		5.7.2. Transformations . . . . . . . . . . . . . . . . . . . 48
	6. Connection Management . . . . . . . . . . . . . . . . . . . . 49		6. Connection Management . . . . . . . . . . . . . . . . . . . . 49
	6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50		6.1. Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
	6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51		6.2. Establishment . . . . . . . . . . . . . . . . . . . . . . 51
	6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52		6.3. Persistence . . . . . . . . . . . . . . . . . . . . . . . 52
	6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53		6.3.1. Retrying Requests . . . . . . . . . . . . . . . . . . 53
	6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53		6.3.2. Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
	6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54		6.4. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 54
	6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54		6.5. Failures and Timeouts . . . . . . . . . . . . . . . . . . 54
	6.6. Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55		6.6. Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
	6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56		6.7. Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . 56
	7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58		7. ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
	8.1. Header Field Registration . . . . . . . . . . . . . . . . 60		8.1. Header Field Registration . . . . . . . . . . . . . . . . 60
	8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60		8.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 60
	8.3. Internet Media Type Registration . . . . . . . . . . . . . 61		8.3. Internet Media Type Registration . . . . . . . . . . . . . 61
	8.3.1. Internet Media Type message/http . . . . . . . . . . . 61		8.3.1. Internet Media Type message/http . . . . . . . . . . . 61
	8.3.2. Internet Media Type application/http . . . . . . . . . 62		8.3.2. Internet Media Type application/http . . . . . . . . . 62
	8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63		8.4. Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
	8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63		8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 63
	skipping to change at page 4, line 37		skipping to change at page 4, line 16
	9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68		9.4. Response Splitting . . . . . . . . . . . . . . . . . . . . 68
	9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69		9.5. Request Smuggling . . . . . . . . . . . . . . . . . . . . 69
	9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69		9.6. Message Integrity . . . . . . . . . . . . . . . . . . . . 69
	9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70		9.7. Message Confidentiality . . . . . . . . . . . . . . . . . 70
	9.8. Privacy of Server Log Information . . . . . . . . . . . . 70		9.8. Privacy of Server Log Information . . . . . . . . . . . . 70
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 71
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 72		11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
	11.2. Informative References . . . . . . . . . . . . . . . . . . 74		11.2. Informative References . . . . . . . . . . . . . . . . . . 74
	Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76		Appendix A. HTTP Version History . . . . . . . . . . . . . . . . 76
	A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 77		A.1. Changes from HTTP/1.0 . . . . . . . . . . . . . . . . . . 76
	A.1.1. Multi-homed Web Servers . . . . . . . . . . . . . . . 77		A.1.1. Multihomed Web Servers . . . . . . . . . . . . . . . . 77
	A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77		A.1.2. Keep-Alive Connections . . . . . . . . . . . . . . . . 77
	A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78		A.1.3. Introduction of Transfer-Encoding . . . . . . . . . . 78
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 78
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 80
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
	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
	skipping to change at page 5, line 26		skipping to change at page 5, line 26
	RFC 7231: Semantics and Content		RFC 7231: Semantics and Content
	RFC 7232: Conditional Requests		RFC 7232: Conditional Requests
	RFC 7233: Range Requests		RFC 7233: Range Requests
	RFC 7234: Caching		RFC 7234: Caching
	RFC 7235: Authentication		RFC 7235: Authentication
	This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP		This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
	versioning). This specification also updates the use of CONNECT to		HTTP versioning). This specification also updates the use of
	establish a tunnel, previously defined in RFC 2817, and defines the		CONNECT, previously defined in RFC 2817, to establish a tunnel, and
	"https" URI scheme that was described informally in RFC 2818.		defines the "https" URI scheme that was described informally in RFC
			2818.
	HTTP is a generic interface protocol for information systems. It is		HTTP is a generic interface protocol for information systems. It is
	designed to hide the details of how a service is implemented by		designed to hide the details of how a service is implemented by
	presenting a uniform interface to clients that is independent of the		presenting a uniform interface to clients that is independent of the
	types of resources provided. Likewise, servers do not need to be		types of resources provided. Likewise, servers do not need to be
	aware of each client's purpose: an HTTP request can be considered in		aware of each client's purpose: an HTTP request can be considered in
	isolation rather than being associated with a specific type of client		isolation rather than being associated with a specific type of client
	or a predetermined sequence of application steps. The result is a		or a predetermined sequence of application steps. The result is a
	protocol that can be used effectively in many different contexts and		protocol that can be used effectively in many different contexts and
	for which implementations can evolve independently over time.		for which implementations can evolve independently over time.
	skipping to change at page 7, line 8		skipping to change at page 7, line 9
	2. Architecture		2. Architecture
	HTTP was created for the World Wide Web (WWW) architecture and has		HTTP was created for the World Wide Web (WWW) architecture and has
	evolved over time to support the scalability needs of a worldwide		evolved over time to support the scalability needs of a worldwide
	hypertext system. Much of that architecture is reflected in the		hypertext system. Much of that architecture is reflected in the
	terminology and syntax productions used to define HTTP.		terminology and syntax productions used to define HTTP.
	2.1. Client/Server Messaging		2.1. Client/Server Messaging
	HTTP is a stateless request/response protocol that operates by		HTTP is a stateless request/response protocol that operates by
	exchanging messages (Section 3) across a reliable transport or		exchanging messages (Section 3) across a reliable transport- or
	session-layer "connection" (Section 6). An HTTP "client" is a		session-layer "connection" (Section 6). An HTTP "client" is a
	program that establishes a connection to a server for the purpose of		program that establishes a connection to a server for the purpose of
	sending one or more HTTP requests. An HTTP "server" is a program		sending one or more HTTP requests. An HTTP "server" is a program
	that accepts connections in order to service HTTP requests by sending		that accepts connections in order to service HTTP requests by sending
	HTTP responses.		HTTP responses.
	The terms "client" and "server" refer only to the roles that these		The terms "client" and "server" refer only to the roles that these
	programs perform for a particular connection. The same program might		programs perform for a particular connection. The same program might
	act as a client on some connections and a server on others. The term		act as a client on some connections and a server on others. The term
	"user agent" refers to any of the various client programs that		"user agent" refers to any of the various client programs that
	skipping to change at page 10, line 36		skipping to change at page 10, line 39
	Gateways are often used to encapsulate legacy or untrusted		Gateways are often used to encapsulate legacy or untrusted
	information services, to improve server performance through		information services, to improve server performance through
	"accelerator" caching, and to enable partitioning or load balancing		"accelerator" caching, and to enable partitioning or load balancing
	of HTTP services across multiple machines.		of HTTP services across multiple machines.
	All HTTP requirements applicable to an origin server also apply to		All HTTP requirements applicable to an origin server also apply to
	the outbound communication of a gateway. A gateway communicates with		the outbound communication of a gateway. A gateway communicates with
	inbound servers using any protocol that it desires, including private		inbound servers using any protocol that it desires, including private
	extensions to HTTP that are outside the scope of this specification.		extensions to HTTP that are outside the scope of this specification.
	However, an HTTP-to-HTTP gateway that wishes to interoperate with		However, an HTTP-to-HTTP gateway that wishes to interoperate with
	third-party HTTP servers ought to conform to user agent requirements		third-party HTTP servers ought to conform to user-agent requirements
	on the gateway's inbound connection.		on the gateway's inbound connection.
	A "tunnel" acts as a blind relay between two connections without		A "tunnel" acts as a blind relay between two connections without
	changing the messages. Once active, a tunnel is not considered a		changing the messages. Once active, a tunnel is not considered a
	party to the HTTP communication, though the tunnel might have been		party to the HTTP communication, though the tunnel might have been
	initiated by an HTTP request. A tunnel ceases to exist when both		initiated by an HTTP request. A tunnel ceases to exist when both
	ends of the relayed connection are closed. Tunnels are used to		ends of the relayed connection are closed. Tunnels are used to
	extend a virtual connection through an intermediary, such as when		extend a virtual connection through an intermediary, such as when
	Transport Layer Security (TLS, [RFC5246]) is used to establish		Transport Layer Security (TLS, [RFC5246]) is used to establish
	confidential communication through a shared firewall proxy.		confidential communication through a shared firewall proxy.
	skipping to change at page 11, line 22		skipping to change at page 11, line 25
	interception proxy filters or redirects outgoing TCP port 80 packets		interception proxy filters or redirects outgoing TCP port 80 packets
	(and occasionally other common port traffic). Interception proxies		(and occasionally other common port traffic). Interception proxies
	are commonly found on public network access points, as a means of		are commonly found on public network access points, as a means of
	enforcing account subscription prior to allowing use of non-local		enforcing account subscription prior to allowing use of non-local
	Internet services, and within corporate firewalls to enforce network		Internet services, and within corporate firewalls to enforce network
	usage policies.		usage policies.
	HTTP is defined as a stateless protocol, meaning that each request		HTTP is defined as a stateless protocol, meaning that each request
	message can be understood in isolation. Many implementations depend		message can be understood in isolation. Many implementations depend
	on HTTP's stateless design in order to reuse proxied connections or		on HTTP's stateless design in order to reuse proxied connections or
	dynamically load-balance requests across multiple servers. Hence, a		dynamically load balance requests across multiple servers. Hence, a
	server MUST NOT assume that two requests on the same connection are		server MUST NOT assume that two requests on the same connection are
	from the same user agent unless the connection is secured and		from the same user agent unless the connection is secured and
	specific to that agent. Some non-standard HTTP extensions (e.g.,		specific to that agent. Some non-standard HTTP extensions (e.g.,
	[RFC4559]) have been known to violate this requirement, resulting in		[RFC4559]) have been known to violate this requirement, resulting in
	security and interoperability problems.		security and interoperability problems.
	2.4. Caches		2.4. Caches
	A "cache" is a local store of previous response messages and the		A "cache" is a local store of previous response messages and the
	subsystem that controls its message storage, retrieval, and deletion.		subsystem that controls its message storage, retrieval, and deletion.
	skipping to change at page 13, line 49		skipping to change at page 14, line 4
	2.6. Protocol Versioning		2.6. Protocol Versioning
	HTTP uses a "<major>.<minor>" numbering scheme to indicate versions		HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
	of the protocol. This specification defines version "1.1". The		of the protocol. This specification defines version "1.1". The
	protocol version as a whole indicates the sender's conformance with		protocol version as a whole indicates the sender's conformance with
	the set of requirements laid out in that version's corresponding		the set of requirements laid out in that version's corresponding
	specification of HTTP.		specification of HTTP.
	The version of an HTTP message is indicated by an HTTP-version field		The version of an HTTP message is indicated by an HTTP-version field
	in the first line of the message. HTTP-version is case-sensitive.		in the first line of the message. HTTP-version is case sensitive.
	HTTP-version = HTTP-name "/" DIGIT "." DIGIT		HTTP-version = HTTP-name "/" DIGIT "." DIGIT
	HTTP-name = %x48.54.54.50 ; "HTTP", case-sensitive		HTTP-name = %x48.54.54.50 ; "HTTP", case sensitive
	The HTTP version number consists of two decimal digits separated by a		The HTTP version number consists of two decimal digits separated by a
	"." (period or decimal point). The first digit ("major version")		"." (period or decimal point). The first digit ("major version")
	indicates the HTTP messaging syntax, whereas the second digit ("minor		indicates the HTTP messaging syntax, whereas the second digit ("minor
	version") indicates the highest minor version within that major		version") indicates the highest minor version within that major
	version to which the sender is conformant and able to understand for		version to which the sender is conformant and able to understand for
	future communication. The minor version advertises the sender's		future communication. The minor version advertises the sender's
	communication capabilities even when the sender is only using a		communication capabilities even when the sender is only using a
	backwards-compatible subset of the protocol, thereby letting the		backwards-compatible subset of the protocol, thereby letting the
	recipient know that more advanced features can be used in response		recipient know that more advanced features can be used in response
	skipping to change at page 14, line 36		skipping to change at page 14, line 39
	The interpretation of a header field does not change between minor		The interpretation of a header field does not change between minor
	versions of the same major HTTP version, though the default behavior		versions of the same major HTTP version, though the default behavior
	of a recipient in the absence of such a field can change. Unless		of a recipient in the absence of such a field can change. Unless
	specified otherwise, header fields defined in HTTP/1.1 are defined		specified otherwise, header fields defined in HTTP/1.1 are defined
	for all versions of HTTP/1.x. In particular, the Host and Connection		for all versions of HTTP/1.x. In particular, the Host and Connection
	header fields ought to be implemented by all HTTP/1.x implementations		header fields ought to be implemented by all HTTP/1.x implementations
	whether or not they advertise conformance with HTTP/1.1.		whether or not they advertise conformance with HTTP/1.1.
	New header fields can be introduced without changing the protocol		New header fields can be introduced without changing the protocol
	version if their defined semantics allow them to be safely ignored by		version if their defined semantics allow them to be safely ignored by
	recipients that do not recognize them. Header field extensibility is		recipients that do not recognize them. Header-field extensibility is
	discussed in Section 3.2.1.		discussed in Section 3.2.1.
	Intermediaries that process HTTP messages (i.e., all intermediaries		Intermediaries that process HTTP messages (i.e., all intermediaries
	other than those acting as tunnels) MUST send their own HTTP-version		other than those acting as tunnels) MUST send their own HTTP-version
	in forwarded messages. In other words, they are not allowed to		in forwarded messages. In other words, they are not allowed to
	blindly forward the first line of an HTTP message without ensuring		blindly forward the first line of an HTTP message without ensuring
	that the protocol version in that message matches a version to which		that the protocol version in that message matches a version to which
	that intermediary is conformant for both the receiving and sending of		that intermediary is conformant for both the receiving and sending of
	messages. Forwarding an HTTP message without rewriting the HTTP-		messages. Forwarding an HTTP message without rewriting the HTTP-
	version might result in communication errors when downstream		version might result in communication errors when downstream
	skipping to change at page 15, line 48		skipping to change at page 15, line 51
	introduced between [RFC2068] and [RFC2616], and this revision has		introduced between [RFC2068] and [RFC2616], and this revision has
	specifically avoided any such changes to the protocol.		specifically avoided any such changes to the protocol.
	When an HTTP message is received with a major version number that the		When an HTTP message is received with a major version number that the
	recipient implements, but a higher minor version number than what the		recipient implements, but a higher minor version number than what the
	recipient implements, the recipient SHOULD process the message as if		recipient implements, the recipient SHOULD process the message as if
	it were in the highest minor version within that major version to		it were in the highest minor version within that major version to
	which the recipient is conformant. A recipient can assume that a		which the recipient is conformant. A recipient can assume that a
	message with a higher minor version, when sent to a recipient that		message with a higher minor version, when sent to a recipient that
	has not yet indicated support for that higher version, is		has not yet indicated support for that higher version, is
	sufficiently backwards-compatible to be safely processed by any		sufficiently backwards compatible to be safely processed by any
	implementation of the same major version.		implementation of the same major version.
	2.7. Uniform Resource Identifiers		2.7. Uniform Resource Identifiers
	Uniform Resource Identifiers (URIs) [RFC3986] are used throughout		Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
	HTTP as the means for identifying resources (Section 2 of [RFC7231]).		HTTP as the means for identifying resources (Section 2 of [RFC7231]).
	URI references are used to target requests, indicate redirects, and		URI references are used to target requests, indicate redirects, and
	define relationships.		define relationships.
	The definitions of "URI-reference", "absolute-URI", "relative-part",		The definitions of "URI-reference", "absolute-URI", "relative-part",
	"scheme", "authority", "port", "host", "path-abempty", "segment",		"scheme", "authority", "port", "host", "path-abempty", "segment",
	"query", and "fragment" are adopted from the URI generic syntax. An		"query", and "fragment" are adopted from the URI generic syntax. An
	"absolute-path" rule is defined for protocol elements that can		"absolute-path" rule is defined for protocol elements that can
	contain a non-empty path component. (This rule differs slightly from		contain a non-empty path component. (This rule differs slightly from
	RFC 3986's path-abempty rule, which allows for an empty path to be		the path-abempty rule of RFC 3986, which allows for an empty path to
	used in references, and path-absolute rule, which does not allow		be used in references, and path-absolute rule, which does not allow
	paths that begin with "//".) A "partial-URI" rule is defined for		paths that begin with "//".) A "partial-URI" rule is defined for
	protocol elements that can contain a relative URI but not a fragment		protocol elements that can contain a relative URI but not a fragment
	component.		component.
	URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>		URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
	absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>		absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
	relative-part = <relative-part, defined in [RFC3986], Section 4.2>		relative-part = <relative-part, defined in [RFC3986], Section 4.2>
	scheme = <scheme, defined in [RFC3986], Section 3.1>		scheme = <scheme, defined in [RFC3986], Section 3.1>
	authority = <authority, defined in [RFC3986], Section 3.2>		authority = <authority, defined in [RFC3986], Section 3.2>
	uri-host = <host, defined in [RFC3986], Section 3.2.2>		uri-host = <host, defined in [RFC3986], Section 3.2.2>
	skipping to change at page 16, line 50		skipping to change at page 16, line 50
	of reference (URI-reference), only a URI in absolute form (absolute-		of reference (URI-reference), only a URI in absolute form (absolute-
	URI), only the path and optional query components, or some		URI), only the path and optional query components, or some
	combination of the above. Unless otherwise indicated, URI references		combination of the above. Unless otherwise indicated, URI references
	are parsed relative to the effective request URI (Section 5.5).		are parsed relative to the effective request URI (Section 5.5).
	2.7.1. http URI Scheme		2.7.1. http URI Scheme
	The "http" URI scheme is hereby defined for the purpose of minting		The "http" URI scheme is hereby defined for the purpose of minting
	identifiers according to their association with the hierarchical		identifiers according to their association with the hierarchical
	namespace governed by a potential HTTP origin server listening for		namespace governed by a potential HTTP origin server listening for
	TCP ([RFC0793]) connections on a given port.		TCP ([RFC793]) connections on a given port.
	http-URI = "http:" "//" authority path-abempty [ "?" query ]		http-URI = "http:" "//" authority path-abempty [ "?" query ]
	[ "#" fragment ]		[ "#" fragment ]
	The origin server for an "http" URI is identified by the authority		The origin server for an "http" URI is identified by the authority
	component, which includes a host identifier and optional TCP port		component, which includes a host identifier and optional TCP port
	([RFC3986], Section 3.2.2). The hierarchical path component and		([RFC3986], Section 3.2.2). The hierarchical path component and
	optional query component serve as an identifier for a potential		optional query component serve as an identifier for a potential
	target resource within that origin server's name space. The optional		target resource within that origin server's name space. The optional
	skipping to change at page 19, line 18		skipping to change at page 19, line 18
	Since the "http" and "https" schemes conform to the URI generic		Since the "http" and "https" schemes conform to the URI generic
	syntax, such URIs are normalized and compared according to the		syntax, such URIs are normalized and compared according to the
	algorithm defined in Section 6 of [RFC3986], using the defaults		algorithm defined in Section 6 of [RFC3986], using the defaults
	described above for each scheme.		described above for each scheme.
	If the port is equal to the default port for a scheme, the normal		If the port is equal to the default port for a scheme, the normal
	form is to omit the port subcomponent. When not being used in		form is to omit the port subcomponent. When not being used in
	absolute form as the request target of an OPTIONS request, an empty		absolute form as the request target of an OPTIONS request, an empty
	path component is equivalent to an absolute path of "/", so the		path component is equivalent to an absolute path of "/", so the
	normal form is to provide a path of "/" instead. The scheme and host		normal form is to provide a path of "/" instead. The scheme and host
	are case-insensitive and normally provided in lowercase; all other		are case insensitive and normally provided in lowercase; all other
	components are compared in a case-sensitive manner. Characters other		components are compared in a case-sensitive manner. Characters other
	than those in the "reserved" set are equivalent to their percent-		than those in the "reserved" set are equivalent to their percent-
	encoded octets: the normal form is to not encode them (see Sections		encoded octets: the normal form is to not encode them (see Sections
	2.1 and 2.2 of [RFC3986]).		2.1 and 2.2 of [RFC3986]).
	For example, the following three URIs are equivalent:		For example, the following three URIs are equivalent:
	http://example.com:80/~smith/home.html		http://example.com:80/~smith/home.html
	http://EXAMPLE.com/%7Esmith/home.html		http://EXAMPLE.com/%7Esmith/home.html
	http://EXAMPLE.com:/%7esmith/home.html		http://EXAMPLE.com:/%7esmith/home.html
	skipping to change at page 20, line 45		skipping to change at page 20, line 45
	3.1. Start Line		3.1. Start Line
	An HTTP message can be either a request from client to server or a		An HTTP message can be either a request from client to server or a
	response from server to client. Syntactically, the two types of		response from server to client. Syntactically, the two types of
	message differ only in the start-line, which is either a request-line		message differ only in the start-line, which is either a request-line
	(for requests) or a status-line (for responses), and in the algorithm		(for requests) or a status-line (for responses), and in the algorithm
	for determining the length of the message body (Section 3.3).		for determining the length of the message body (Section 3.3).
	In theory, a client could receive requests and a server could receive		In theory, a client could receive requests and a server could receive
	responses, distinguishing them by their different start-line formats,		responses, distinguishing them by their different start-line formats,
	but, in practice, servers are implemented to only expect a request (a		but, in practice, servers are implemented only to expect a request (a
	response is interpreted as an unknown or invalid request method) and		response is interpreted as an unknown or invalid request method) and
	clients are implemented to only expect a response.		clients are implemented to only expect a response.
	start-line = request-line / status-line		start-line = request-line / status-line
	3.1.1. Request Line		3.1.1. Request Line
	A request-line begins with a method token, followed by a single space		A request-line begins with a method token and is followed by a single
	(SP), the request-target, another single space (SP), the protocol		space (SP), the request-target, another single space (SP), the
	version, and ending with CRLF.		protocol version, and ends with CRLF.
	request-line = method SP request-target SP HTTP-version CRLF		request-line = method SP request-target SP HTTP-version CRLF
	The method token indicates the request method to be performed on the		The method token indicates the request method to be performed on the
	target resource. The request method is case-sensitive.		target resource. The request method is case sensitive.
	method = token		method = token
	The request methods defined by this specification can be found in		The request methods defined by this specification can be found in
	Section 4 of [RFC7231], along with information regarding the HTTP		Section 4 of [RFC7231], along with information regarding the HTTP
	method registry and considerations for defining new methods.		method registry and considerations for defining new methods.
	The request-target identifies the target resource upon which to apply		The request-target identifies the target resource upon which to apply
	the request, as defined in Section 5.3.		the request, as defined in Section 5.3.
	skipping to change at page 22, line 8		skipping to change at page 22, line 8
	longer than any URI it wishes to parse MUST respond with a 414 (URI		longer than any URI it wishes to parse MUST respond with a 414 (URI
	Too Long) status code (see Section 6.5.12 of [RFC7231]).		Too Long) status code (see Section 6.5.12 of [RFC7231]).
	Various ad hoc limitations on request-line length are found in		Various ad hoc limitations on request-line length are found in
	practice. It is RECOMMENDED that all HTTP senders and recipients		practice. It is RECOMMENDED that all HTTP senders and recipients
	support, at a minimum, request-line lengths of 8000 octets.		support, at a minimum, request-line lengths of 8000 octets.
	3.1.2. Status Line		3.1.2. 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
	space, a possibly empty textual phrase describing the status code,		(SP), a possibly empty textual phrase describing the status code,
	and ending with CRLF.		and, finally, CRLF.
	status-line = HTTP-version SP status-code SP reason-phrase CRLF		status-line = HTTP-version SP status-code SP reason-phrase CRLF
	The status-code element is a 3-digit integer code describing the		The status-code element is a 3-digit integer code describing the
	result of the server's attempt to understand and satisfy the client's		result of the server's attempt to understand and satisfy the client's
	corresponding request. The rest of the response message is to be		corresponding request. The rest of the response message is to be
	interpreted in light of the semantics defined for that status code.		interpreted in light of the semantics defined for that status code.
	See Section 6 of [RFC7231] for information about the semantics of		See Section 6 of [RFC7231] for information about the semantics of
	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,
	skipping to change at page 23, line 29		skipping to change at page 23, line 29
	evaluation, or refine the meaning of responses.		evaluation, or refine the meaning of responses.
	A proxy MUST forward unrecognized header fields unless the field-name		A proxy MUST forward unrecognized header fields unless the field-name
	is listed in the Connection header field (Section 6.1) or the proxy		is listed in the Connection header field (Section 6.1) or the proxy
	is specifically configured to block, or otherwise transform, such		is specifically configured to block, or otherwise transform, such
	fields. Other recipients SHOULD ignore unrecognized header fields.		fields. Other recipients SHOULD ignore unrecognized header fields.
	These requirements allow HTTP's functionality to be enhanced without		These requirements allow HTTP's functionality to be enhanced without
	requiring prior update of deployed intermediaries.		requiring prior update of deployed intermediaries.
	All defined header fields ought to be registered with IANA in the		All defined header fields ought to be registered with IANA in the
	Message Header Field Registry, as described in Section 8.3 of		"Message Headers" field registry, as described in Section 8.3 of
	[RFC7231].		[RFC7231].
	3.2.2. Field Order		3.2.2. Field Order
	The order in which header fields with differing field names are		The order in which header fields with differing field names are
	received is not significant. However, it is good practice to send		received is not significant. However, it is good practice to send
	header fields that contain control data first, such as Host on		header fields that contain control data first, such as Host on
	requests and Date on responses, so that implementations can decide		requests and Date on responses, so that implementations can decide
	when not to handle a message as early as possible. A server MUST NOT		when not to handle a message as early as possible. A server MUST NOT
	apply a request to the target resource until the entire request		apply a request to the target resource until the entire request
	skipping to change at page 24, line 14		skipping to change at page 24, line 14
	the combined field value in order, separated by a comma. The order		the combined field value in order, separated by a comma. The order
	in which header fields with the same field name are received is		in which header fields with the same field name are received is
	therefore significant to the interpretation of the combined field		therefore significant to the interpretation of the combined field
	value; a proxy MUST NOT change the order of these field values when		value; a proxy MUST NOT change the order of these field values when
	forwarding a message.		forwarding a message.
	Note: In practice, the "Set-Cookie" header field ([RFC6265]) often		Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
	appears multiple times in a response message and does not use the		appears multiple times in a response message and does not use the
	list syntax, violating the above requirements on multiple header		list syntax, violating the above requirements on multiple header
	fields with the same name. Since it cannot be combined into a		fields with the same name. Since it cannot be combined into a
	single field-value, recipients ought to handle "Set-Cookie" as a		single field-value, recipients ought to handle Set-Cookie as a
	special case while processing header fields. (See Appendix A.2.3		special case while processing header fields. (See Appendix A.2.3
	of [Kri2001] for details.)		of [Kri2001] for details.)
	3.2.3. Whitespace		3.2.3. Whitespace
	This specification uses three rules to denote the use of linear		This specification uses three rules to denote the use of linear
	whitespace: OWS (optional whitespace), RWS (required whitespace), and		whitespace: OWS (optional whitespace), RWS (required whitespace), and
	BWS ("bad" whitespace).		BWS ("bad" whitespace).
	The OWS rule is used where zero or more linear whitespace octets		The OWS rule is used where zero or more linear whitespace octets
	might appear. For protocol elements where optional whitespace is		might appear. For protocol elements where optional whitespace is
	preferred to improve readability, a sender SHOULD generate the		preferred to improve readability, a sender SHOULD generate the
	optional whitespace as a single SP; otherwise, a sender SHOULD NOT		optional whitespace as a single SP; otherwise, a sender SHOULD NOT
	generate optional whitespace except as needed to white-out invalid or		generate optional whitespace except as needed to white out invalid or
	unwanted protocol elements during in-place message filtering.		unwanted protocol elements during in-place message filtering.
	The RWS rule is used when at least one linear whitespace octet is		The RWS rule is used when at least one linear whitespace octet is
	required to separate field tokens. A sender SHOULD generate RWS as a		required to separate field tokens. A sender SHOULD generate RWS as a
	single SP.		single SP.
	The BWS rule is used where the grammar allows optional whitespace		The BWS rule is used where the grammar allows optional whitespace
	only for historical reasons. A sender MUST NOT generate BWS in		only for historical reasons. A sender MUST NOT generate BWS in
	messages. A recipient MUST parse for such bad whitespace and remove		messages. A recipient MUST parse for such bad whitespace and remove
	it before interpreting the protocol element.		it before interpreting the protocol element.
	skipping to change at page 25, line 12		skipping to change at page 25, line 12
	BWS = OWS		BWS = OWS
	; "bad" whitespace		; "bad" whitespace
	3.2.4. Field Parsing		3.2.4. 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). Consequently, this specification does not use ABNF rules		processed). Consequently, this specification does not use ABNF rules
	to define each "Field-Name: Field Value" pair, as was done in		to define each "field-name: field-value" pair, as was done in
	previous editions. Instead, this specification uses ABNF rules that		previous editions. Instead, this specification uses ABNF rules that
	are named according to each registered field name, wherein the rule		are named according to each registered field name, wherein the rule
	defines the valid grammar for that field's corresponding field values		defines the valid grammar for that field's corresponding field values
	(i.e., after the field-value has been extracted from the header		(i.e., after the field-value has been extracted from the header
	section by a generic field parser).		section by a generic field parser).
	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
	server MUST reject any received request message that contains		server MUST reject any received request message that contains
	skipping to change at page 26, line 16		skipping to change at page 26, line 16
	received, or replace each received obs-fold with one or more SP		received, or replace each received obs-fold with one or more SP
	octets prior to interpreting the field value or forwarding the		octets prior to interpreting the field value or forwarding the
	message downstream.		message downstream.
	A user agent that receives an obs-fold in a response message that is		A user agent that receives an obs-fold in a response message that is
	not within a message/http container MUST replace each received obs-		not within a message/http container MUST replace each received obs-
	fold with one or more SP octets prior to interpreting the field		fold with one or more SP octets prior to interpreting the field
	value.		value.
	Historically, HTTP has allowed field content with text in the		Historically, HTTP has allowed field content with text in the
	ISO-8859-1 charset [ISO-8859-1], supporting other charsets only		ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
	through use of [RFC2047] encoding. In practice, most HTTP header		through use of [RFC2047] encoding. In practice, most HTTP header
	field values use only a subset of the US-ASCII charset [USASCII].		field values use only a subset of the US-ASCII charset [USASCII].
	Newly defined header fields SHOULD limit their field values to		Newly defined header fields SHOULD limit their field values to
	US-ASCII octets. A recipient SHOULD treat other octets in field		US-ASCII octets. A recipient SHOULD treat other octets in field
	content (obs-text) as opaque data.		content (obs-text) as opaque data.
	3.2.5. Field Limits		3.2.5. Field Limits
	HTTP does not place a predefined limit on the length of each header		HTTP does not place a predefined limit on the length of each header
	field or on the length of the header section as a whole, as described		field or on the length of the header section as a whole, as described
	skipping to change at page 33, line 6		skipping to change at page 33, line 6
	6. If this is a request message and none of the above are true, then		6. If this is a request message and none of the above are true, then
	the message body length is zero (no message body is present).		the message body length is zero (no message body is present).
	7. Otherwise, this is a response message without a declared message		7. Otherwise, this is a response message without a declared message
	body length, so the message body length is determined by the		body length, so the message body length is determined by the
	number of octets received prior to the server closing the		number of octets received prior to the server closing the
	connection.		connection.
	Since there is no way to distinguish a successfully completed, close-		Since there is no way to distinguish a successfully completed, close-
	delimited message from a partially-received message interrupted by		delimited message from a partially received message interrupted by
	network failure, a server SHOULD generate encoding or length-		network failure, a server SHOULD generate encoding or length-
	delimited messages whenever possible. The close-delimiting feature		delimited messages whenever possible. The close-delimiting feature
	exists primarily for backwards compatibility with HTTP/1.0.		exists primarily for backwards compatibility with HTTP/1.0.
	A server MAY reject a request that contains a message body but not a		A server MAY reject a request that contains a message body but not a
	Content-Length by responding with 411 (Length Required).		Content-Length by responding with 411 (Length Required).
	Unless a transfer coding other than chunked has been applied, a		Unless a transfer coding other than chunked has been applied, a
	client that sends a request containing a message body SHOULD use a		client that sends a request containing a message body SHOULD use a
	valid Content-Length header field if the message body length is known		valid Content-Length header field if the message body length is known
	skipping to change at page 35, line 26		skipping to change at page 35, line 26
	/ "compress" ; Section 4.2.1		/ "compress" ; Section 4.2.1
	/ "deflate" ; Section 4.2.2		/ "deflate" ; Section 4.2.2
	/ "gzip" ; Section 4.2.3		/ "gzip" ; Section 4.2.3
	/ transfer-extension		/ transfer-extension
	transfer-extension = token *( OWS ";" OWS transfer-parameter )		transfer-extension = token *( OWS ";" OWS transfer-parameter )
	Parameters are in the form of a name or name=value pair.		Parameters are in the form of a name or name=value pair.
	transfer-parameter = token BWS "=" BWS ( token / quoted-string )		transfer-parameter = token BWS "=" BWS ( token / quoted-string )
	All transfer-coding names are case-insensitive and ought to be		All transfer-coding names are case insensitive and ought to be
	registered within the HTTP Transfer Coding registry, as defined in		registered within the "HTTP Transfer Coding" registry, as defined in
	Section 8.4. They are used in the TE (Section 4.3) and Transfer-		Section 8.4. They are used in the TE (Section 4.3) and Transfer-
	Encoding (Section 3.3.1) header fields.		Encoding (Section 3.3.1) header fields.
	4.1. Chunked Transfer Coding		4.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
	sequence of length-delimited buffers, which enables the sender to		sequence of length-delimited buffers, which enables the sender to
	skipping to change at page 49, line 29		skipping to change at page 49, line 29
	A proxy MUST NOT modify the "absolute-path" and "query" parts of the		A proxy MUST NOT modify the "absolute-path" and "query" parts of the
	received request-target when forwarding it to the next inbound		received request-target when forwarding it to the next inbound
	server, except as noted above to replace an empty path with "/" or		server, except as noted above to replace an empty path with "/" or
	"*".		"*".
	A proxy MAY modify the message body through application or removal of		A proxy MAY modify the message body through application or removal of
	a transfer coding (Section 4).		a transfer coding (Section 4).
	A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of		A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
	a message that contains a no-transform cache-control directive		a message that contains a no-transform Cache-Control directive
	(Section 5.2 of [RFC7234]).		(Section 5.2 of [RFC7234]).
	A proxy MAY transform the payload of a message that does not contain		A proxy MAY transform the payload of a message that does not contain
	a no-transform cache-control directive. A proxy that transforms a		a no-transform Cache-Control directive. A proxy that transforms a
	payload MUST add a Warning header field with the warn-code of 214		payload MUST add a Warning header field with the warn-code of 214
	("Transformation Applied") if one is not already in the message (see		("Transformation Applied") if one is not already in the message (see
	Section 5.5 of [RFC7234]). A proxy that transforms the payload of a		Section 5.5 of [RFC7234]). A proxy that transforms the payload of a
	200 (OK) response can further inform downstream recipients that a		200 (OK) response can further inform downstream recipients that a
	transformation has been applied by changing the response status code		transformation has been applied by changing the response status code
	to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).		to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
	A proxy SHOULD NOT modify header fields that provide information		A proxy SHOULD NOT modify header fields that provide information
	about the end points of the communication chain, the resource state,		about the endpoints of the communication chain, the resource state,
	or the selected representation (other than the payload) unless the		or the selected representation (other than the payload) unless the
	field's definition specifically allows such modification or the		field's definition specifically allows such modification or the
	modification is deemed necessary for privacy or security.		modification is deemed necessary for privacy or security.
	6. Connection Management		6. Connection Management
	HTTP messaging is independent of the underlying transport or session-		HTTP messaging is independent of the underlying transport- or
	layer connection protocol(s). HTTP only presumes a reliable		session-layer connection protocol(s). HTTP only presumes a reliable
	transport with in-order delivery of requests and the corresponding		transport with in-order delivery of requests and the corresponding
	in-order delivery of responses. The mapping of HTTP request and		in-order delivery of responses. The mapping of HTTP request and
	response structures onto the data units of an underlying transport		response structures onto the data units of an underlying transport
	protocol is outside the scope of this specification.		protocol is outside the scope of this specification.
	As described in Section 5.2, the specific connection protocols to be		As described in Section 5.2, the specific connection protocols to be
	used for an HTTP interaction are determined by client configuration		used for an HTTP interaction are determined by client configuration
	and the target URI. For example, the "http" URI scheme		and the target URI. For example, the "http" URI scheme
	(Section 2.7.1) indicates a default connection of TCP over IP, with a		(Section 2.7.1) indicates a default connection of TCP over IP, with a
	default TCP port of 80, but the client might be configured to use a		default TCP port of 80, but the client might be configured to use a
	skipping to change at page 51, line 8		skipping to change at page 51, line 8
	recipients on the chain ("end-to-end"), enabling the message to be		recipients on the chain ("end-to-end"), enabling the message to be
	self-descriptive and allowing future connection-specific extensions		self-descriptive and allowing future connection-specific extensions
	to be deployed without fear that they will be blindly forwarded by		to be deployed without fear that they will be blindly forwarded by
	older intermediaries.		older intermediaries.
	The Connection header field's value has the following grammar:		The Connection header field's value has the following grammar:
	Connection = 1#connection-option		Connection = 1#connection-option
	connection-option = token		connection-option = token
	Connection options are case-insensitive.		Connection options are case insensitive.
	A sender MUST NOT send a connection option corresponding to a header		A sender MUST NOT send a connection option corresponding to a header
	field that is intended for all recipients of the payload. For		field that is intended for all recipients of the payload. For
	example, Cache-Control is never appropriate as a connection option		example, Cache-Control is never appropriate as a connection option
	(Section 5.2 of [RFC7234]).		(Section 5.2 of [RFC7234]).
	The connection options do not always correspond to a header field		The connection options do not always correspond to a header field
	present in the message, since a connection-specific header field		present in the message, since a connection-specific header field
	might not be needed if there are no parameters associated with a		might not be needed if there are no parameters associated with a
	connection option. In contrast, a connection-specific header field		connection option. In contrast, a connection-specific header field
	skipping to change at page 51, line 51		skipping to change at page 51, line 51
	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.
	6.2. Establishment		6.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.
	6.3. Persistence		6.3. Persistence
	HTTP/1.1 defaults to the use of "persistent connections", allowing		HTTP/1.1 defaults to the use of "persistent connections", allowing
	multiple requests and responses to be carried over a single		multiple requests and responses to be carried over a single
	connection. The "close" connection-option is used to signal that a		connection. The "close" connection option is used to signal that a
	connection will not persist after the current request/response. HTTP		connection will not persist after the current request/response. HTTP
	implementations SHOULD support persistent connections.		implementations SHOULD support persistent connections.
	A recipient determines whether a connection is persistent or not		A recipient determines whether a connection is persistent or not
	based on the most recently received message's protocol version and		based on the most recently received message's protocol version and
	Connection header field (if any):		Connection header field (if any):
	o If the close connection option is present, the connection will not		o If the "close" connection option is present, the connection will
	persist after the current response; else,		not persist after the current response; else,
	o If the received protocol is HTTP/1.1 (or later), the connection		o If the received protocol is HTTP/1.1 (or later), the connection
	will persist after the current response; else,		will persist after the current response; else,
	o If the received protocol is HTTP/1.0, the "keep-alive" connection		o If the received protocol is HTTP/1.0, the "keep-alive" connection
	option is present, the recipient is not a proxy, and the recipient		option is present, the recipient is not a proxy, and the recipient
	wishes to honor the HTTP/1.0 "keep-alive" mechanism, the		wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
	connection will persist after the current response; otherwise,		connection will persist after the current response; otherwise,
	o The connection will close after the current response.		o The connection will close after the current response.
	A client MAY send additional requests on a persistent connection		A client MAY send additional requests on a persistent connection
	until it sends or receives a close connection option or receives an		until it sends or receives a "close" connection option or receives an
	HTTP/1.0 response without a "keep-alive" connection option.		HTTP/1.0 response without a "keep-alive" connection option.
	In order to remain persistent, all messages on a connection need to		In order to remain persistent, all messages on a connection need to
	have a self-defined message length (i.e., one not defined by closure		have a self-defined message length (i.e., one not defined by closure
	of the connection), as described in Section 3.3. A server MUST read		of the connection), as described in Section 3.3. A server MUST read
	the entire request message body or close the connection after sending		the entire request message body or close the connection after sending
	its response, since otherwise the remaining data on a persistent		its response, since otherwise the remaining data on a persistent
	connection would be misinterpreted as the next request. Likewise, a		connection would be misinterpreted as the next request. Likewise, a
	client MUST read the entire response message body if it intends to		client MUST read the entire response message body if it intends to
	reuse the same connection for a subsequent request.		reuse the same connection for a subsequent request.
	skipping to change at page 55, line 31		skipping to change at page 55, line 31
	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.
	6.6. Tear-down		6.6. Teardown
	The Connection header field (Section 6.1) provides a "close"		The Connection header field (Section 6.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 MUST		requests on that connection (after the one containing close) and MUST
	close the connection after reading the final response message		close the connection after reading the final response message
	corresponding to this request.		corresponding to this request.
	A server that receives a close connection option MUST initiate a		A server that receives a "close" connection option MUST initiate a
	close of the connection (see below) after it sends the final response		close of the connection (see below) after it sends the final response
	to the request that contained close. The server SHOULD send a close		to the request that contained close. The server SHOULD send a close
	connection option in its final response on that connection. The		connection option in its final response on that connection. The
	server MUST NOT process any further requests received on that		server MUST NOT process any further requests received on that
	connection.		connection.
	A server that sends a close connection option MUST initiate a close		A server that sends a "close" connection option MUST initiate a close
	of the connection (see below) after it sends the response containing		of the connection (see below) after it sends the response containing
	close. The server MUST NOT process any further requests received on		close. The server MUST NOT process any further requests received on
	that connection.		that connection.
	A client that receives a close connection option MUST cease sending		A client that receives a "close" connection option MUST cease sending
	requests on that connection and close the connection after reading		requests on that connection and close the connection after reading
	the response message containing the close; if additional pipelined		the response message containing the close; if additional pipelined
	requests had been sent on the connection, the client SHOULD NOT		requests had been sent on the connection, the client SHOULD NOT
	assume that they will be processed by the server.		assume that they will be processed by the server.
	If a server performs an immediate close of a TCP connection, there is		If a server performs an immediate close of a TCP connection, there is
	a significant risk that the client will not be able to read the last		a significant risk that the client will not be able to read the last
	HTTP response. If the server receives additional data from the		HTTP response. If the server receives additional data from the
	client on a fully closed connection, such as another request that was		client on a fully closed connection, such as another request that was
	sent by the client before receiving the server's response, the		sent by the client before receiving the server's response, the
	skipping to change at page 57, line 31		skipping to change at page 57, line 31
	The following is a hypothetical example sent by a client:		The following is a hypothetical example sent by a client:
	GET /hello.txt HTTP/1.1		GET /hello.txt HTTP/1.1
	Host: www.example.com		Host: www.example.com
	Connection: upgrade		Connection: upgrade
	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11		Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
	The capabilities and nature of the application-level communication		The capabilities and nature of the application-level communication
	after the protocol change is entirely dependent upon the new		after the protocol change is entirely dependent upon the new
	protocol(s) chosen. However, immediately after sending the 101		protocol(s) chosen. However, immediately after sending the 101
	response, the server is expected to continue responding to the		(Switching Protocols) response, the server is expected to continue
	original request as if it had received its equivalent within the new		responding to the original request as if it had received its
	protocol (i.e., the server still has an outstanding request to		equivalent within the new protocol (i.e., the server still has an
	satisfy after the protocol has been changed, and is expected to do so		outstanding request to satisfy after the protocol has been changed,
	without requiring the request to be repeated).		and is expected to do so without requiring the request to be
			repeated).
	For example, if the Upgrade header field is received in a GET request		For example, if the Upgrade header field is received in a GET request
	and the server decides to switch protocols, it first responds with a		and the server decides to switch protocols, it first responds with a
	101 (Switching Protocols) message in HTTP/1.1 and then immediately		101 (Switching Protocols) message in HTTP/1.1 and then immediately
	follows that with the new protocol's equivalent of a response to a		follows that with the new protocol's equivalent of a response to a
	GET on the target resource. This allows a connection to be upgraded		GET on the target resource. This allows a connection to be upgraded
	to protocols with the same semantics as HTTP without the latency cost		to protocols with the same semantics as HTTP without the latency cost
	of an additional round trip. A server MUST NOT switch protocols		of an additional round trip. A server MUST NOT switch protocols
	unless the received message semantics can be honored by the new		unless the received message semantics can be honored by the new
	protocol; an OPTIONS request can be honored by any protocol.		protocol; an OPTIONS request can be honored by any protocol.
	skipping to change at page 59, line 35		skipping to change at page 59, line 35
	#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]		#element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]
	1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )		1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )
	Empty elements do not contribute to the count of elements present.		Empty elements do not contribute to the count of elements present.
	For example, given these ABNF productions:		For example, given these ABNF productions:
	example-list = 1#example-list-elmt		example-list = 1#example-list-elmt
	example-list-elmt = token ; see Section 3.2.6		example-list-elmt = token ; see Section 3.2.6
	Then the following are valid values for example-list (not including		Then, the following are valid values for example-list (not including
	the double quotes, which are present for delimitation only):		the double quotes, which are present for delimitation only):
	"foo,bar"		"foo,bar"
	"foo ,bar,"		"foo ,bar,"
	"foo , ,bar,charlie "		"foo , ,bar,charlie "
	In contrast, the following values would be invalid, since at least		In contrast, the following values would be invalid, since at least
	one non-empty element is required by the example-list production:		one non-empty element is required by the example-list production:
	""		""
	","		","
	", ,"		", ,"
	Appendix B shows the collected ABNF for recipients after the list		Appendix B shows the collected ABNF for recipients after the list
	constructs have been expanded.		constructs have been expanded.
	8. IANA Considerations		8. IANA Considerations
	8.1. Header Field Registration		8.1. Header Field Registration
	HTTP header fields are registered within the Message Header Field		HTTP header fields are registered within the "Message Header" field
	Registry maintained at		registry maintained at
	<http://www.iana.org/assignments/message-headers/>.		<http://www.iana.org/assignments/message-headers/>.
	This document defines the following HTTP header fields, so their		This document defines the following HTTP header fields, so the
	associated registry entries shall be updated according to the		"Permanent Message Header Field Names" registry has been updated
	permanent registrations below (see [BCP90]):		accordingly (see [BCP90]).
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	| Connection | http | standard | Section 6.1 |		| Connection | http | standard | Section 6.1 |
	| Content-Length | http | standard | Section 3.3.2 |		| Content-Length | http | standard | Section 3.3.2 |
	| Host | http | standard | Section 5.4 |		| Host | http | standard | Section 5.4 |
	| TE | http | standard | Section 4.3 |		| TE | http | standard | Section 4.3 |
	| Trailer | http | standard | Section 4.4 |		| Trailer | http | standard | Section 4.4 |
	| Transfer-Encoding | http | standard | Section 3.3.1 |		| Transfer-Encoding | http | standard | Section 3.3.1 |
	| Upgrade | http | standard | Section 6.7 |		| Upgrade | http | standard | Section 6.7 |
	| Via | http | standard | Section 5.7.1 |		| Via | http | standard | Section 5.7.1 |
	+-------------------+----------+----------+---------------+		+-------------------+----------+----------+---------------+
	Furthermore, the header field-name "Close" shall be registered as		Furthermore, the header field-name "Close" has been registered as
	"reserved", since using that name as an HTTP header field might		"reserved", since using that name as an HTTP header field might
	conflict with the "close" connection option of the "Connection"		conflict with the "close" connection option of the "Connection"
	header field (Section 6.1).		header field (Section 6.1).
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Header Field Name | Protocol | Status | Reference |		| Header Field Name | Protocol | Status | Reference |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Close | http | reserved | Section 8.1 |		| Close | http | reserved | Section 8.1 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
	8.2. URI Scheme Registration		8.2. URI Scheme Registration
	IANA maintains the registry of URI Schemes [BCP115] at		IANA maintains the registry of URI Schemes [BCP115] at
	<http://www.iana.org/assignments/uri-schemes/>.		<http://www.iana.org/assignments/uri-schemes/>.
	This document defines the following URI schemes, so their associated		This document defines the following URI schemes, so the "Permanent
	registry entries shall be updated according to the permanent		URI Schemes" registry has been updated accordingly.
	registrations below:
	+------------+------------------------------------+---------------+		+------------+------------------------------------+---------------+
	| URI Scheme | Description | Reference |		| URI Scheme | Description | Reference |
	+------------+------------------------------------+---------------+		+------------+------------------------------------+---------------+
	| http | Hypertext Transfer Protocol | Section 2.7.1 |		| http | Hypertext Transfer Protocol | Section 2.7.1 |
	| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |		| https | Hypertext Transfer Protocol Secure | Section 2.7.2 |
	+------------+------------------------------------+---------------+		+------------+------------------------------------+---------------+
	8.3. Internet Media Type Registration		8.3. Internet Media Type Registration
	IANA maintains the registry of Internet media types [BCP13] at		IANA maintains the registry of Internet media types [BCP13] at
	<http://www.iana.org/assignments/media-types>.		<http://www.iana.org/assignments/media-types>.
	This document serves as the specification for the Internet media		This document serves as the specification for the Internet media
	types "message/http" and "application/http". The following is to be		types "message/http" and "application/http". The following has been
	registered with IANA.		registered with IANA.
	8.3.1. Internet Media Type message/http		8.3.1. Internet Media Type message/http
	The message/http type can be used to enclose a single HTTP request or		The message/http type can be used to enclose a single HTTP request or
	response message, provided that it obeys the MIME restrictions for		response message, provided that it obeys the MIME restrictions for
	all "message" types regarding line length and encodings.		all "message" types regarding line length and encodings.
	Type name: message		Type name: message
	skipping to change at page 62, line 20		skipping to change at page 62, line 20
	Additional information:		Additional information:
	Magic number(s): N/A		Magic number(s): N/A
	Deprecated alias names for this type: N/A		Deprecated alias names for this type: N/A
	File extension(s): N/A		File extension(s): N/A
	Macintosh file type code(s): N/A		Macintosh file type code(s): N/A
	Person and email address to contact for further information: See		Person and email address to contact for further information:
	Authors' Addresses Section.		See Authors' Addresses Section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: N/A		Restrictions on usage: N/A
	Author: See Authors' Addresses Section.		Author: See Authors' Addresses Section.
	Change controller: IESG		Change controller: IESG
	8.3.2. Internet Media Type application/http		8.3.2. Internet Media Type application/http
	skipping to change at page 63, line 29		skipping to change at page 63, line 29
	Additional information:		Additional information:
	Deprecated alias names for this type: N/A		Deprecated alias names for this type: N/A
	Magic number(s): N/A		Magic number(s): N/A
	File extension(s): N/A		File extension(s): N/A
	Macintosh file type code(s): N/A		Macintosh file type code(s): N/A
	Person and email address to contact for further information: See		Person and email address to contact for further information:
	Authors' Addresses Section.		See Authors' Addresses Section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: N/A		Restrictions on usage: N/A
	Author: See Authors' Addresses Section.		Author: See Authors' Addresses Section.
	Change controller: IESG		Change controller: IESG
	8.4. Transfer Coding Registry		8.4. Transfer Coding Registry
	The HTTP Transfer Coding Registry defines the namespace for transfer		The "HTTP Transfer Coding" registry defines the namespace for
	coding names. It is maintained at		transfer coding names. It is maintained at
	<http://www.iana.org/assignments/http-parameters>.		<http://www.iana.org/assignments/http-parameters>.
	8.4.1. Procedure		8.4.1. Procedure
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Name		o Name
	o Description		o Description
	o Pointer to specification text		o Pointer to specification text
	skipping to change at page 64, line 22		skipping to change at page 64, line 22
	Values to be added to this namespace require IETF Review (see Section		Values to be added to this namespace require IETF Review (see Section
	4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding		4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
	defined in this specification.		defined in this specification.
	Use of program names for the identification of encoding formats is		Use of program names for the identification of encoding formats is
	not desirable and is discouraged for future encodings.		not desirable and is discouraged for future encodings.
	8.4.2. Registration		8.4.2. Registration
	The HTTP Transfer Coding Registry shall be updated with the		The "HTTP Transfer Coding Registry" has been updated with the
	registrations below:		registrations below:
	+------------+--------------------------------------+---------------+		+------------+--------------------------------------+---------------+
	| Name | Description | Reference |		| Name | Description | Reference |
	+------------+--------------------------------------+---------------+		+------------+--------------------------------------+---------------+
	| chunked | Transfer in a series of chunks | Section 4.1 |		| chunked | Transfer in a series of chunks | Section 4.1 |
	| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |		| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
	| deflate | "deflate" compressed data | Section 4.2.2 |		| deflate | "deflate" compressed data | Section 4.2.2 |
	| | ([RFC1951]) inside the "zlib" data | |		| | ([RFC1951]) inside the "zlib" data | |
	| | format ([RFC1950]) | |		| | format ([RFC1950]) | |
	| gzip | GZIP file format [RFC1952] | Section 4.2.3 |		| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
	| x-compress | Deprecated (alias for compress) | Section 4.2.1 |		| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
	| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |		| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
	+------------+--------------------------------------+---------------+		+------------+--------------------------------------+---------------+
	8.5. Content Coding Registration		8.5. Content Coding Registration
	IANA maintains the registry of HTTP Content Codings at		IANA maintains the "HTTP Content Coding Registry" at
	<http://www.iana.org/assignments/http-parameters>.		<http://www.iana.org/assignments/http-parameters>.
	The HTTP Content Codings Registry shall be updated with the		The "HTTP Content Codings Registry" has been updated with the
	registrations below:		registrations below:
	+------------+--------------------------------------+---------------+		+------------+--------------------------------------+---------------+
	| Name | Description | Reference |		| Name | Description | Reference |
	+------------+--------------------------------------+---------------+		+------------+--------------------------------------+---------------+
	| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |		| compress | UNIX "compress" data format [Welch] | Section 4.2.1 |
	| deflate | "deflate" compressed data | Section 4.2.2 |		| deflate | "deflate" compressed data | Section 4.2.2 |
	| | ([RFC1951]) inside the "zlib" data | |		| | ([RFC1951]) inside the "zlib" data | |
	| | format ([RFC1950]) | |		| | format ([RFC1950]) | |
	| gzip | GZIP file format [RFC1952] | Section 4.2.3 |		| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
	| x-compress | Deprecated (alias for compress) | Section 4.2.1 |		| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
	| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |		| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
	+------------+--------------------------------------+---------------+		+------------+--------------------------------------+---------------+
	8.6. Upgrade Token Registry		8.6. Upgrade Token Registry
	The HTTP Upgrade Token Registry defines the namespace for protocol-		The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
	name tokens used to identify protocols in the Upgrade header field.		defines the namespace for protocol-name tokens used to identify
	The registry is maintained at		protocols in the Upgrade header field. The registry is maintained at
	<http://www.iana.org/assignments/http-upgrade-tokens>.		<http://www.iana.org/assignments/http-upgrade-tokens>.
	8.6.1. Procedure		8.6.1. Procedure
	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.1 of [RFC5226]) and are subject to the following rules:		Section 4.1 of [RFC5226]) and are subject to the following rules:
	skipping to change at page 66, line 10		skipping to change at page 66, line 10
	7. The IESG MAY reassign responsibility for a protocol token. This		7. 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.
	This registration procedure for HTTP Upgrade Tokens replaces that		This registration procedure for HTTP Upgrade Tokens replaces that
	previously defined in Section 7.2 of [RFC2817].		previously defined in Section 7.2 of [RFC2817].
	8.6.2. Upgrade Token Registration		8.6.2. Upgrade Token Registration
	The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated		The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
	with the registration below:		updated with the registration below:
	+-------+----------------------+----------------------+-------------+		+-------+----------------------+----------------------+-------------+
	| Value | Description | Expected Version | Reference |		| Value | Description | Expected Version | Reference |
	| | | Tokens | |		| | | Tokens | |
	+-------+----------------------+----------------------+-------------+		+-------+----------------------+----------------------+-------------+
	| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |		| HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 |
	| | Protocol | (e.g, "2.0") | |		| | Protocol | (e.g, "2.0") | |
	+-------+----------------------+----------------------+-------------+		+-------+----------------------+----------------------+-------------+
	The responsible party is: "IETF (iesg@ietf.org) - Internet		The responsible party is: "IETF (iesg@ietf.org) - Internet
	skipping to change at page 67, line 13		skipping to change at page 67, line 13
	unknown or untrusted source.		unknown or untrusted source.
	When a registered name is used in the authority component, the "http"		When a registered name is used in the authority component, the "http"
	URI scheme (Section 2.7.1) relies on the user's local name resolution		URI scheme (Section 2.7.1) relies on the user's local name resolution
	service to determine where it can find authoritative responses. This		service to determine where it can find authoritative responses. This
	means that any attack on a user's network host table, cached names,		means that any attack on a user's network host table, cached names,
	or name resolution libraries becomes an avenue for attack on		or name resolution libraries becomes an avenue for attack on
	establishing authority. Likewise, the user's choice of server for		establishing authority. Likewise, the user's choice of server for
	Domain Name Service (DNS), and the hierarchy of servers from which it		Domain Name Service (DNS), and the hierarchy of servers from which it
	obtains resolution results, could impact the authenticity of address		obtains resolution results, could impact the authenticity of address
	mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to		mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
	improve authenticity.		improve authenticity.
	Furthermore, after an IP address is obtained, establishing authority		Furthermore, after an IP address is obtained, establishing authority
	for an "http" URI is vulnerable to attacks on Internet Protocol		for an "http" URI is vulnerable to attacks on Internet Protocol
	routing.		routing.
	The "https" scheme (Section 2.7.2) is intended to prevent (or at		The "https" scheme (Section 2.7.2) is intended to prevent (or at
	least reveal) many of these potential attacks on establishing		least reveal) many of these potential attacks on establishing
	authority, provided that the negotiated TLS connection is secured and		authority, provided that the negotiated TLS connection is secured and
	the client properly verifies that the communicating server's identity		the client properly verifies that the communicating server's identity
	matches the target URI's authority component (see [RFC2818]).		matches the target URI's authority component (see [RFC2818]).
	Correctly implementing such verification can be difficult (see		Correctly implementing such verification can be difficult (see
	[Georgiev]).		[Georgiev]).
	9.2. Risks of Intermediaries		9.2. Risks of Intermediaries
	By their very nature, HTTP intermediaries are men-in-the-middle, and		By their very nature, HTTP intermediaries are men in the middle and,
	thus represent an opportunity for man-in-the-middle attacks.		thus, represent an opportunity for man-in-the-middle attacks.
	Compromise of the systems on which the intermediaries run can result		Compromise of the systems on which the intermediaries run can result
	in serious security and privacy problems. Intermediaries might have		in serious security and privacy problems. Intermediaries might have
	access to security-related information, personal information about		access to security-related information, personal information about
	individual users and organizations, and proprietary information		individual users and organizations, and proprietary information
	belonging to users and content providers. A compromised		belonging to users and content providers. A compromised
	intermediary, or an intermediary implemented or configured without		intermediary, or an intermediary implemented or configured without
	regard to security and privacy considerations, might be used in the		regard to security and privacy considerations, might be used in the
	commission of a wide range of potential attacks.		commission of a wide range of potential attacks.
	Intermediaries that contain a shared cache are especially vulnerable		Intermediaries that contain a shared cache are especially vulnerable
	skipping to change at page 70, line 9		skipping to change at page 70, line 9
	access mechanism has resulted in its increasing use within		access mechanism has resulted in its increasing use within
	environments where verification of message integrity is crucial.		environments where verification of message integrity is crucial.
	User agents are encouraged to implement configurable means for		User agents are encouraged to implement configurable means for
	detecting and reporting failures of message integrity such that those		detecting and reporting failures of message integrity such that those
	means can be enabled within environments for which integrity is		means can be enabled within environments for which integrity is
	necessary. For example, a browser being used to view medical history		necessary. For example, a browser being used to view medical history
	or drug interaction information needs to indicate to the user when		or drug interaction information needs to indicate to the user when
	such information is detected by the protocol to be incomplete,		such information is detected by the protocol to be incomplete,
	expired, or corrupted during transfer. Such mechanisms might be		expired, or corrupted during transfer. Such mechanisms might be
	selectively enabled via user agent extensions or the presence of		selectively enabled via user-agent extensions or the presence of
	message integrity metadata in a response. At a minimum, user agents		message integrity metadata in a response. At a minimum, user agents
	ought to provide some indication that allows a user to distinguish		ought to provide some indication that allows a user to distinguish
	between a complete and incomplete response message (Section 3.4) when		between a complete and incomplete response message (Section 3.4) when
	such verification is desired.		such verification is desired.
	9.7. Message Confidentiality		9.7. Message Confidentiality
	HTTP relies on underlying transport protocols to provide message		HTTP relies on underlying transport protocols to provide message
	confidentiality when that is desired. HTTP has been specifically		confidentiality when that is desired. HTTP has been specifically
	designed to be independent of the transport protocol, such that it		designed to be independent of the transport protocol, such that it
	skipping to change at page 72, line 50		skipping to change at page 72, line 50
	Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the		Yuchung Cheng, Yutaka Oiwa, Yves Lafon (long-time member of the
	editor team), Zed A. Shaw, and Zhong Yu.		editor team), Zed A. Shaw, and Zhong Yu.
	See Section 16 of [RFC2616] for additional acknowledgements from		See Section 16 of [RFC2616] for additional acknowledgements from
	prior revisions.		prior revisions.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
	RFC 793, September 1981.
	[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data		[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
	Format Specification version 3.3", RFC 1950, May 1996.		Format Specification version 3.3", RFC 1950, May 1996.
	[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format		[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
	Specification version 1.3", RFC 1951, May 1996.		Specification version 1.3", RFC 1951, May 1996.
	[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and		[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
	G. Randers-Pehrson, "GZIP file format specification		G. Randers-Pehrson, "GZIP file format specification
	version 4.3", RFC 1952, May 1996.		version 4.3", RFC 1952, May 1996.
	skipping to change at page 73, line 28		skipping to change at page 73, line 25
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
	"Uniform Resource Identifier (URI): Generic Syntax",		"Uniform Resource Identifier (URI): Generic Syntax",
	STD 66, RFC 3986, January 2005.		STD 66, RFC 3986, January 2005.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
	Syntax Specifications: ABNF", STD 68, RFC 5234,		Syntax Specifications: ABNF", STD 68, RFC 5234,
	January 2008.		January 2008.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Semantics and Content",		Transfer Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-latest (work in		RFC 7231, May 2014.
	progress), May 2014.
	[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Conditional Requests",		Transfer Protocol (HTTP/1.1): Conditional Requests",
	draft-ietf-httpbis-p4-conditional-latest (work in		RFC 7232, May 2014.
	progress), May 2014.
	[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"Hypertext Transfer Protocol (HTTP/1.1): Range		"Hypertext Transfer Protocol (HTTP/1.1): Range
	Requests", draft-ietf-httpbis-p5-range-latest (work in		Requests", RFC 7233, May 2014.
	progress), May 2014.
	[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-latest (work in progress),		RFC 7234, May 2014.
	May 2014.
	[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext		[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
	Transfer Protocol (HTTP/1.1): Authentication",		Transfer Protocol (HTTP/1.1): Authentication",
	draft-ietf-httpbis-p7-auth-latest (work in progress),		RFC 7235, May 2014.
	May 2014.
			[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
			RFC 793, September 1981.
	[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.
	11.2. Informative References		11.2. Informative References
	skipping to change at page 77, line 10		skipping to change at page 77, line 5
	implements name-based virtual hosts ought to disable support for		implements name-based virtual hosts ought to disable support for
	HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,		HTTP/0.9. Most requests that appear to be HTTP/0.9 are, in fact,
	badly constructed HTTP/1.x requests caused by a client failing to		badly constructed HTTP/1.x requests caused by a client failing to
	properly encode the request-target.		properly encode the request-target.
	A.1. Changes from HTTP/1.0		A.1. Changes from HTTP/1.0
	This section summarizes major differences between versions HTTP/1.0		This section summarizes major differences between versions HTTP/1.0
	and HTTP/1.1.		and HTTP/1.1.
	A.1.1. Multi-homed Web Servers		A.1.1. Multihomed Web Servers
	The requirements that clients and servers support the Host header		The requirements that clients and servers support the Host header
	field (Section 5.4), report an error if it is missing from an		field (Section 5.4), report an error if it is missing from an
	HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among		HTTP/1.1 request, and accept absolute URIs (Section 5.3) are among
	the most important changes defined by HTTP/1.1.		the most important changes defined by HTTP/1.1.
	Older HTTP/1.0 clients assumed a one-to-one relationship of IP		Older HTTP/1.0 clients assumed a one-to-one relationship of IP
	addresses and servers; there was no other established mechanism for		addresses and servers; there was no other established mechanism for
	distinguishing the intended server of a request than the IP address		distinguishing the intended server of a request than the IP address
	to which that request was directed. The Host header field was		to which that request was directed. The Host header field was
	skipping to change at page 78, line 20		skipping to change at page 78, line 14
	not be used by clients at all when a proxy is being used.		not be used by clients at all when a proxy is being used.
	A.1.3. Introduction of Transfer-Encoding		A.1.3. Introduction of Transfer-Encoding
	HTTP/1.1 introduces the Transfer-Encoding header field		HTTP/1.1 introduces the Transfer-Encoding header field
	(Section 3.3.1). Transfer codings need to be decoded prior to		(Section 3.3.1). Transfer codings need to be decoded prior to
	forwarding an HTTP message over a MIME-compliant protocol.		forwarding an HTTP message over a MIME-compliant protocol.
	A.2. Changes from RFC 2616		A.2. Changes from RFC 2616
	HTTP's approach to error handling has been explained. (Section 2.5)		HTTP's approach to error handling has been explained (Section 2.5).
	The HTTP-version ABNF production has been clarified to be case-		The HTTP-version ABNF production has been clarified to be case
	sensitive. Additionally, version numbers have been restricted to		sensitive. Additionally, version numbers have been restricted to
	single digits, due to the fact that implementations are known to		single digits, due to the fact that implementations are known to
	handle multi-digit version numbers incorrectly. (Section 2.6)		handle multi-digit version numbers incorrectly (Section 2.6).
	Userinfo (i.e., username and password) are now disallowed in HTTP and		Userinfo (i.e., username and password) are now disallowed in HTTP and
	HTTPS URIs, because of security issues related to their transmission		HTTPS URIs, because of security issues related to their transmission
	on the wire. (Section 2.7.1)		on the wire (Section 2.7.1).
	The HTTPS URI scheme is now defined by this specification;		The HTTPS URI scheme is now defined by this specification;
	previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it		previously, it was defined in Section 2.4 of [RFC2818]. Furthermore,
	implies end-to-end security. (Section 2.7.2)		it implies end-to-end security (Section 2.7.2).
	HTTP messages can be (and often are) buffered by implementations;		HTTP messages can be (and often are) buffered by implementations;
	despite it sometimes being available as a stream, HTTP is		despite it sometimes being available as a stream, HTTP is
	fundamentally a message-oriented protocol. Minimum supported sizes		fundamentally a message-oriented protocol. Minimum supported sizes
	for various protocol elements have been suggested, to improve		for various protocol elements have been suggested, to improve
	interoperability. (Section 3)		interoperability (Section 3).
	Invalid whitespace around field-names is now required to be rejected,		Invalid whitespace around field-names is now required to be rejected,
	because accepting it represents a security vulnerability. The ABNF		because accepting it represents a security vulnerability. The ABNF
	productions defining header fields now only list the field value.		productions defining header fields now only list the field value
	(Section 3.2)		(Section 3.2).
	Rules about implicit linear whitespace between certain grammar		Rules about implicit linear whitespace between certain grammar
	productions have been removed; now whitespace is only allowed where		productions have been removed; now whitespace is only allowed where
	specifically defined in the ABNF. (Section 3.2.3)		specifically defined in the ABNF (Section 3.2.3).
	Header fields that span multiple lines ("line folding") are		Header fields that span multiple lines ("line folding") are
	deprecated. (Section 3.2.4)		deprecated (Section 3.2.4).
	The NUL octet is no longer allowed in comment and quoted-string text,		The NUL octet is no longer allowed in comment and quoted-string text,
	and handling of backslash-escaping in them has been clarified. The		and handling of backslash-escaping in them has been clarified. The
	quoted-pair rule no longer allows escaping control characters other		quoted-pair rule no longer allows escaping control characters other
	than HTAB. Non-ASCII content in header fields and the reason phrase		than HTAB. Non-US-ASCII content in header fields and the reason
	has been obsoleted and made opaque (the TEXT rule was removed).		phrase has been obsoleted and made opaque (the TEXT rule was removed)
	(Section 3.2.6)		(Section 3.2.6).
	Bogus "Content-Length" header fields are now required to be handled		Bogus "Content-Length" header fields are now required to be handled
	as errors by recipients. (Section 3.3.2)		as errors by recipients (Section 3.3.2).
	The algorithm for determining the message body length has been		The algorithm for determining the message body length has been
	clarified to indicate all of the special cases (e.g., driven by		clarified to indicate all of the special cases (e.g., driven by
	methods or status codes) that affect it, and that new protocol		methods or status codes) that affect it, and that new protocol
	elements cannot define such special cases. CONNECT is a new, special		elements cannot define such special cases. CONNECT is a new, special
	case in determining message body length. "multipart/byteranges" is no		case in determining message body length. "multipart/byteranges" is no
	longer a way of determining message body length detection.		longer a way of determining message body length detection
	(Section 3.3.3)		(Section 3.3.3).
	The "identity" transfer coding token has been removed. (Sections 3.3		The "identity" transfer coding token has been removed (Sections 3.3
	and 4)		and 4).
	Chunk length does not include the count of the octets in the chunk		Chunk length does not include the count of the octets in the chunk
	header and trailer. Line folding in chunk extensions is disallowed.		header and trailer. Line folding in chunk extensions is disallowed
	(Section 4.1)		(Section 4.1).
	The meaning of the "deflate" content coding has been clarified.		The meaning of the "deflate" content coding has been clarified
	(Section 4.2.2)		(Section 4.2.2).
	The segment + query components of RFC 3986 have been used to define		The segment + query components of RFC 3986 have been used to define
	the request-target, instead of abs_path from RFC 1808. The asterisk-		the request-target, instead of abs_path from RFC 1808. The asterisk-
	form of the request-target is only allowed with the OPTIONS method.		form of the request-target is only allowed with the OPTIONS method
	(Section 5.3)		(Section 5.3).
	The term "Effective Request URI" has been introduced. (Section 5.5)		The term "Effective Request URI" has been introduced (Section 5.5).
	Gateways do not need to generate Via header fields anymore.		Gateways do not need to generate Via header fields anymore
	(Section 5.7.1)		(Section 5.7.1).
	Exactly when "close" connection options have to be sent has been		Exactly when "close" connection options have to be sent has been
	clarified. Also, "hop-by-hop" header fields are required to appear		clarified. Also, "hop-by-hop" header fields are required to appear
	in the Connection header field; just because they're defined as hop-		in the Connection header field; just because they're defined as hop-
	by-hop in this specification doesn't exempt them. (Section 6.1)		by-hop in this specification doesn't exempt them (Section 6.1).
	The limit of two connections per server has been removed. An		The limit of two connections per server has been removed. An
	idempotent sequence of requests is no longer required to be retried.		idempotent sequence of requests is no longer required to be retried.
	The requirement to retry requests under certain circumstances when		The requirement to retry requests under certain circumstances when
	the server prematurely closes the connection has been removed. Also,		the server prematurely closes the connection has been removed. Also,
	some extraneous requirements about when servers are allowed to close		some extraneous requirements about when servers are allowed to close
	connections prematurely have been removed. (Section 6.3)		connections prematurely have been removed (Section 6.3).
	The semantics of the Upgrade header field is now defined in responses		The semantics of the Upgrade header field is now defined in responses
	other than 101 (this was incorporated from [RFC2817]). Furthermore,		other than 101 (this was incorporated from [RFC2817]). Furthermore,
	the ordering in the field value is now significant. (Section 6.7)		the ordering in the field value is now significant (Section 6.7).
	Empty list elements in list productions (e.g., a list header field		Empty list elements in list productions (e.g., a list header field
	containing ", ,") have been deprecated. (Section 7)		containing ", ,") have been deprecated (Section 7).
	Registration of Transfer Codings now requires IETF Review		Registration of Transfer Codings now requires IETF Review
	(Section 8.4)		(Section 8.4).
	This specification now defines the Upgrade Token Registry, previously		This specification now defines the "HTTP Upgrade Tokens" registry,
	defined in Section 7.2 of [RFC2817]. (Section 8.6)		previously defined in Section 7.2 of [RFC2817] (Section 8.6).
	The expectation to support HTTP/0.9 requests has been removed.		The expectation to support HTTP/0.9 requests has been removed
	(Appendix A)		(Appendix A).
	Issues with the Keep-Alive and Proxy-Connection header fields in		Issues with the Keep-Alive and Proxy-Connection header fields in
	requests are pointed out, with use of the latter being discouraged		requests are pointed out, with use of the latter being discouraged
	altogether. (Appendix A.1.2)		altogether (Appendix A.1.2).
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	BWS = OWS		BWS = OWS
	Connection = *( "," OWS ) connection-option *( OWS "," [ OWS		Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
	connection-option ] )		connection-option ] )
	Content-Length = 1*DIGIT		Content-Length = 1*DIGIT
	HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body		HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body
	skipping to change at page 83, line 25		skipping to change at page 83, line 20
	client 7		client 7
	close 50, 55		close 50, 55
	compress (Coding Format) 38		compress (Coding Format) 38
	connection 7		connection 7
	Connection header field 50, 55		Connection header field 50, 55
	Content-Length header field 30		Content-Length header field 30
	D		D
	deflate (Coding Format) 38		deflate (Coding Format) 38
	Delimiters 26		Delimiters 26
	downstream 9		downstream 10
	E		E
	effective request URI 44		effective request URI 44
	G		G
	gateway 10		gateway 10
	Grammar		Grammar
	absolute-form 41-42		absolute-form 41-42
	absolute-path 16		absolute-path 16
	absolute-URI 16		absolute-URI 16
	skipping to change at page 84, line 20		skipping to change at page 84, line 14
	field-content 22		field-content 22
	field-name 22, 39		field-name 22, 39
	field-value 22		field-value 22
	field-vchar 22		field-vchar 22
	fragment 16		fragment 16
	header-field 22, 36		header-field 22, 36
	HEXDIG 6		HEXDIG 6
	Host 43		Host 43
	HTAB 6		HTAB 6
	HTTP-message 19		HTTP-message 19
	HTTP-name 13		HTTP-name 14
	http-URI 16		http-URI 16
	HTTP-version 13		HTTP-version 14
	https-URI 18		https-URI 18
	last-chunk 35		last-chunk 35
	LF 6		LF 6
	message-body 27		message-body 27
	method 21		method 21
	obs-fold 22		obs-fold 22
	obs-text 27		obs-text 27
	OCTET 6		OCTET 6
	origin-form 41		origin-form 41
	OWS 24		OWS 24
	skipping to change at page 85, line 34		skipping to change at page 85, line 28
	H		H
	header field 19		header field 19
	header section 19		header section 19
	headers 19		headers 19
	Host header field 43		Host header field 43
	http URI scheme 16		http URI scheme 16
	https URI scheme 18		https URI scheme 18
	I		I
	inbound 9		inbound 10
	interception proxy 11		interception proxy 11
	intermediary 9		intermediary 9
	M		M
	Media Type		Media Type
	application/http 62		application/http 62
	message/http 61		message/http 61
	message 7		message 7
	message/http Media Type 61		message/http Media Type 61
	method 21		method 21
	N		N
	non-transforming proxy 48		non-transforming proxy 48
	O		O
	origin server 7		origin server 7
	origin-form (of request-target) 41		origin-form (of request-target) 41
	outbound 9		outbound 10
	P		P
	phishing 66		phishing 66
	proxy 10		proxy 10
	R		R
	recipient 7		recipient 7
	request 7		request 7
	request-target 21		request-target 21
	resource 16		resource 16
	skipping to change at page 86, line 35		skipping to change at page 86, line 30
	target URI 40		target URI 40
	TE header field 38		TE header field 38
	Trailer header field 39		Trailer header field 39
	Transfer-Encoding header field 28		Transfer-Encoding header field 28
	transforming proxy 48		transforming proxy 48
	transparent proxy 11		transparent proxy 11
	tunnel 10		tunnel 10
	U		U
	Upgrade header field 56		Upgrade header field 56
	upstream 9		upstream 10
	URI scheme		URI scheme
	http 16		http 16
	https 18		https 18
	user agent 7		user agent 7
	V		V
	Via header field 47		Via header field 47
	Authors' Addresses		Authors' Addresses
End of changes. 103 change blocks.
	176 lines changed or deleted		153 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/