]> Meta Platforms, Inc.

ietf@bemasc.net

Zscaler

yrosomakho@zscaler.com

HTTP HTTP/3 was initially specified only for use with the QUIC version 1 transport protocol. This specification defines how to use HTTP/3 over a WebTransport session, which can be implemented using any WebTransport protocol. This enables operation of HTTP/3 when UDP based transport is not available, as well as server-initiated HTTP/3 requests. 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 HTTP mailing list (), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction HTTP versions 2 and earlier were primarily specified to run over a reliable stream transport. Initially, this transport was normally TCP, but TLS over TCP is now often used instead. Other reliable stream transports are also used, especially for interprocess HTTP requests on a single host. HTTP version 3 was specified only to run on QUIC version 1 , but its specification anticipates support for other transports ():

• The use of other QUIC transport versions with HTTP/3 MAY be defined by future specifications.

In fact, nothing in HTTP/3 relies on the transport being a QUIC version at all, so long as it provides transport capabilities similar to QUICv1. These include:

• A session establishment procedure.
• Support for multiple streams within a session.
• Unidirectional and bidirectional streams, initiated by either party.
• Transmission of independent datagrams (for HTTP/3 Datagrams ).

Another transport system that provides these capabilities is the WebTransport session interface , which we refer to here as "WebTransport". WebTransport can be implemented within an HTTP/2 or HTTP/3 connection, and implementations based on WebSocket and other protocols have been proposed. A WebTransport server endpoint can always be identified by a URI, which might or might not use the "https" URI scheme. After a WebTransport session is established, the interface presented to the client and server are largely identical. Either party can open or accept new streams of either type, send datagrams, and eventually terminate the session. Thus, once we have defined HTTP/3 over WebTransport (H3-WT), it is straightforward to define Reverse H3-WT, in which the HTTP client and server roles are reversed. H3-WT is a general-purpose specification that may be put to various uses. One motivating use case for Forward H3-WT is to enable HTTP/3 over a TCP-based WebTransport protocol, for cases where the client and server prefer HTTP/3 but a network element only permits TCP. Other creative uses are also possible. For Reverse H3-WT, one motivating use case is to enable a hidden backend server to delegate TCP server functions to a proxy server. With this specification, the hidden backend can create a Reverse H3-WT session over which the proxy can issue multiple HTTP CONNECT requests.

Conventions and Definitions The key words "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.

Roles To distinguish actions on the WebTransport session from actions on the H3-WT connection that it carries, we define the following roles:

• Dialer - initiates the WebTransport session
• Listener - accepts the WebTransport session
• Client - sends requests on the H3-WT session
• Server - receives these HTTP requests
• Participant - A Client or Server.

In Forward H3-WT, the Dialer is the Client. In Reverse H3-WT, the Dialer is the Server.

Specification

Establishment Establishment of an H3-WT session is not constrained by this specification. Any new WebTransport session MAY be used with this specification, subject to prior arrangement by the endpoints. This specification does not constrain any URLs or protocol IDs associated with the session establishment process. A future specification could allocate TLS ALPN IDs that indicate the use of this specification with a particular WebTransport protocol.

Applicability An H3-WT connection can carry HTTP requests with any method, scheme, authority, and path. These values are not constrained by any similar values that may have applied to the WebTransport session itself. For example, if the Listener's URI is "https://my-origin.example.com/wt", this does not limit the origins to which requests may be sent on the H3-WT connection. Clients MUST determine the permissible set of origins for an H3-WT session by private arrangement (see ). Servers SHOULD send an ORIGIN frame at the beginning of the connection to indicate which origins are actually available on the session, unless that set is unambiguous (i.e., fixed by private arrangement) or unbounded (e.g., in the case of a proxy service).

Streams To create a stream, participants use WebTransport's "create a unidirectional stream" or "create a bidirectional stream" operation. If this operation fails, it MUST produce a connection error of type H3_STREAM_CREATION_ERROR. To accept a stream, participants use WebTransport's "receive a unidirectional stream" and "receive a bidirectional stream" operations. Participants MUST accept additional unidirectional streams whenever there are fewer than 3 active, and SHOULD accept additional bidirectional streams whenever there are fewer than 100. If the Client receives a bidirectional stream, and no HTTP extension has been negotiated to permit this stream, it MUST produce a connection error of type H3_STREAM_CREATION_ERROR.

Stream IDs WebTransport streams do not expose a Stream ID. To enable HTTP/3 functions that rely on Stream IDs, such as GOAWAY () and Datagrams, the creator of each stream MUST write the H3-WT Stream ID at the beginning of each stream, and the H3-WT receiver must consume this Stream ID before passing the stream to HTTP/3. The H3-WT Stream ID is encoded as a QUIC variable-length integer () and follows the QUICv1 stream numbering convention (), so the Client's first stream has stream ID 0x00.

Datagrams If SETTINGS_H3_DATAGRAM was negotiated on the H3-WT connection, participants send and receive each HTTP/3 Datagram using the WebTransport "send a datagram" and "receive a datagram" operations. HTTP/3 MUST derive the datagram's Quarter Stream ID from the corresponding stream's H3-WT Stream ID. Note that datagrams in H3-WT may be unreliable even when H3-WT is running over a reliable protocol, as the HTTP request or the WebTransport session may be forwarded by an intermediary onto a connection that uses a different protocol.

Closure and Errors When closing a stream successfully, participants use the WebTransport "send bytes" operation with a FIN indication. Receipt of a FIN indication in "receive bytes" indicates successful completion of the stream. When closing a stream abruptly, the stream error code is passed to the WebTransport "abort send side" or "abort receive side" operation as appropriate, and retrieved by the other participant from the "send side aborted" or "receive side aborted" event. An H3-WT connection is terminated using the WebTransport "terminate a session" operation. The connection error is passed to this operation and retrieved by the other participant from the "session terminated" event.

Security Considerations HTTP clients generally rely on the transport (TCP, TLS, or QUIC) to ensure that they are connected to the intended server before sending a request. For "https" URIs, this involves TLS server authentication. In H3-WT, the implementor is responsible for employing suitable authentication of the WebTransport session. WebTransport guarantees TLS-equivalent authentication of the Listener to the Dialer, which may be sufficient for some Forward H3-WT deployments. Authentication of the Dialer to the Listener can be accomplished using TLS client authentication (if exposed by the WebTransport protocol), HTTP Authentication (when using WebTransport over HTTP), or Capability URLs (when using WebTransport with a URI scheme that supports a non-empty path). If the WebTransport protocol exposes a TLS Exported Authenticator capability, participants MAY use it to enable Secondary Certificate Authentication and/or HTTP Concealed Authentication within the H3-WT session.

Examples

Hidden Origin Configuration In some cases, it can be desirable for an HTTP origin server to operate through a public gateway without exposing a publicly reachable IP address. For example, the origin server might be subject to request flood attacks if its IP address were publicly reachable. Reverse H3-WT allows a hidden origin server to make itself available only to the gateway. One potential implementation proceeds as follows:

1. The public gateway instructs the origin operator to use "https://gateway.example/reverse/$customer_id" as the URL for Reverse H3-WT, along with a specified secret Bearer token.
2. The origin operator selects a generic HTTP gateway implementation that supports Reverse H3-WT over HTTP with Bearer authentication, and configures it to forward requests to the origin server.
3. The origin operator configures this local gateway with the specified URL and Bearer token for Reverse H3-WT.
4. The local gateway opens a WebTransport session to the public gateway using an Extended CONNECT request to the specified URL.
5. The public gateway verifies that the Extended CONNECT request carries the correct Bearer token for this customer ID.
6. The local gateway uses the ORIGIN frame to enumerate the origins that are available on this session.
7. The public gateway validates that this customer is permitted to serve the indicated origins.
8. The public gateway starts forwarding incoming HTTP requests for those origins over this session.

Hidden Origin Configuration

IANA Considerations This document has no IANA actions.

References Normative References 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. 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. 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 Inc. Apple Inc. Apple Inc. Mozilla Google Facebook Inc. 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. Facebook Apple Inc. Google WebTransport [OVERVIEW] 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/3 [HTTP3] and provides support for unidirectional streams, bidirectional streams and datagrams, all multiplexed within the same HTTP/3 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. The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it needs to be separately registered. This document describes the ORIGIN frame for HTTP/3. Informative References 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 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. Apple Akamai This document defines a way for HTTP/2 and HTTP/3 servers to send additional certificate-based credentials after a TLS connection is established, based on TLS Exported Authenticators. 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. Linden Research This memo explains a method for making HTTP requests to a host that cannot be contacted directly. Typically, such a host is behind a firewall and/or a network address translation system. This document introduces a negotiated extension to HTTP/2 that turns a single HTTP/2 connection into a bi-directional communication channel. Meta Platforms, Inc. Nokia Orange SAP SE This document defines a secure transport for HTTP in which the client and server roles are reversed. This arrangement improves the origin server's protection from Layer 3 and Layer 4 denial-of-service attacks when an intermediary is in use. It allows origin server's to be hosted without being publicly (and directly) accessible but allows clients to access these servers via an intermediary. Fastly This document specifies an HTTP extension to establish bi-directional byte streams in the direction from servers to their clients, utilizing HTTP as a tunneling mechanism. This approach not only facilitates communication between servers located behind firewalls and their known clients but also introduces the potential for these known clients to serve as relays. In such configurations, clients can forward application protocol messages or relay TCP connections, allowing servers to interact with any client on the Internet without direct exposure.

Acknowledgments This specification is inspired by earlier proposals related to reversing connection establishment over HTTP, including: