Facebook Inc.

afrind@fb.com

Apple Inc.

One Apple Park Way Cupertino, California 95014 United States of America ekinnear@apple.com

Apple Inc.

One Apple Park Way Cupertino, California 95014 United States of America tpauly@apple.com

Google

vasilvv@google.com

Facebook Inc.

woo@fb.com

art webtrans Internet-Draft WebTransport is a protocol framework that enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/2 and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/2 connection. Note to Readers Discussion of this draft takes place on the WebTransport mailing list (webtransport@ietf.org), which is archived at <https://mailarchive.ietf.org/arch/search/?email_list=webtransport>. The repository tracking the issues for this draft can be found at <https://github.com/ekinnear/draft-webtransport-http2/issues>. The web API draft corresponding to this document can be found at <https://w3c.github.io/webtransport/>.

Introduction Currently, the only mechanism in HTTP/2 for server to client communication is server push. That is, servers can initiate unidirectional push promised streams to clients, but clients cannot respond to them; they can only accept them or discard them. Additionally, intermediaries along the path may have different server push policies and may not forward push promised streams to the downstream client. This best effort mechanism is not sufficient to reliably deliver messages from servers to clients, limiting server to client use-cases such as chat messages or notifications. Several techniques have been developed to workaround these limitations: long polling , WebSocket , and tunneling using the CONNECT method. All of these approaches have limitations. This document defines a mechanism for multiplexing non-HTTP data with HTTP/2 in a manner that conforms with the WebTransport protocol requirements and semantics . Using the mechanism described here, multiple WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/2 connection.

Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document follows terminology defined in Section 1.2 of . Note that this document distinguishes between a WebTransport server and an HTTP/2 server. An HTTP/2 server is the server that terminates HTTP/2 connections; a WebTransport server is an application that accepts WebTransport sessions, which can be accessed via an HTTP/2 server.

Protocol Overview WebTransport servers are identified by a pair of authority value and path value (defined in Sections 3.2 and 3.3 correspondingly). When an HTTP/2 connection is established, both the client and server have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to indicate that they both support WebTransport over HTTP/2. WebTransport sessions are initiated inside a given HTTP/2 connection by the client, who sends an extended CONNECT request . If the server accepts the request, an WebTransport session is established. The resulting stream will be further referred to as a CONNECT stream, and its stream ID is used to uniquely identify a given WebTransport session within the connection. The ID of the CONNECT stream that established a given WebTransport session will be further referred to as a Session ID. After the session is established, the peers can exchange data using the following mechanisms:

• Both client and server can create a bidirectional or unidirectional stream using a new HTTP/2 extension frame (WT_STREAM)
• A datagram can be sent using a new HTTP/2 extension frame WT_DATAGRAM.

A WebTransport session is terminated when the CONNECT stream that created it is closed.

Session Establishment

Establishing a Transport-Capable HTTP/2 Connection In order to indicate support for WebTransport, both the client and the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1" in their SETTINGS frame. Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated.

Extended CONNECT in HTTP/2 defines an extended CONNECT method in Section 4, enabled by the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter. An endpoint doesn not need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT setting implies that an endpoint supports extended CONNECT.

Creating a New Session As WebTransport sessions are established over HTTP/2, they are identified using the https URI scheme . In order to create a new WebTransport session, a client can send an HTTP CONNECT request. The :protocol pseudo-header field () MUST be set to webtransport (Section 7.1 ). The :scheme field MUST be https. Both the :authority and the :path value MUST be set; those fields indicate the desired WebTransport server. An Origin header MUST be provided within the request. Upon receiving an extended CONNECT request with a :protocol field set to webtransport, the HTTP/2 server can check if it has a WebTransport server associated with the specified :authority and :path values. If it does not, it SHOULD reply with status code 404 (Section 6.5.4, ). If it does, it MAY accept the session by replying with status code 200. The WebTransport server MUST verify the Origin header to ensure that the specified origin is allowed to access the server in question. From the client's perspective, a WebTransport session is established when the client receives a 200 response. From the server's perspective, a session is established once it sends a 200 response. Both endpoints MUST NOT open any streams or send any datagrams on a given session before that session is established.

Limiting the Number of Simultaneous Sessions From the flow control perspective, WebTransport sessions count against the stream flow control just like regular HTTP requests, since they are established via an HTTP CONNECT request. This document does not make any effort to introduce a separate flow control mechanism for sessions, nor to separate HTTP requests from WebTransport data streams. If the server needs to limit the rate of incoming requests, it has alternative mechanisms at its disposal:

• HTTP_STREAM_REFUSED error code defined in indicates to the receiving HTTP/2 stack that the request was not processed in any way.
• HTTP status code 429 indicates that the request was rejected due to rate limiting . Unlike the previous method, this signal is directly propagated to the application.

WebTransport Features WebTransport over HTTP/2 provides the following features described in : unidirectional streams, bidirectional streams and datagrams, initiated by either endpoint. Session IDs are used to demultiplex streams and datagrams belonging to different WebTransport sessions. On the wire, session IDs are encoded using a 31-bit integer field.

WT_STREAM Frame A new HTTP/2 frame called WT_STREAM is introduced for either endpoint to establish WebTransport streams. WT_STREAM frames can be sent on a stream in the "idle", "reserved (local)", "open", or "half-closed (remote)" state.

WT_STREAM Frame Format

The WT_STREAM frame define the following fields: Pad Length: An 8-bit field containing the length of the frame padding in units of octets. This field is conditional (as signified by a "?" in the diagram) and is only present if the PADDED flag is set. Session ID: An unsigned 31-bit integer that identifies the stream Connect Stream for this Web Transport stream. The Session ID MUST be MUST be an open stream negotiated via the extended CONNECT protocol with a :protocol value of "webtransport". The WT_STREAM frame defines the following flags: UNIDIRECTIONAL (0x1): When set, the stream begins in the "half-closed (remote)" state at the sender, and in the "half-closed (local)" state at the receiver. As with all HTTP/2 streams, WebTransport streams initiated by a client have odd stream IDs and those initiated by a server have even stream IDs. The recipient MUST respond with a stream error of type WT_STREAM_ERROR if the specified WebTransport Connect Stream does not exist, is not a stream established via extended CONNECT to use the "webtransport" protocol, or if it is in the "closed" or "half-closed (remote)" stream state.

WT_DATAGRAM Frame A new HTTP/2 frame called WT_DATAGRAM is introduced for either endpoint to transmit a datagram. WT_DATAGRAM frames are sent with Stream Identifier 0.

WT_DATAGRAM Frame Format

The WT_DATAGRAM frame define the following fields: Pad Length: An 8-bit field containing the length of the frame padding in units of octets. This field is conditional (as signified by a "?" in the diagram) and is only present if the PADDED flag is set. Session ID: An unsigned 31-bit integer that identifies the stream Connect Stream for this Web Transport stream. The Session ID MUST be MUST be an open stream negotiated via the extended CONNECT protocol with a :protocol value of "webtransport". Data: Application data. The amount of data is the remainder of the frame payload after subtracting the length of the other fields that are present. The WT_DATAGRAM frame does not define any flags. The recipient MAY respond with a stream error of type WT_STREAM_ERROR if the specified WebTransport Connect Stream does not exist, is not a stream established via extended CONNECT to use the "webtransport" protocol, or if it is in the "closed" or "half-closed (remote)" stream state. The data in WT_DATAGRAM frames is not subject to flow control. The receiver MAY discard this data if it does not have sufficient space to buffer it. An intermediary could forward the data in a WT_DATAGRAM frame over another protocol, such as WebTransport over HTTP/3. In QUIC, a datagram frame can span at most one packet. Because of that, the applications have to know the maximum size of the datagram they can send. However, when proxying the datagrams, the hop-by-hop MTUs can vary.

Session Termination An WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session. Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session.

Transport Properties The WebTransport framework defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols. Below are details about support in Http2Transport for those properties.

Stream Independence:

Http2Transport does not support stream independence, as HTTP/2 inherently has head of line blocking.

Partial Reliability:

Http2Transport does not support partial reliability, as HTTP/2 retransmits any lost data. This means that any datagrams sent via Http2Transport will be retransmitted regardless of the preference of the application. The receiver is permitted to drop them, however, if it is unable to buffer them.

Pooling Support:

Http2Transport supports pooling, as multiple transports using Http2Transport may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context.

Connection Mobility:

Http2Transport does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP , is used underneath HTTP/2 and TLS. Without such support, Http2Transport connections cannot survive network transitions.

Security Considerations WebTransport over HTTP/2 satisfies all of the security requirements imposed by on WebTransport protocols, thus providing a secure framework for client-server communication in cases when the client is potentially untrusted. WebTransport over HTTP/2 requires explicit opt-in through the use of HTTP SETTINGS; this avoids potential protocol confusion attacks by ensuring the HTTP/2 server explicitly supports it. It also requires the use of the Origin header, providing the server with the ability to deny access to Web-based clients that do not originate from a trusted origin. Just like HTTP traffic going over HTTP/2, WebTransport pools traffic to different origins within a single connection. Different origins imply different trust domains, meaning that the implementations have to treat each transport as potentially hostile towards others on the same connection. One potential attack is a resource exhaustion attack: since all of the transports share both congestion control and flow control context, a single client aggressively using up those resources can cause other transports to stall. The user agent thus SHOULD implement a fairness scheme that ensures that each transport within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.

IANA Considerations

HTTP/2 SETTINGS Parameter Registration The following entry is added to the "HTTP/2 Settings" registry established by : The SETTINGS_ENABLE_WEBTRANSPORT parameter indicates that the specified HTTP/2 connection is WebTransport-capable.

Setting Name:

ENABLE_WEBTRANSPORT

Value:

0x2b603742

Default:

0

Specification:

This document

Frame Type Registration The following entries are added to the "HTTP/2 Frame Type" registry established by : The WT_STREAM frame allows HTTP/2 client- and server-initiated unidirectional and bidirectional streams to be used by WebTransport:

Code:

0xTBD

Frame Type:

WEBTRANSPORT_STREAM

Specification:

This document

The WT_DATAGRAM frame allows HTTP/2 client and server to exchange datagrams used by WebTransport:

Code:

0xTBD

Frame Type:

WEBTRANSPORT_DATAGRAM

Specification:

This document

HTTP/2 Error Code Registry The following entries are added to the "HTTP/2 Error Code" registry that was established by Section 11.2 of .

Name:

WT_STREAM_ERROR

Code:

0xTBD

Description:

Invalid use of WT_STREAM frame

Specification:

RFC Editor: Please fill in this value with the RFC number for this document

Examples An example of negotiating a WebTransport Stream on an HTTP/2 connection follows. This example is intended to closely follow the example in Section 5.1 of to help illustrate the differences defined in this document. An example of the server initiating a WebTransport Stream follows. The only difference here is the endpoint that sends the first WT_STREAM frame.

References Normative References Google Google This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. [STANDARDS-TRACK] The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. Informative References On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments Thanks to Anthony Chivetta, Joshua Otto, and Valentin Pistol for their contributions in the design and implementation of this work.