QUIC Support for HTTP3 in WebClient

[manonworldrepository]

📝 Proposal: Add QUIC (HTTP/3) Support to Spring WebClient

🎯 Motivation

QUIC is the transport protocol behind HTTP/3, offering:

Faster connection setup (0-RTT)

Stream multiplexing without head-of-line blocking

Built-in TLS 1.3 encryption

Better performance on mobile and lossy networks

Spring WebClient currently supports HTTP/1.1 and HTTP/2 via Reactor Netty. Adding QUIC support would future-proof the framework and enable high-performance reactive clients for modern web services.

🔧 Technical Approach

1. Choose a QUIC Implementation

Use Kwik, a 100% Java QUIC library that supports both client and server roles. It’s actively maintained and interoperable with other QUIC stacks.

2. Create a Custom ClientHttpConnector

Spring WebClient uses ClientHttpConnector to abstract the transport. You can implement a new connector:

public class QuicHttpConnector implements ClientHttpConnector {
    // Wrap Kwik's QuicClientConnection and QuicStream
}

3. Handle HTTP/3 Semantics

Use Kwik’s Flupke plugin to support HTTP/3 on top of QUIC. This handles:

Stream negotiation

Request/response framing

ALPN protocol selection

4. Integrate with Reactor

Ensure the connector supports non-blocking I/O and reactive streams:

Wrap Kwik’s input/output streams in Flux and Mono

Use DataBufferFactory for efficient memory handling

5. Configuration Options

Expose QUIC-specific settings:

ALPN protocol ID

0-RTT support

Cipher suite selection

Certificate validation toggle

🧪 Testing Strategy

Use public QUIC endpoints (e.g., Cloudflare, Google) for integration tests

Benchmark against HTTP/2 for latency and throughput

Simulate packet loss and connection migration scenarios

📚 Documentation & Samples

Provide usage examples:

WebClient client = WebClient.builder()
    .clientConnector(new QuicHttpConnector())
    .build(); 

Document limitations (e.g., stream prioritization not yet supported)

[bclozel]

Hi @manonworldrepository

Thank you for taking the time to draft this enhancement proposal for HTTP/3 and QUIC support in the Spring Framework. While we appreciate the initiative and the effort you’ve put into this, we’re unable to accept this proposal as it stands.

The functionality you’re requesting—HTTP/3 and QUIC support—is already available in Spring Framework via Reactor Netty, as documented in our official blog post. Reactor Netty has had robust HTTP/3 support for some time, and Spring WebFlux seamlessly integrates with it. This means developers can already build HTTP/3 applications today, without needing to introduce yet another dependency like kwik.

We encourage contributors to thoroughly research existing documentation and features before submitting enhancement proposals. It’s important to ensure that proposals address genuine gaps rather than duplicating functionality that’s already well-supported. In this case, a quick search or review of recent Spring blog posts would have clarified that HTTP/3 is not only supported but actively maintained.

If you’d like to contribute to Spring’s HTTP/3 story, we’d welcome improvements to the existing Reactor Netty integration—whether that’s documentation, performance optimizations, or developer experience enhancements. But adding a parallel implementation using kwik would introduce unnecessary fragmentation and maintenance overhead.

Thanks again for your interest in Spring. We’re always open to thoughtful, well-researched contributions!

[lobaorn-bitso]

Just a drive-by since I received the notification, for heads-up @bclozel from JDK 26 onwards there will be a HTTP/3 client available, so maybe in a 7.2 release it could be considered: openjdk/jdk#24751