]> Fastly

kazuhooku@gmail.com

Cloudflare

lucas@lucaspardue.com

httpbis internet-draft This document specifies how to use HTTP/3 on top of bi-directional, byte-oriented streams such as TLS over TCP. 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 2023, 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 TCP, utilizing QUIC on Streams as the basis. QUIC on Streams, acting as a polyfill of QUIC atop bi-directional byte streams, enables the operation of HTTP/3 over TCP 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 . Conversely, HTTP/3 on Streams utilizes the same set of operations but functions over QUIC on Streams instead.

Starting HTTP/3 on Streams HTTP/3 on Streams can be used for “http” and “https” URI schemes defined in with the same default port numbers as HTTP/1.1 . When starting HTTP/3 on Streams for “https” URIs, clients use the TLS with the ALPN extension: “h3s”. Also, clients may learn that a particular server supports HTTP/3 on Streams by other means. A client that knows that a server supports HTTP/3 on Streams can establish a TCP connection and start exchanging HTTP/3 frames using QUIC on Streams. The latter is the only way to discover HTTP/3 on Streams for “http” URIs. When used in cleartext, servers can determine if or not the client is speaking HTTP/3 on Streams by comparing the first eight bytes to the encoded form of the QS_TRANSPORT_PARAMETERS frame type (Section 4.2 of ).

Support for Extended CONNECT Servers speaking HTTP/3 on Streams MUST implement the Extended CONNECT scheme defined in .

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

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 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 This document specifies a polyfill of QUIC version 1 that runs on top of bi-directional streams such as TLS. 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/kazuho/draft-kazuho-quic-quic-on-streams. 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 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. 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. 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. 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.