]> 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

Mozilla

mt@lowentropy.net

Google

vasilvv@google.com

Facebook Inc.

woo@fb.com

Web and Internet Transport WEBTRANS webtransport WebTransport defines a set of low-level communications features designed for client-server interactions that are initiated by Web clients. This document describes a protocol that can provide many of the capabilities of WebTransport over HTTP/2. This protocol enables the use of WebTransport when a UDP-based protocol is not available. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the WebTransport Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction WebTransport is designed to provide generic communication capabilities to Web clients that use HTTP/3 . The HTTP/3 WebTransport protocol allows Web clients to use QUIC features such as streams or datagrams . However, there are some environments where QUIC cannot be deployed. This document defines a protocol that provides all of the core functions of WebTransport using HTTP semantics. This includes unidirectional streams, bidirectional streams, and datagrams. By relying only on generic HTTP semantics, this protocol might allow deployment using any HTTP version. However, this document only defines negotiation for HTTP/2 as the current most common TCP-based fallback to HTTP/3.

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 . 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 using HTTP/2 and this protocol.

Protocol Overview WebTransport servers are identified by an HTTPS URI as defined in . When an HTTP/2 connection is established, the server sends a SETTINGS_WT_MAX_SESSIONS setting with a value greater than "0" to indicate that it supports WebTransport over HTTP/2. The value of the setting is the number of concurrent sessions the server is willing to receive. Note that the client does not need to send any value to indicate support for WebTransport; clients indicate support for WebTransport by using the "webtransport" upgrade token in CONNECT requests establishing WebTransport sessions (see ). A client initiates a WebTransport session by sending an extended CONNECT request . If the server accepts the request, a WebTransport session is established. The stream that carries the CONNECT request is used to exchange bidirectional data for the session. This stream will be referred to as a CONNECT stream. The stream ID of a CONNECT stream, which will be referred to as a Session ID, is used to uniquely identify a given WebTransport session within the connection. WebTransport using HTTP/2 uses extended CONNECT with the webtransport HTTP Upgrade Token (). This Upgrade Token uses the Capsule Protocol as defined in . After the session is established, endpoints exchange WebTransport messages using the Capsule Protocol on the bidirectional CONNECT stream, the "data stream" as defined in . Within this stream, WebTransport streams and WebTransport datagrams are multiplexed. In HTTP/2, WebTransport capsules are carried in HTTP/2 DATA frames. Multiple independent WebTransport sessions can share a connection if the HTTP version supports that, as HTTP/2 does. WebTransport capsules closely mirror a subset of QUIC frames and provide the essential WebTransport features. Within a WebTransport session, endpoints can create and use bidirectional or unidirectional streams with no additional round trips using the WT_STREAM capsule. Stream creation and data flow on streams uses flow control mechanisms modeled on those in QUIC. Flow control is managed using the WebTransport capsules: WT_MAX_DATA, WT_MAX_STREAM_DATA, WT_MAX_STREAMS, WT_DATA_BLOCKED, WT_STREAM_DATA_BLOCKED, and WT_STREAMS_BLOCKED. Flow control for the CONNECT stream as a whole, as provided by the HTTP version in use, applies in addition to any WebTransport-session-level flow control. WebTransport streams can be aborted using a WT_RESET_STREAM capsule and a receiver can request that a sender stop sending with a WT_STOP_SENDING capsule. A WebTransport session is terminated when the CONNECT stream that created it is closed. This implicitly closes all WebTransport streams that were multiplexed over that CONNECT stream.

Session Establishment and Termination A WebTransport session is a communication context between a client and server . This section describes how sessions begin and end.

Establishing a WebTransport-Capable HTTP/2 Connection In order to indicate potential support for WebTransport, the server MUST send the SETTINGS_ENABLE_CONNECT_PROTOCOL setting with a value of "1" in its SETTINGS frame. The client MUST NOT send a WebTransport request until it has received the setting indicating extended CONNECT support from the server.

Creating a New Session As WebTransport sessions are established over HTTP, 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 (). The :scheme field MUST be https. Both the :authority and the :path value MUST be set; those fields indicate the desired WebTransport server. In a Web context, the request MUST include an Origin header field that includes the origin of the site that requested the creation of the session. Upon receiving an extended CONNECT request with a :protocol field set to webtransport, the HTTP server checks if the identified resource supports WebTransport sessions. If the resource does not, the server SHOULD reply with status code 406 (). If it does, it MAY accept the session by replying with a 2xx series status code, as defined in . The WebTransport server MUST verify the Origin header to ensure that the specified origin is allowed to access the server in question. A WebTransport session is established when the server sends a 2xx response. A server generates that response from the request header, not from the contents of the request. To enable clients to resend data when attempting to re-establish a session that was rejected by a server, a server MUST NOT process any capsules on the request stream unless it accepts the WebTransport session. A client MAY optimistically send any WebTransport capsules associated with a CONNECT request, without waiting for a response, to the extent allowed by flow control. This can reduce latency for data sent by a client at the start of a WebTransport session. For example, a client might choose to send datagrams or flow control updates before receiving any response from the server.

Application Protocol Negotiation WebTransport over HTTP/2 offers a subprotocol negotiation mechanism, similar to TLS Application-Layer Protocol Negotiation Extension (ALPN) ; the intent is to simplify porting pre-existing protocols that rely on this type of functionality. The user agent MAY include a WT-Available-Protocols header field in the CONNECT request. The WT-Available-Protocols enumerates the possible protocols in preference order. If the server receives such a header, it MAY include a WT-Protocol field in a successful (2xx) response. If it does, the server MUST include a single choice from the client's list in that field. Servers MAY reject the request if the client did not include a suitable protocol. Both WT-Available-Protocols and WT-Protocol are defined in .

Session Termination and Error Handling A WebTransport session over HTTP/2 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session. Prior to closing the stream associated with the CONNECT request, either endpoint can send a WT_CLOSE_SESSION capsule with an application error code and message to convey additional information about the reasons for the closure of the session. Session errors result in the termination of a session. Errors can be reported using the WT_CLOSE_SESSION capsule, which includes an error code and an optional explanatory message. An endpoint can terminate a session without sending a WT_CLOSE_SESSION capsule by closing the HTTP/2 stream. An HTTP/2 stream that is reset terminates the session without providing an application-level signal, though there will be an HTTP/2 error code. This document reserves the following HTTP/2 error codes for use with reporting WebTransport errors:

WEBTRANSPORT_ERROR (0xTBD):

This generic error can be used for errors that do not have more specific error codes.

WEBTRANSPORT_STREAM_STATE_ERROR (0xTBD):

A stream-related capsule identified a stream that was in an invalid state.

Prior to terminating a stream with an error, a WT_CLOSE_SESSION capsule with an application-specified error code MAY be sent. Session errors do not necessarily result in any change of HTTP/2 connection state, except that an endpoint might choose to terminate a connection in response to stream errors; see .

Flow Control Flow control governs the amount of resources that can be consumed or data that can be sent. WebTransport over HTTP/2 allows a server to limit the number of sessions that a client can create on a single connection; see . For data, there are five applicable levels of flow control for data that is sent or received using WebTransport over HTTP/2:

1. TCP flow control.
2. HTTP/2 connection flow control, which governs the total amount of data in DATA frames for all HTTP/2 streams.
3. HTTP/2 stream flow control, which limits the data on a single HTTP/2 stream. For a WebTransport session, this includes all capsules, including those that are exempt from WebTransport session-level flow control.
4. WebTransport session-level flow control, which limits the total amount of stream data that can be sent or received on streams within the WebTransport session. Note that this does not limit other types of capsules within a WebTransport session, such as control messages or datagrams.
5. WebTransport stream flow control, which limits data on individual streams within a session.

TCP and HTTP/2 define the first three levels of flow control. This document defines the final two.

Limiting the Number of Simultaneous Sessions HTTP/2 defines a SETTINGS_MAX_CONCURRENT_STREAMS parameter that allows the server to limit the maximum number of concurrent streams on a single HTTP/2 session, which also limits the number of WebTransport sessions on that connection. Servers that wish to limit the rate of incoming WebTransport sessions on any particular HTTP/2 session have multiple mechanisms:

• The REFUSED_STREAM 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.

Limiting the Number of Streams Within a Session The WT_MAX_STREAMS capsule () allows each endpoint to limit the number of streams its peer is permitted to open as part of a WebTransport session. There is a separate limit for bidirectional streams and for unidirectional streams. Note that, unlike WebTransport over HTTP/3 , because the entire WebTransport session is contained within HTTP/2 DATA frames on a single HTTP/2 stream, this limit is the only mechanism for an endpoint to limit the number of WebTransport streams that its peer can open on a session.

Initial Flow Control Limits To allow stream data to be exchanged in the same flight as the extended CONNECT request that establishes a WebTransport session, initial flow control limits can be exchanged via HTTP/2 SETTINGS (). Initial values for the flow control limits can also be exchanged via the WebTransport-Init header field on the extended CONNECT request (). The limits communicated via HTTP/2 SETTINGS apply to all WebTransport sessions opened on that HTTP/2 connection. Limits communicated via the WebTransport-Init header field apply only to the WebTransport session established by the extended CONNECT request carrying that field. If both the SETTINGS and the header field are present when a WebTransport session is established, the endpoint MUST use the greater of the two values for each corresponding initial flow control value. Endpoints sending the SETTINGS and also including the header field SHOULD ensure that the header field values are greater than or equal to the values provided in the SETTINGS.

Flow Control SETTINGS Initial flow control limits can be exchanged via HTTP/2 SETTINGS () by providing non-zero values for

• WT_MAX_DATA via SETTINGS_WT_INITIAL_MAX_DATA
• WT_MAX_STREAM_DATA via SETTINGS_WT_INITIAL_MAX_STREAM_DATA_UNI, SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_LOCAL, and SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_REMOTE
• WT_MAX_STREAMS via SETTINGS_WT_INITIAL_MAX_STREAMS_UNI and SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI

WebTransport SETTINGS can be updated during the lifetime of the HTTP/2 connection. Updated values take effect for new sessions once they have been acknowledged by the peer, as described in . The initial flow control limits for a new session are determined by the most recently acknowledged SETTINGS values at the time the session is created. Sessions that are already established are not affected by changes to these SETTINGS, and their limits can only be updated using the corresponding flow control capsules.

Flow Control Header Field The WebTransport-Init HTTP header field can be used to communicate the initial values of the flow control windows, similar to how QUIC uses transport parameters. The WebTransport-Init is a Dictionary Structured Field (). If the WebTransport-Init field cannot be parsed correctly or does not have the correct type, the endpoint MUST reject the CONNECT request with a 4xx status code. The following keys are defined for the WebTransport-Init header field:

u:

The initial flow control limit for unidirectional streams opened by the recipient of this header field. MUST be an Integer.

bl:

The initial flow control limit for the bidirectional streams opened by the sender of this header field. MUST be an Integer.

br:

The initial flow control limit for the bidirectional streams opened by the recipient of this header field. MUST be an Integer.

If any of these keys are present but contain invalid values, the endpoint MUST reject the CONNECT request with a 4xx status code. Unknown keys and parameters in the dictionary MUST be ignored.

Flow Control and Intermediaries WebTransport over HTTP/2 uses several capsules for flow control, and all of these capsules define special intermediary handling as described in . These capsules, referred to as the "flow control capsules" are WT_MAX_DATA, WT_MAX_STREAM_DATA, WT_MAX_STREAMS, WT_DATA_BLOCKED, WT_STREAM_DATA_BLOCKED, and WT_STREAMS_BLOCKED. An endpoint MUST NOT wait for a WT_DATA_BLOCKED, WT_STREAM_DATA_BLOCKED, or WT_STREAMS_BLOCKED capsule before sending a WT_MAX_DATA, WT_MAX_STREAM_DATA, or WT_MAX_STREAMS capsule; doing so could result in the sender being blocked for at least an entire round trip. Endpoints SHOULD send flow control credit as they consume data or close streams (similar to the mechanism used in QUIC, see ). Because flow control in WebTransport is hop-by-hop and does not provide an end-to-end signal, intermediaries MUST consume flow control signals and express their own flow control limits to the next hop. The intermediary can send these signals via HTTP/3 flow control messages, HTTP/2 flow control messages, or as WebTransport flow control capsules, where appropriate. Intermediaries are responsible for storing any data for which they advertise flow control credit if that data cannot be immediately forwarded to the next hop. In practice, an intermediary that translates flow control signals between similar WebTransport protocols, such as between two HTTP/2 connections, can often simply reexpress the same limits received on one connection directly on the other connection. An intermediary that does not want to be responsible for storing data that cannot be immediately sent on its translated connection would ensure that it does not advertise a higher flow control limit on one connection than the corresponding limit on the translated connection.

WebTransport Features WebTransport over TCP-based HTTP semantics provides the following features described in : unidirectional streams, bidirectional streams, and datagrams, initiated by either endpoint. WebTransport streams and datagrams that belong to different WebTransport sessions are identified by the CONNECT stream on which they are transmitted, with one WebTransport session consuming one CONNECT stream.

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. Because WebTransport over TCP-based HTTP semantics relies on the underlying protocols to provide in order and reliable delivery, there are some notable differences from the way in which QUIC handles application data. For example, endpoints send stream data in order. As there is no ordering mechanism available for the receiver to reassemble incoming data, receivers assume that all data arriving in WT_STREAM capsules is contiguous and in order. Below are details about support in WebTransport over HTTP/2 for the properties defined by the WebTransport framework.

Unreliable Delivery:

WebTransport over HTTP/2 does not support unreliable delivery, as HTTP/2 retransmits any lost data. This means that any datagrams sent via WebTransport over HTTP/2 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:

WebTransport over HTTP/2 provides support for pooling. Every WebTransport session is an independent HTTP/2 stream and does not compete with other pooled WebTransport sessions for per-stream resources.

Stream Independence:

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

Connection Mobility:

WebTransport over HTTP/2 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, WebTransport over HTTP/2 connections cannot survive network transitions.

WebTransport Streams WebTransport streams have identifiers and states that mirror the identifiers (()) and states () of QUIC streams as closely as possible to aid in ease of implementation. WebTransport streams are identified by a numeric value, or stream ID. Stream IDs are only meaningful within the WebTransport session in which they were created. They share the same semantics as QUIC stream IDs, with client initiated streams having even-numbered stream IDs and server-initiated streams having odd-numbered stream IDs. Similarly, they can be bidirectional or unidirectional, indicated by the second least significant bit of the stream ID. Because WebTransport does not provide an acknowledgement mechanism for WebTransport capsules, it relies on the underlying transport's in order delivery to inform stream state transitions. Wherever QUIC relies on receiving an ack for a packet to transition between stream states, WebTransport performs that transition immediately.

Use of Keying Material Exporters WebTransport over HTTP/2 supports the use of TLS keying material exporters . Since the underlying HTTP/2 connection could be shared by multiple WebTransport sessions, WebTransport defines a mechanism for deriving a TLS exporter that separates keying material for different sessions. If the application requests an exporter for a given WebTransport session with a specified label and context, the resulting exporter SHALL be a TLS exporter as defined in with the label set to "EXPORTER-WebTransport" and the context set to the serialization of the "WebTransport Exporter Context" struct as defined below.

WebTransport Exporter Context struct

A TLS exporter API might permit the context field to be omitted. In this case, as with TLS 1.3, the WebTransport Application-Supplied Exporter Context becomes zero-length if omitted.

WebTransport Capsules WebTransport capsules mirror their QUIC frame counterparts as closely as possible to enable maximal reuse of any applicable QUIC infrastructure by implementors. WebTransport capsules use the Capsule Protocol defined in .

PADDING Capsule A PADDING capsule is an HTTP capsule of type=0x190B4D38 and has no semantic value. PADDING capsules can be used to introduce additional data between other HTTP datagrams and can also be used to provide protection against traffic analysis or for other reasons. Note that, when used with WebTransport over HTTP/2, the PADDING capsule exists alongside the ability to pad HTTP/2 frames (). HTTP/2 padding is hop-by-hop and can be modified by intermediaries, while the PADDING capsule traverses intermediaries. The PADDING capsule cannot be smaller than its own header, which means that the minimum size of the capsule is two bytes: one byte for the Type and one byte to encode "0" for the Length.

PADDING Capsule Format

The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field. A receiver is not obligated to verify padding but MAY treat non-zero padding as a stream error.

WT_RESET_STREAM Capsule A WT_RESET_STREAM capsule is an HTTP capsule of type=0x190B4D39 and allows either endpoint to abruptly terminate the sending part of a WebTransport stream. After sending a WT_RESET_STREAM capsule, an endpoint ceases transmission of WT_STREAM capsules on the identified stream. A receiver of a WT_RESET_STREAM capsule can discard any data in excess of the Reliable Size indicated, even if that data was already received. The WT_RESET_STREAM capsule follows the design of the QUIC RESET_STREAM_AT frame . Consequently, it includes a Reliable Size field. A WT_RESET_STREAM capsule MUST be sent after WT_STREAM capsules that include an amount of data equal to or in excess of the value in the Reliable Size field. A receiver MUST treat the receipt of a WT_RESET_STREAM with a Reliable Size smaller than the number of bytes it has received on the stream as a session error.

WT_RESET_STREAM Capsule Format

The WT_RESET_STREAM capsule defines the following fields:

Stream ID:

A variable-length integer encoding of the WebTransport stream ID of the stream being terminated.

Application Protocol Error Code:

A variable-length integer containing the application protocol error code that indicates why the stream is being closed. WebTransport application error codes are constrained to an unsigned 32-bit range defined in . This value MUST NOT exceed 0xffffffff, values larger than this MUST be treated as a session error of type WEBTRANSPORT_ERROR.

Reliable Size:

A variable-length integer indicating the amount of data that needs to be delivered to the application even though the stream is reset.

Unlike the equivalent QUIC frame, this capsule does not include a Final Size field. In-order delivery of WT_STREAM capsules ensures that the amount of session-level flow control consumed by a stream is always known by both endpoints. A WT_RESET_STREAM capsule MUST NOT be sent after a stream is closed or reset. While QUIC permits redundant RESET_STREAM frames, the ordering guarantee in HTTP/2 makes this unnecessary. A stream error of type WEBTRANSPORT_STREAM_STATE_ERROR MUST be sent if a WT_RESET_STREAM capsule is received for a stream that is not in a valid state.

WT_STOP_SENDING Capsule An HTTP capsule called WT_STOP_SENDING (type=0x190B4D3A) is introduced to communicate that incoming data is being discarded on receipt per application request. WT_STOP_SENDING requests that a peer cease transmission on a WebTransport stream.

WT_STOP_SENDING Capsule Format

The WT_STOP_SENDING capsule defines the following fields:

Stream ID:

A variable-length integer carrying the WebTransport stream ID of the stream being ignored.

Application Protocol Error Code:

A variable-length integer containing the application-specified reason the sender is ignoring the stream. WebTransport application error codes are constrained to an unsigned 32-bit range defined in . This value MUST NOT exceed 0xffffffff, values larger than this MUST be treated as a session error of type WEBTRANSPORT_ERROR.

As defined in , the recipient of a WT_STOP_SENDING capsule sends a WT_RESET_STREAM capsule in response, including the same error code, if the stream is the "Ready" or "Send" state. A WT_STOP_SENDING capsule MUST NOT be sent multiple times for the same stream. While QUIC permits redundant STOP_SENDING frames, the ordering guarantee in HTTP/2 makes this unnecessary. A stream error of type WEBTRANSPORT_STREAM_STATE_ERROR MUST be sent if a second WT_STOP_SENDING capsule is received.

WT_STREAM Capsule WT_STREAM capsules implicitly create a WebTransport stream and carry stream data. The Type field in the WT_STREAM capsule is either 0x190B4D3B or 0x190B4D3C. The least significant bit in the capsule type is the FIN bit (0x01), indicating when set that the capsule marks the end of the stream in one direction. Stream data consists of any number of 0x190B4D3B capsules followed by a terminal 0x190B4D3C capsule.

WT_STREAM Capsule Format

WT_STREAM capsules contain the following fields:

Stream ID:

The stream ID for the stream. The second least significant bit of the Stream ID indicates whether the stream is bidirectional or unidirectional, as described in .

Stream Data:

Zero or more bytes of data for the stream. Empty WT_STREAM capsules MUST NOT be used unless they open or close a stream; an endpoint MAY treat an empty WT_STREAM capsule that neither starts nor ends a stream as a session error.

A WT_STREAM capsule MUST NOT be sent after a stream is closed or reset. While QUIC permits redundant STREAM frames, the ordering guarantee in HTTP/2 makes this unnecessary. A stream error of type WEBTRANSPORT_STREAM_STATE_ERROR MUST be sent if a WT_STREAM capsule is received for a stream that is not in a valid state.

WT_MAX_DATA Capsule An HTTP capsule called WT_MAX_DATA (type=0x190B4D3D) () is used to inform the peer of the maximum amount of data that can be sent on the WebTransport session as a whole.

WT_MAX_DATA Capsule Format

WT_MAX_DATA capsules contain the following field:

Maximum Data:

A variable-length integer indicating the maximum amount of data that can be sent on the entire connection, in units of bytes.

All data sent in WT_STREAM capsules counts toward this limit. The sum of the lengths of Stream Data fields in WT_STREAM capsules MUST NOT exceed the value advertised by a receiver. If an endpoint receives an incoming WT_STREAM capsule with Stream Data in excess of this limit, it MUST close the WebTransport session with a WEBTRANSPORT_FLOW_CONTROL_ERROR session error. If an endpoint receives a WT_MAX_DATA capsule with a Maximum Data value less than a previously received value, it MUST close the WebTransport session with a WEBTRANSPORT_FLOW_CONTROL_ERROR session error. The WT_MAX_DATA capsule defines special intermediary handling, as described in . Intermediaries MUST consume WT_MAX_DATA capsules for flow control purposes and MUST generate and send appropriate flow control signals for their limits; see . The initial value for this limit MAY be communicated by sending a non-zero value for SETTINGS_WT_INITIAL_MAX_DATA.

WT_MAX_STREAM_DATA Capsule An HTTP capsule called WT_MAX_STREAM_DATA (type=0x190B4D3E) is introduced to inform a peer of the maximum amount of data that can be sent on a WebTransport stream.

WT_MAX_STREAM_DATA Capsule Format

WT_MAX_STREAM_DATA capsules contain the following fields:

Stream ID:

The stream ID of the affected WebTransport stream, encoded as a variable-length integer.

Maximum Stream Data:

A variable-length integer indicating the maximum amount of data that can be sent on the identified stream, in units of bytes.

All data sent in WT_STREAM capsules for the identified stream counts toward this limit. The sum of the lengths of Stream Data fields in WT_STREAM capsules on the identified stream MUST NOT exceed the value advertised by a receiver. If an endpoint receives an incoming WT_STREAM capsule with Stream Data in excess of this limit, it MUST close the WebTransport session with a WEBTRANSPORT_FLOW_CONTROL_ERROR session error. If an endpoint receives a WT_MAX_STREAM_DATA capsule with a Maximum Stream Data value less than a previously received value, it MUST close the WebTransport session with a WEBTRANSPORT_FLOW_CONTROL_ERROR session error. The WT_MAX_STREAM_DATA capsule defines special intermediary handling, as described in . Intermediaries MUST consume WT_MAX_STREAM_DATA capsules for flow control purposes and MUST generate and send appropriate flow control signals for their limits; see . Initial values for this limit for unidirectional and bidirectional streams MAY be communicated by sending non-zero values for SETTINGS_WT_INITIAL_MAX_STREAM_DATA_UNI, SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_LOCAL, and SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_REMOTE respectively. A WT_MAX_STREAM_DATA capsule MUST NOT be sent after a sender requests that a stream be closed with WT_STOP_SENDING. While QUIC permits redundant MAX_STREAM_DATA frames, the ordering guarantee in HTTP/2 makes this unnecessary. A stream error of type WEBTRANSPORT_STREAM_STATE_ERROR MUST be sent if a WT_MAX_STREAM_DATA capsule is received after a WT_STOP_SENDING capsule for the same stream.

WT_MAX_STREAMS Capsule An HTTP capsule called WT_MAX_STREAMS is defined by to inform the peer of the cumulative number of streams of a given type it is permitted to open. A WT_MAX_STREAMS capsule with a type of 0x190B4D3F applies to bidirectional streams, and a WT_MAX_STREAMS capsule with a type of 0x190B4D40 applies to unidirectional streams. Note that, because Maximum Streams is a cumulative value representing the total allowed number of streams, including previously closed streams, endpoints repeatedly send new WT_MAX_STREAMS capsules with increasing Maximum Streams values as streams are opened.

WT_MAX_STREAMS Capsule Format

WT_MAX_STREAMS capsules contain the following field:

Maximum Streams:

A count of the cumulative number of streams of the corresponding type that can be opened over the lifetime of the connection. This value cannot exceed 2⁶⁰, as it is not possible to encode stream IDs larger than 2⁶²-1.

An endpoint MUST NOT open more streams than permitted by the current stream limit set by its peer. For instance, a server that receives a unidirectional stream limit of 3 is permitted to open streams 3, 7, and 11, but not stream 15. Note that this limit includes streams that have been closed as well as those that are open. If an endpoint receives an incoming stream that would exceed the advertised Maximum Streams value, it MUST close the WebTransport session with a WEBTRANSPORT_FLOW_CONTROL_ERROR session error. Note that, like QUIC stream IDs, WebTransport stream IDs cannot be skipped. Opening a stream with a given ID implicitly opens all streams of the same type and direction with lower stream IDs. Even though WebTransport over HTTP/2 uses an ordered transport, an application can create a stream without immediately sending data on it. A higher-numbered stream might have data written to it first, causing it to appear at the peer before any data is sent on lower-numbered streams. For example, if the client's bidirectional stream limit is 3 and the server opens stream ID 15 (the fourth server-initiated bidirectional stream), this implicitly counts stream IDs 3, 7, 11, and 15 against the limit, which would violate the limit of 3. An endpoint that receives such a stream would close the WebTransport session with a WEBTRANSPORT_FLOW_CONTROL_ERROR error. If an endpoint receives a WT_MAX_STREAMS capsule with a Maximum Streams value less than a previously received value, it MUST close the WebTransport session with a WEBTRANSPORT_FLOW_CONTROL_ERROR session error. The WT_MAX_STREAMS capsule defines special intermediary handling, as described in . Intermediaries MUST consume WT_MAX_STREAMS capsules for flow control purposes and MUST generate and send appropriate flow control signals for their limits. Initial values for these limits MAY be communicated by sending non-zero values for SETTINGS_WT_INITIAL_MAX_STREAMS_UNI and SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI.

WT_DATA_BLOCKED Capsule A sender SHOULD send a WT_DATA_BLOCKED capsule (type=0x190B4D41) () when it wishes to send data but is unable to do so due to WebTransport session-level flow control. A sender is not required to send WT_DATA_BLOCKED capsules, however WT_DATA_BLOCKED capsules can be used as input to tuning of flow control algorithms and for debugging purposes.

WT_DATA_BLOCKED Capsule Format

WT_DATA_BLOCKED capsules contain the following field:

Maximum Data:

A variable-length integer indicating the session-level limit at which blocking occurred.

The WT_DATA_BLOCKED capsule defines special intermediary handling, as described in . Intermediaries MUST consume WT_DATA_BLOCKED capsules for flow control purposes and MUST generate and send appropriate flow control signals for their limits; see .

WT_STREAM_DATA_BLOCKED Capsule A sender SHOULD send a WT_STREAM_DATA_BLOCKED capsule (type=0x190B4D42) when it wishes to send data but is unable to do so due to stream-level flow control. A sender is not required to send WT_STREAM_DATA_BLOCKED capsules, however WT_STREAM_DATA_BLOCKED capsules can be used as input to tuning of flow control algorithms and for debugging purposes. This capsule is analogous to WT_DATA_BLOCKED (), but for stream-level data limits instead of session-level data limits.

WT_STREAM_DATA_BLOCKED Capsule Format

WT_STREAM_DATA_BLOCKED capsules contain the following fields:

Stream ID:

A variable-length integer indicating the WebTransport stream that is blocked due to flow control.

Maximum Stream Data:

A variable-length integer indicating the offset of the stream at which the blocking occurred.

The WT_STREAM_DATA_BLOCKED capsule defines special intermediary handling, as described in . Intermediaries MUST consume WT_STREAM_DATA_BLOCKED capsules for flow control purposes and MUST generate and send appropriate flow control signals for their limits; see . A WT_STREAM_DATA_BLOCKED capsule MUST NOT be sent after a stream is closed or reset. While QUIC permits redundant STREAM_DATA_BLOCKED frames, the ordering guarantee in HTTP/2 makes this unnecessary. A stream error of type WEBTRANSPORT_STREAM_STATE_ERROR MUST be sent if a WT_STREAM_DATA_BLOCKED capsule is received for a stream that is not in a valid state.

WT_STREAMS_BLOCKED Capsule A sender SHOULD send a WT_STREAMS_BLOCKED capsule (type=0x190B4D43 or 0x190B4D44) () when it wishes to open a stream but is unable to do so due to the maximum stream limit set by its peer. A WT_STREAMS_BLOCKED capsule of type 0x190B4D43 is used to indicate reaching the bidirectional stream limit, and a WT_STREAMS_BLOCKED capsule of type 0x190B4D44 is used to indicate reaching the unidirectional stream limit. A WT_STREAMS_BLOCKED capsule does not open the stream, but informs the peer that a new stream was needed and the stream limit prevented the creation of the stream. A sender is not required to send WT_STREAMS_BLOCKED capsules, however WT_STREAMS_BLOCKED capsules can be used as input to tuning of flow control algorithms and for debugging purposes.

WT_STREAMS_BLOCKED Capsule Format

WT_STREAMS_BLOCKED capsules contain the following field:

Maximum Streams:

A variable-length integer indicating the maximum number of streams allowed at the time the capsule was sent. This value cannot exceed 2⁶⁰, as it is not possible to encode stream IDs larger than 2⁶²-1.

The WT_STREAMS_BLOCKED capsule defines special intermediary handling, as described in . Intermediaries MUST consume WT_STREAMS_BLOCKED capsules for flow control purposes and MUST generate and send appropriate flow control signals for their limits.

DATAGRAM Capsule WebTransport over HTTP/2 uses the DATAGRAM capsule defined in to carry datagram traffic.

DATAGRAM Capsule Format

When used in WebTransport over HTTP/2, DATAGRAM capsules contain the following fields:

HTTP Datagram Payload:

The content of the datagram to be delivered.

The data in DATAGRAM capsules 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 DATAGRAM capsule 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. indicates that intermediaries that forward DATAGRAM capsules where QUIC datagrams are available forward the contents of the capsule as native QUIC datagrams, rather than as HTTP datagrams in a DATAGRAM capsule. Similarly, when forwarding DATAGRAM capsules used as part of a WebTransport over HTTP/2 session on a WebTransport session that natively supports QUIC datagrams, such as WebTransport over HTTP/3 , intermediaries follow the requirements in to use native QUIC datagrams.

WT_CLOSE_SESSION Capsule WebTransport over HTTP/2 uses the WT_CLOSE_SESSION capsule defined in to terminate a WebTransport session with an application error code and message. WebTransport sessions can be terminated by optionally sending a WT_CLOSE_SESSION capsule and then by closing the HTTP/2 stream associated with the session (see ).

WT_CLOSE_SESSION Capsule Format

When used in WebTransport over HTTP/2, WT_CLOSE_SESSION capsules contain the following fields:

Application Error Code:

A 32-bit error code provided by the application closing the connection.

Application Error Message:

A UTF-8 encoded error message string provided by the application closing the connection. The message takes up the remainder of the capsule, and its length MUST NOT exceed 1024 bytes.

An endpoint that sends a WT_CLOSE_SESSION capsule MUST then half-close the stream by sending an HTTP/2 frame with the END_STREAM flag set (). The recipient MUST close the stream upon receipt of the capsule by replying with an HTTP/2 frame with the END_STREAM flag set; note that it does not need to send a WT_CLOSE_SESSION capsule in response. Cleanly terminating a WebTransport session without a WT_CLOSE_SESSION capsule is semantically equivalent to terminating it with a WT_CLOSE_SESSION capsule that has an error code of 0 and an empty error string.

WT_DRAIN_SESSION Capsule HTTP/2 uses GOAWAY frames () to allow an endpoint to gracefully stop accepting new streams while still finishing processing of previously established streams. WebTransport over HTTP/2 uses the WT_DRAIN_SESSION capsule defined in to gracefully shut down a WebTransport session.

WT_DRAIN_SESSION Capsule Format

After sending or receiving either a WT_DRAIN_SESSION capsule or HTTP/2 GOAWAY frame, an endpoint MAY continue using the session and MAY open new WebTransport streams. The signal is intended for the application using WebTransport, which is expected to attempt to gracefully terminate the session as soon as possible.

Capsule Ordering and Reliability The use of an ordered and reliable transport means that a receiver does not need to tolerate capsules that arrive out of order. This differs from QUIC in that a receiver is required to treat the arrival of out of order frames rather than being tolerant. For an intermediary that forwards from an strongly-ordered transport (like ) to a reliable transport (like this protocol), it is necessary to maintain state for streams. A simple forwarding intermediary that directly translates one type of protocol unit into another without understanding the underlying state might cause a receiver to abort the session. For instance, after a RESET_STREAM frame is forwarded, an intermediary cannot forward a RESET_STREAM frame as a WT_RESET_STREAM capsule or a STREAM frame as a WT_STREAM capsule without error.

Requirements on TLS Usage Because TLS keying material exporters are only secure for authentication when they are uniquely bound to the TLS session , WebTransport requires either one of the following conditions:

• The TLS version in use is greater than or equal to 1.3 .
• The TLS version in use is 1.2, and the extended master secret extension has been negotiated.

Clients MUST NOT send WebTransport over HTTP/2 requests on connections that do not meet one of the two conditions above. If a server receives a WebTransport over HTTP/2 request on a connection that meets neither, the server MUST treat the request as malformed, as specified in .

Examples An example of negotiating a WebTransport Stream on an HTTP/2 connection follows. This example is intended to closely follow the example in 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 capsule.

Considerations for Future Versions Future versions of WebTransport that change the syntax of the CONNECT requests used to establish WebTransport sessions will need to modify the upgrade token used to identify WebTransport, allowing servers to offer multiple versions simultaneously ().

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. An application could attempt to exhaust resources by opening too many WebTransport sessions at once. In cases when the application is untrusted, a WebTransport client SHOULD limit the number of outgoing sessions it will open. Note that the security considerations of HTTP/2 apply to WebTransport over HTTP/2. In particular, the denial-of-service considerations in are relevant. WebTransport extends HTTP/2 with additional features that have legitimate uses but can become a burden when they are used unnecessarily or to excess. Once a WebTransport session is established on an HTTP/2 stream, there are new interaction modes that permit either endpoint to send WebTransport streams and datagrams to its peer. This is particularly novel for clients, which previously had limited exposure to unsolicited server-initiated traffic beyond server push (see ). An endpoint that does not monitor use of these features exposes itself to a risk of denial-of-service attack. Implementations track the use of WebTransport features, such as the number of incoming streams and datagrams, and set limits on their use as described in . An endpoint MAY treat activity that is suspicious as a stream error or choose to close the connection.

IANA Considerations This document registers an upgrade token (), new HTTP/2 settings (), HTTP/2 error codes (), new capsules (), and the WebTransport-Init header field ().

Upgrade Token Registration The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by Section 16.7 of . The "webtransport" label identifies HTTP/2 used as a protocol for WebTransport:

Value:

webtransport

Description:

WebTransport over HTTP/2

Reference:

This document

HTTP/2 SETTINGS Parameter Registration The following entries are added to the "HTTP/2 Settings" registry established by : The SETTINGS_WT_INITIAL_MAX_DATA parameter indicates the initial value for the session data limit, otherwise communicated by the WT_MAX_DATA capsule (). The default value for the SETTINGS_WT_INITIAL_MAX_DATA parameter is "0", indicating that the endpoint needs to send a WT_MAX_DATA capsule within each session before its peer is allowed to send any stream data within that session. Note that this limit applies to all WebTransport sessions that use the HTTP/2 connection on which this SETTING is sent.

Setting Name:

SETTINGS_WT_INITIAL_MAX_DATA

Code:

0x2b61

Initial Value:

0

Specification:

This document

The SETTINGS_WT_INITIAL_MAX_STREAM_DATA_UNI parameter indicates the initial value for the stream data limit for incoming unidirectional streams, otherwise communicated by the WT_MAX_STREAM_DATA capsule (). The default value for the SETTINGS_WT_INITIAL_MAX_STREAM_DATA_UNI parameter is "0", indicating that the endpoint needs to send WT_MAX_STREAM_DATA capsules for each stream within each individual WebTransport session before its peer is allowed to send any stream data on those streams. Note that this limit applies to all WebTransport streams on all sessions that use the HTTP/2 connection on which this SETTING is sent.

Setting Name:

SETTINGS_WT_INITIAL_MAX_STREAM_DATA_UNI

Code:

0x2b62

Initial Value:

0

Specification:

This document

The SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_LOCAL parameter indicates the initial value for the stream data limit for incoming data on bidirectional streams initiated by the sender of this setting, otherwise communicated by the WT_MAX_STREAM_DATA capsule (). The default value for the SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_LOCAL parameter is "0", indicating that the endpoint needs to send WT_MAX_STREAM_DATA capsules for each stream within each individual WebTransport session before its peer is allowed to send any stream data on those streams. Note that this limit applies to all WebTransport streams on all sessions that use the HTTP/2 connection on which this SETTING is sent.

Setting Name:

SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_LOCAL

Code:

0x2b63

Initial Value:

0

Specification:

This document

The SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_REMOTE parameter indicates the initial value for the stream data limit for incoming data on bidirectional streams initiated by the receiver of this setting, otherwise communicated by the WT_MAX_STREAM_DATA capsule (). The default value for the SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_REMOTE parameter is "0", indicating that the endpoint needs to send WT_MAX_STREAM_DATA capsules for each stream within each individual WebTransport session before its peer is allowed to send any stream data on those streams. Note that this limit applies to all WebTransport streams on all sessions that use the HTTP/2 connection on which this SETTING is sent.

Setting Name:

SETTINGS_WT_INITIAL_MAX_STREAM_DATA_BIDI_REMOTE

Code:

0x2b66

Initial Value:

0

Specification:

This document

The SETTINGS_WT_INITIAL_MAX_STREAMS_UNI parameter indicates the initial value for the unidirectional max stream limit, otherwise communicated by the WT_MAX_STREAMS capsule (). The default value for the SETTINGS_WT_INITIAL_MAX_STREAMS_UNI parameter is "0", indicating that the endpoint needs to send WT_MAX_STREAMS capsules on each individual WebTransport session before its peer is allowed to create any unidirectional streams within that session. Note that this limit applies to all WebTransport sessions that use the HTTP/2 connection on which this SETTING is sent.

Setting Name:

SETTINGS_WT_INITIAL_MAX_STREAMS_UNI

Code:

0x2b64

Initial Value:

0

Specification:

This document

The SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI parameter indicates the initial value for the bidirectional max stream limit, otherwise communicated by the WT_MAX_STREAMS capsule (). The default value for the SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI parameter is "0", indicating that the endpoint needs to send WT_MAX_STREAMS capsules on each individual WebTransport session before its peer is allowed to create any bidirectional streams within that session. Note that this limit applies to all WebTransport sessions that use the HTTP/2 connection on which this SETTING is sent.

Setting Name:

SETTINGS_WT_INITIAL_MAX_STREAMS_BIDI

Code:

0x2b65

Initial Value:

0

Specification:

This document

HTTP/2 Error Code Registration The following entries are added to the "HTTP/2 Error Code" registry established by : For WEBTRANSPORT_ERROR:

Code:

0xTBD

Name:

WEBTRANSPORT_ERROR

Description:

General WebTransport error detected

Reference:

For WEBTRANSPORT_STREAM_STATE_ERROR:

Code:

0xTBD

Name:

WEBTRANSPORT_STREAM_STATE_ERROR

Description:

Unexpected WebTransport stream-related capsule received

Reference:

For WEBTRANSPORT_FLOW_CONTROL_ERROR:

Code:

0xTBD

Name:

WEBTRANSPORT_FLOW_CONTROL_ERROR

Description:

A flow control error occurred

Reference:

Capsule Types The following entries are added to the "HTTP Capsule Types" registry established by : The PADDING capsule.

Value:

0x190B4D38

Capsule Type:

PADDING

Status:

permanent

Specification:

This document

Change Controller:

IETF

Contact:

WebTransport Working Group webtransport@ietf.org

Notes:

None

The WT_RESET_STREAM capsule.

Value:

0x190B4D39

Capsule Type:

WT_RESET_STREAM

Status:

permanent

Specification:

This document

Change Controller:

IETF

Contact:

WebTransport Working Group webtransport@ietf.org

Notes:

None

The WT_STOP_SENDING capsule.

Value:

0x190B4D3A

Capsule Type:

WT_STOP_SENDING

Status:

permanent

Specification:

This document

Change Controller:

IETF

Contact:

WebTransport Working Group webtransport@ietf.org

Notes:

None

The WT_STREAM capsule.

Value:

0x190B4D3B..0x190B4D3C

Capsule Type:

WT_STREAM

Status:

permanent

Specification:

This document

Change Controller:

IETF

Contact:

WebTransport Working Group webtransport@ietf.org

Notes:

None

The WT_MAX_STREAM_DATA capsule.

Value:

0x190B4D3E

Capsule Type:

WT_MAX_STREAM_DATA

Status:

permanent

Specification:

This document

Change Controller:

IETF

Contact:

WebTransport Working Group webtransport@ietf.org

Notes:

None

HTTP Header Field Name IANA will register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at https://www.iana.org/assignments/http-fields:

Field Name:

WebTransport-Init

Structured Type:

Dictionary

Status:

permanent

Reference:

This document

Comments:

None

References Normative References Apple Inc. Google The WebTransport Protocol Framework enables clients constrained by the Web security model to communicate with a remote server using a secure multiplexed transport. It consists of a set of individual protocols that are safe to expose to untrusted applications, combined with an abstract model that allows them to be used interchangeably. This document defines the overall requirements on the protocols used in WebTransport, as well as the common features of the protocols, support for some of which may be optional. Facebook Apple Inc. Google WebTransport [OVERVIEW] is a protocol framework that enables application clients constrained by the Web security model to communicate with a remote application server using a secure multiplexed transport. This document describes a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams, and datagrams, all multiplexed within the same HTTP/3 connection. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. 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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. 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] Fastly QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. 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. This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection. This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. 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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. Informative References This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. Most HTTP authentication schemes are probeable in the sense that it is possible for an unauthenticated client to probe whether an origin serves resources that require authentication. It is possible for an origin to hide the fact that it requires authentication by not generating Unauthorized status codes; however, that only works with non-cryptographic authentication schemes: cryptographic signatures require a fresh nonce to be signed. Prior to this document, there was no existing way for the origin to share such a nonce without exposing the fact that it serves resources that require authentication. This document defines a new non-probeable cryptographic authentication scheme.

Use with Other HTTP Versions While this document defines WebTransport negotiation and session establishment in terms of HTTP/2, the capsule-based mechanisms described here rely on generic HTTP semantics and the Capsule Protocol , and can generally be used over any HTTP version that supports these features. The primary HTTP-version-specific aspects of this protocol are the use of Extended CONNECT for session establishment and the use of HTTP SETTINGS for exchanging initial flow control limits (). Extended CONNECT is defined for HTTP/2 in and for HTTP/3 in . Other HTTP versions that support Extended CONNECT can use the "webtransport" upgrade token () to establish capsule-based WebTransport sessions. The flow control SETTINGS defined in this document use the same codepoints across HTTP versions, but their behavior differs. HTTP/2 allows SETTINGS to be updated during the lifetime of a connection with acknowledgment-based synchronization, while HTTP/3 SETTINGS are sent only once and are fixed for the connection lifetime. The WebTransport-Init header field () can be used to provide per-session initial flow control limits regardless of HTTP version. When a version-specific WebTransport protocol exists for a given HTTP version, endpoints SHOULD prefer it over the capsule-based protocol defined here. For example, WebTransport over HTTP/3 provides stream independence and unreliable datagram delivery by using native QUIC streams and datagrams, which are not available when using the capsule-based protocol over a single HTTP/3 stream.

Acknowledgments Thanks to Anthony Chivetta, Eric Gorbaty, Ankshit Jain, Joshua Otto, and Valentin Pistol for their contributions in the design and implementation of this work. The requirements on TLS usage were inspired by .