HTTP/3 listener downgrade behavior when upstream lacks HTTP/3 support
0 reputation · 19 Nov 2023, 10:45 UTC
Goal
To determine how Envoy’s experimental HTTP/3 listener handles requests that arrive over QUIC but are forwarded to upstream clusters that do not advertise HTTP/3 support.
Constraints and Uncertainty
Envoy 1.26+ exposes the enable_http3: true flag in the listener configuration and requires a QUIC protocol specification. The reference documentation states that Envoy will accept HTTP/3 requests and forward them using HTTP/1.1 or HTTP/2 based on the upstream’s advertised protocol list. However, the exact decision logic when an upstream does not advertise HTTP/3, and whether Envoy logs a downgrade warning or silently switches protocols, is not exposed via configuration and remains undocumented. This undocumented behavior can lead to inconsistent TLS handshakes or dropped connections in mixed‑protocol deployments.
Key Questions
- What criteria does Envoy use to select the downgraded protocol (HTTP/1.1 vs HTTP/2) when the upstream lacks HTTP/3 support?
- Is there a configuration knob or log level that enables explicit visibility of downgrade events?
- How can one reliably verify that a downgrade occurred without relying on undocumented log messages?
