HTTP/3 on Streams
Internet-Draft draft-kazuho-httpbis-http3-on-streams-00
Kazuho Oku
Fastly
kazuhooku@gmail.com
Lucas Pardue
Cloudflare
lucas@lucaspardue.com
16 February 2024
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 https://lists.w3.org/Archives/Public/ietf-http-wg/.
Source for this draft and an issue tracker can be found at https://github.com/kazuho/draft-kazuho-httpbis-http3-on-streams.
Introduction
As of 2023, HTTP/2 [HTTP2] remains the most widely used version of HTTP across the Internet, although the adoption rate of HTTP/3 [HTTP3] is increasing rapidly.
HTTP/3 has several advantages over HTTP/2, primarily due to its use of QUIC [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 [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 [RFC2119] [RFC8174] 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 2.4 and Section 5.3 of [QUIC]. 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 Section 4.2 of [HTTP-SEMANTICS] with the same default port numbers as HTTP/1.1 [HTTP1].
When starting HTTP/3 on Streams for “https” URIs, clients use the TLS [TLS13] with the ALPN [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 [QUIC-ON-STREAMS]).
Support for Extended CONNECT
Servers speaking HTTP/3 on Streams MUST implement the Extended CONNECT scheme defined in [EXT-CONNECT3].
Security Considerations
TODO Security
IANA Considerations
This document has no IANA actions.
References
Normative References
[HTTP-SEMANTICS]

HTTP Semantics
R. Fielding, Ed.
M. Nottingham, Ed.
J. Reschke, Ed.
June 2022
STD 97
RFC 9110
DOI 10.17487/RFC9110
[HTTP3]

HTTP/3
M. Bishop, Ed.
June 2022
RFC 9114
DOI 10.17487/RFC9114
[QUIC-ON-STREAMS]

QUIC on Streams
Kazuho Oku
Fastly
Lucas Pardue
Cloudflare
16 February 2024
Internet-Draft draft-kazuho-quic-quic-on-streams-00
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[HTTP1]

HTTP/1.1
R. Fielding, Ed.
M. Nottingham, Ed.
J. Reschke, Ed.
June 2022
STD 99
RFC 9112
DOI 10.17487/RFC9112
[TLS13]

The Transport Layer Security (TLS) Protocol Version 1.3
E. Rescorla
August 2018
RFC 8446
DOI 10.17487/RFC8446
[ALPN]

Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension
S. Friedl
A. Popov
A. Langley
E. Stephan
July 2014
RFC 7301
DOI 10.17487/RFC7301
[EXT-CONNECT3]

Bootstrapping WebSockets with HTTP/3
R. Hamilton
June 2022
RFC 9220
DOI 10.17487/RFC9220
Informative References
[HTTP2]

HTTP/2
M. Thomson, Ed.
C. Benfield, Ed.
June 2022
RFC 9113
DOI 10.17487/RFC9113
[QUIC]

QUIC: A UDP-Based Multiplexed and Secure Transport
J. Iyengar, Ed.
M. Thomson, Ed.
May 2021
RFC 9000
DOI 10.17487/RFC9000
Acknowledgments
TODO acknowledge.