< draft-ietf-httpbis-h2-websockets-00.txt		draft-ietf-httpbis-h2-websockets-01.txt >
	Network Working Group P. McManus		HTTP P. McManus
	Internet-Draft Mozilla		Internet-Draft Mozilla
	Intended status: Standards Track December 19, 2017		Intended status: Standards Track March 27, 2018
	Expires: June 22, 2018		Expires: September 28, 2018
	Bootstrapping WebSockets with HTTP/2		Bootstrapping WebSockets with HTTP/2
	draft-ietf-httpbis-h2-websockets-00		draft-ietf-httpbis-h2-websockets-01
	Abstract		Abstract
	This document defines a mechanism for running the WebSocket Protocol		This document defines a mechanism for running the WebSocket Protocol
	[RFC6455] over a single stream of an HTTP/2 connection.		over a single stream of an HTTP/2 connection.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 22, 2018.		This Internet-Draft will expire on September 28, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. The ENABLE_CONNECT_PROTOCOL SETTINGS Parameter . . . . . . . 3		3. The SETTINGS_ENABLE_CONNECT_PROTOCOL SETTINGS Parameter . . . 3
	4. The Extended CONNECT Method . . . . . . . . . . . . . . . . . 3		4. The Extended CONNECT Method . . . . . . . . . . . . . . . . . 3
	5. Using Extended CONNECT To Bootstrap The WebSocket Protocol . 4		5. Using Extended CONNECT To Bootstrap The WebSocket Protocol . 4
	5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5		5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Design Considerations . . . . . . . . . . . . . . . . . . . . 5		6. Design Considerations . . . . . . . . . . . . . . . . . . . . 5
	7. About Intermediaries . . . . . . . . . . . . . . . . . . . . 5		7. About Intermediaries . . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
	11. Normative References . . . . . . . . . . . . . . . . . . . . 6		11. Normative References . . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The Hypertext Transfer Protocol (HTTP) provides compatible resource		The Hypertext Transfer Protocol (HTTP) provides compatible resource
	level semantics across different versions but it does not offer		level semantics across different versions but it does not offer
	compatibility at the connection management level. Other protocols,		compatibility at the connection management level. Other protocols,
	such as WebSockets, that rely on connection management details of		such as WebSockets, that rely on connection management details of
	HTTP must be updated for new versions of HTTP.		HTTP must be updated for new versions of HTTP.
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	treating the stream as if were the TCP connection in that		treating the stream as if were the TCP connection in that
	specification.		specification.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in BCP 14,		and "OPTIONAL" are to be interpreted as described in BCP 14,
	[RFC2119].		[RFC2119].
	3. The ENABLE_CONNECT_PROTOCOL SETTINGS Parameter		3. The SETTINGS_ENABLE_CONNECT_PROTOCOL SETTINGS Parameter
	This document adds a new SETTINGS Parameter to those defined by		This document adds a new SETTINGS Parameter to those defined by
	[RFC7540] Section 6.5.2.		[RFC7540], Section 6.5.2.
	The new parameter is ENABLE_CONNECT_PROTOCOL (type = 0x8). The value		The new parameter name is SETTINGS_ENABLE_CONNECT_PROTOCOL. The
	of the parameter MUST be 0 or 1.		value of the parameter MUST be 0 or 1.
	Upon receipt of ENABLE_CONNECT_PROTOCOL with a value of 1 a client		Upon receipt of SETTINGS_ENABLE_CONNECT_PROTOCOL with a value of 1 a
	MAY use the Extended CONNECT definition of this document when		client MAY use the Extended CONNECT definition of this document when
	creating new streams. Receipt of this parameter by a server does not		creating new streams. Receipt of this parameter by a server does not
	have any impact.		have any impact.
	A sender MUST NOT send a ENABLE_CONNECT_PROTOCOL parameter with the		A sender MUST NOT send a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter
	value of 0 after previously sending a value of 1.		with the value of 0 after previously sending a value of 1.
	The use of a SETTINGS Parameter to opt-in to an otherwise		The use of a SETTINGS Parameter to opt-in to an otherwise
	incompatible protocol change is a use of "Extending HTTP/2" defined		incompatible protocol change is a use of "Extending HTTP/2" defined
	by section 5.5 of [RFC7540]. If a client were to use the provisions		by Section 5.5 of [RFC7540]. If a client were to use the provisions
	of the extended CONNECT method defined in this document without first		of the extended CONNECT method defined in this document without first
	receiving a ENABLE_CONNECT_PROTOCOL parameter with the value of 1 it		receiving a SETTINGS_ENABLE_CONNECT_PROTOCOL parameter, a non-
	would be a protocol violation.		supporting peer would detect a malformed request and generate a
			stream error (Section 8.1.2.6 of [RFC7540]).
	4. The Extended CONNECT Method		4. The Extended CONNECT Method
	The CONNECT Method of [RFC7540] Section 8.3 is modified in the		The CONNECT Method defined in Section 8.3 of [RFC7540] is modified in
	following ways:		the following ways:
	o A new pseudo-header :protocol MAY be included on request HEADERS		o A new pseudo-header :protocol MAY be included on request HEADERS
	indicating the desired protocol to be spoken on the tunnel created		indicating the desired protocol to be spoken on the tunnel created
	by CONNECT. The pseudo-header is single valued and contains a		by CONNECT. The pseudo-header is single valued and contains a
	value from the HTTP Upgrade Token Registry defined by [RFC7230].		value from the HTTP Upgrade Token Registry defined by [RFC7230].
	o On requests bearing the :protocol pseudo-header, the :scheme and		o On requests bearing the :protocol pseudo-header, the :scheme and
	:path pseudo-header fields MUST be included.		:path pseudo-header fields MUST be included.
	o On requests bearing the :protocol pseudo-header, the :authority		o On requests bearing the :protocol pseudo-header, the :authority
	pseudo-header field is interpreted according to [RFC7540]		pseudo-header field is interpreted according to Section 8.1.2.3 of
	Section 8.1.2.3 instead of [RFC7540] Section 8.3. In particular		[RFC7540] instead of Section 8.3 of [RFC7540]. In particular the
	the server MUST not make a new TCP connection to the host and port		server MUST not make a new TCP connection to the host and port
	indicated by the :authority.		indicated by the :authority.
	Upon receiving a CONNECT request bearing the :protocol pseudo-header		Upon receiving a CONNECT request bearing the :protocol pseudo-header
	the server establishes a tunnel to another service of the protocol		the server establishes a tunnel to another service of the protocol
	type indicated by the pseudo-header. This service may or may not be		type indicated by the pseudo-header. This service may or may not be
	co-located with the server.		co-located with the server.
	5. Using Extended CONNECT To Bootstrap The WebSocket Protocol		5. Using Extended CONNECT To Bootstrap The WebSocket Protocol
	The pseudo-header :protocol MUST be included in the CONNECT request		The pseudo-header :protocol MUST be included in the CONNECT request
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 43 ¶
	[RFC6455] requires the use of Connection and Upgrade headers that are		[RFC6455] requires the use of Connection and Upgrade headers that are
	not part of HTTP/2. They MUST not be included in the CONNECT request		not part of HTTP/2. They MUST not be included in the CONNECT request
	defined here.		defined here.
	[RFC6455] requires the use of a Host header which is also not part of		[RFC6455] requires the use of a Host header which is also not part of
	HTTP/2. The Host information is conveyed as part of the :authority		HTTP/2. The Host information is conveyed as part of the :authority
	pseudo-header which is required on every HTTP/2 transaction.		pseudo-header which is required on every HTTP/2 transaction.
	Implementations using this extended CONNECT to bootstrap WebSockets		Implementations using this extended CONNECT to bootstrap WebSockets
	do not do the processing of the [RFC6455] Sec-WebSocket-Key and Sec-		do not do the processing of the [RFC6455] Sec-WebSocket-Key and Sec-
	WebSocket-Accept headers as that functionality has been superceded by		WebSocket-Accept headers as that functionality has been superseded by
	the :protocol pseudo-header.		the :protocol pseudo-header.
	The Sec-WebSocket-Version, Origin [RFC6454], Sec-WebSocket-Protocol,		The Sec-WebSocket-Version, Origin [RFC6454], Sec-WebSocket-Protocol,
	and Sec-WebSocket-Extensions headers are used on the CONNECT request		and Sec-WebSocket-Extensions headers are used on the CONNECT request
	and response headers in the same way as defined in [RFC6455]. Note		and response headers in the same way as defined in [RFC6455]. Note
	that HTTP/1 header names were case insensitive and HTTP/2 requires		that HTTP/1 header names were case insensitive and HTTP/2 requires
	they be encoded as lower case.		they be encoded as lower case.
	After successfully processing the opening handshake the peers should		After successfully processing the opening handshake the peers should
	proceed with The WebSocket Protocol [RFC6455] using the HTTP/2 stream		proceed with The WebSocket Protocol [RFC6455] using the HTTP/2 stream
	from the CONNECT transaction as if it were the TCP connection		from the CONNECT transaction as if it were the TCP connection
	referred to in [RFC6455]. The state of the WebSocket connection at		referred to in [RFC6455]. The state of the WebSocket connection at
	this point is OPEN as defined by [RFC6455] Section 4.1.		this point is OPEN as defined by [RFC6455], Section 4.1.
	5.1. Example		5.1. Example
	[[ From Client ]] [[ From Server ]]		[[ From Client ]] [[ From Server ]]
	SETTINGS		SETTINGS
	ENABLE_CONNECT_PROTOCOL = 1		SETTINGS_ENABLE_CONNECT_PROTOCOL = 1
	HEADERS + END_HEADERS		HEADERS + END_HEADERS
	:method = CONNECT		:method = CONNECT
	:protocol = websocket		:protocol = websocket
	:scheme = https		:scheme = https
	:path = /chat		:path = /chat
	:authority = server.example.com:443		:authority = server.example.com
	sec-websocket-protocol = chat, superchat		sec-websocket-protocol = chat, superchat
	sec-websocket-extensions = permessage-deflate		sec-websocket-extensions = permessage-deflate
	sec-websocket-version = 13		sec-websocket-version = 13
	origin = http://www.example.com		origin = http://www.example.com
	HEADERS + END_HEADERS		HEADERS + END_HEADERS
	:status = 200		:status = 200
	sec-websocket-protocol = chat		sec-websocket-protocol = chat
	DATA		DATA
	WebSocket Data		WebSocket Data
	DATA + END_STREAM		DATA + END_STREAM
	WebSocket Data		WebSocket Data
	DATA + END_STREAM		DATA + END_STREAM
	WebSocket Data		WebSocket Data
	6. Design Considerations		6. Design Considerations
	A more native integration with HTTP/2 is certainly possible with		A more native integration with HTTP/2 is certainly possible with
	larger additions to HTTP/2. This design was selected to minimize the		larger additions to HTTP/2. This design was selected to minimize the
	solution complexity while still addressing the primary concern of		solution complexity while still addressing the primary concern of
	running HTTP/2 and WebSockets concurrently.		running HTTP/2 and WebSockets concurrently.
	7. About Intermediaries		7. About Intermediaries
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 33 ¶
	clients. This specification addresses that concern in two ways:		clients. This specification addresses that concern in two ways:
	o The CONNECT method is prohibited from being used by XMLHttpRequest		o The CONNECT method is prohibited from being used by XMLHttpRequest
	o The use of a pseudo-header is something that is connection		o The use of a pseudo-header is something that is connection
	specific and HTTP/2 does not ever allow to be created outside of		specific and HTTP/2 does not ever allow to be created outside of
	the protocol stack.		the protocol stack.
	9. IANA Considerations		9. IANA Considerations
	This document establishes a entry for the HTTP/2 Settings Registry		This document establishes an entry for the HTTP/2 Settings Registry
	that was established by [RFC7540] Section 11.3		that was established by Section 11.3 of [RFC7540].
	Name: ENABLE_CONNECT_PROTOCOL		Name: SETTINGS_ENABLE_CONNECT_PROTOCOL
	Code: 0x8		Code: 0x8
	Initial Value: 0		Initial Value: 0
	Specification: This document		Specification: This document
	10. Acknowledgments		10. Acknowledgments
	The 2017 HTTP Workshop had a very productive discussion that helped		The 2017 HTTP Workshop had a very productive discussion that helped
End of changes. 29 change blocks.
	53 lines changed or deleted		54 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/