Feature request: configuration option to disable HTTP/3 0-RTT (Early Data)

[steffenbusch]

Issue Details

I recently ran into a real interoperability issue related to HTTP/3 0-RTT being enabled by default in Caddy, and the lack of a configuration option to disable it.

After updating Chrome and Brave from version 144.0.7559.133 to 145.0.7632.76, I observed a behavioural change: these Chromium-based browsers now expose HTTP 425 Too Early responses directly to users instead of retrying the request transparently when Early Data is rejected. Firefox does not exhibit this behaviour and continues to retry the request internally.

This behaviour change is tracked in the Chromium issue tracker:
https://issues.chromium.org/issues/484218878

From the server perspective, rejecting Early Data with HTTP 425 is expected and compliant behaviour. However, since Caddy currently always enables 0-RTT together with HTTP/3 and does not provide a way to disable it, the only reliable workaround is to disable HTTP/3 entirely.

This is not ideal, since HTTP/3 itself works correctly, and the interoperability issue is limited specifically to 0-RTT handling in affected client versions.

Additional evidence

I observed the same behaviour when accessing https://caddyserver.com using Chrome. HTTP 425 Too Early responses are exposed directly to the user instead of being retried transparently.

This demonstrates that the issue is not specific to my configuration and also affects real-world deployments using Caddy with HTTP/3 enabled.

Current workaround

At the moment, the only practical workaround is to disable HTTP/3 completely in Caddy.

I also verified that rebuilding Caddy with Allow0RTT: false, in https://github.com/caddyserver/caddy/blob/master/listeners.go#L556 resolves the issue while keeping HTTP/3 fully functional.

Requested feature

Please provide a configuration option to disable HTTP/3 0-RTT (Early Data), independent of HTTP/3 itself.

This would allow operators to continue using HTTP/3 while mitigating client interoperability issues or regressions affecting Early Data handling.

Why this would be useful

Browser regressions and behavioural changes do occur, and even after fixes are implemented upstream, deployment to end users can take a significant time. A server-side option to disable 0-RTT would provide operators with a practical mitigation mechanism without requiring source modifications or disabling HTTP/3 entirely.

This would improve operational flexibility and robustness, especially in environments with mixed browser versions.

Environment

• Caddy version (production): 2.10.2
• Caddy version (reproduction): custom build from master using xcaddy run (commit: 929d0e502ad895737d7b0bafab18c63fb1d44cc1)
• HTTP/3 enabled
• Chrome and Brave 145.0.7632.76: affected
• Chrome 144.0.7559.133: not affected
• Firefox: unaffected
• Disabling HTTP/3 (protocols h1 h2) resolves the issue
• Rebuilding Caddy with Allow0RTT: false resolves the issue while preserving HTTP/3

Additional context

We (@WMACCESS) rely on Caddy in production and are a Caddy sponsor. We also supported quic-go development with a donation to @marten-seemann last year. We appreciate the work that has gone into making HTTP/3 support robust and performant. Providing a configuration option for disabling 0-RTT would help ensure continued reliable operation of HTTP/3 in production environments.

Assistance Disclosure

AI used

If AI was used, describe the extent to which it was used.

I used ChatGPT to assist with wording and structuring this report in English. All described behaviour, testing, verification, and technical investigation were performed by me.

[marten-seemann]

Under which circumstances does Caddy send 425?

[francislavoie]

It's here @marten-seemann

caddy/modules/caddyhttp/ip_matchers.go

Lines 154 to 162 in 929d0e5

	// MatchWithError returns true if r matches m.
	func (m MatchRemoteIP) MatchWithError(r *http.Request) (bool, error) {
	// if handshake is not finished, we infer 0-RTT that has
	// not verified remote IP; could be spoofed, so we throw
	// HTTP 425 status to tell the client to try again after
	// the handshake is complete
	if r.TLS != nil && !r.TLS.HandshakeComplete {
	return false, Error(http.StatusTooEarly, fmt.Errorf("TLS handshake not complete, remote IP cannot be verified"))
	}

Basically, in remote_ip or client_ip matchers where the user has conditional routing based on the remote address, if 0-RTT is used then Caddy may not actually have the remote address yet so we need to respond with 425 to avoid a security bypass.

[francislavoie]

Adding an option to disable 0-RTT in #7485

[marten-seemann]

This seems like a bug on the Chrome side, but adding an option sounds reasonable.

[francislavoie]

Yeah, browsers don't seem to consistently retry 425 responses as they should. Annoying. Chromium bug is tracked here (as mentioned in OP) https://issues.chromium.org/issues/484218878

[francislavoie]

Looks like the Chromium bug has been fixed 👍