]> Fastly

kazuhooku@gmail.com

Cloudflare

lucas@lucaspardue.com

Netflix

jri.ietf@gmail.com

httpbis internet-draft This document specifies how to use HTTP/3 over QMux. Discussion Venues Discussion of this document takes place on the HTTP Working Group mailing list (ietf-http-wg@w3.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction As of 2026, HTTP/2 remains the most widely used version of HTTP across the Internet, although the adoption rate of HTTP/3 is increasing rapidly. HTTP/3 has several advantages over HTTP/2, primarily due to its use of QUIC as the transport layer protocol, which provides features like stream multiplexing without head-of-line blocking and low-latency connection establishment. However, given that QUIC's availability and accessibility are not as universal as TCP's, a complete migration of all HTTP/2 traffic to QUIC-based HTTP/3 seems unlikely. This situation necessitates HTTP deployments to support both transport protocols and their respective HTTP versions for the foreseeable future. Maintaining dual support is costly, as the two protocols differ in many aspects such as wire-encoding, flow control and stream multiplexing machinery, and HTTP header compression. Extensions operating at the HTTP wire encoding layer must be developed and implemented for both HTTP/2 and HTTP/3, and both protocol stacks require ongoing maintenance to address bugs, performance issues, and vulnerabilities. To address this redundancy, this specification defines the method of running HTTP/3 over QMux version 1 , which enables the operation of HTTP/3 over TCP and TLS without any modifications. Consequently, design, implementation, and maintenance efforts can concentrate on a single HTTP version: HTTP/3.

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.

The Protocol HTTP/3 functions over QUIC version 1, employing the set of operations (i.e., API) defined in Section and Section of . HTTP/3 over QMux version 1 utilizes the same set of operations that are available in QMux.

QPACK Considerations HTTP/3 uses QPACK for field compression as described in . QPACK is designed to operate over QUIC version 1, which does not provide guarantees of global ordering across streams. It provides flexibility for implementations to balance resilience against head-of-line blocking and optimal compression ratio (). QMux version 1 operates on top of a transport layer that guarantees in-order delivery and guarantees global ordering across streams. When HTTP/3 over QMux is used, QPACK decoders will never be blocked due to packet losses. To improve compression efficiency, QPACK encoders can reference a dynamic table entry as soon as the entry is emitted to the underlying transport, regardless of the SETTINGS_QPACK_BLOCKED_STREAMS value advertised by the peer.

Starting HTTP/3 over QMux HTTP/3 over QMux version 1 can be used for “https” URI schemes defined in with the same default port number as HTTP/1.1 . When a client uses HTTP/3 over QMux for an "https" URI scheme, it uses TLS with ALPN as described in . The ALPN ID for the final, published RFC is "h3qx". Until such an RFC exists, implementations MUST NOT identify themselves using this string.

Draft Version Identification [[RFC editor: please remove this section before publication.]] This draft describes HTTP/3 over draft version of QMux. In order to support interoperability over revisions, HTTP/3 over QMux drafts define an ALPN ID that captures both this document revision and the QMux revision in use. The ALPN ID defined by this draft revision is "h3qx-01", which represents HTTP/3 over draft-ietf-quic-qmux-01.

Security Considerations The security considerations from and apply.

IANA Considerations If this document is adopted and published as an RFC, it will have an action to create a new registration for the identification of HTTP/3 over QMux version 1 in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in .

References Normative References 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. 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. Fastly Cloudflare Netflix Apple This document specifies QMux version 1. QMux version 1 provides, over bi-directional streams such as TLS, the same set of stream and datagram operations that applications rely upon in QUIC version 1. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/quicwg/qmux. 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 specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3. This is a variation of HPACK compression that seeks to reduce head-of-line blocking. 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. 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. 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 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.

Acknowledgments TODO acknowledge.