BUG/MINOR: mux-quic/h3: properly handle too low peer fctl initial stream
authorAmaury Denoyelle <adenoyelle@haproxy.com>
Wed, 18 Jun 2025 13:12:31 +0000 (15:12 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Tue, 26 Aug 2025 06:28:01 +0000 (08:28 +0200)
commit541d2c9a9b124cb19f4346a8c2fff3ada354380a
tree5509d30f712e72e5bdb3f7a11eb6478d6ff25d04
parentdb39526525ec1124f8742410c573a621311c0ce3
BUG/MINOR: mux-quic/h3: properly handle too low peer fctl initial stream

Previously, no check on peer flow-control was implemented prior to open
a local QUIC stream. This was a small problem for frontend
implementation, as in this case haproxy as a server never opens
bidirectional streams.

On frontend, the only stream opened by haproxy in this case is for
HTTP/3 control unidirectional data. If the peer uses an initial value
for max uni streams set to 0, it would violate its flow control, and the
peer will probably close the connection. Note however that RFC 9114
mandates that each peer defines minimal initial value so that at least
the control stream can be created.

This commit improves the situation of too low initial max uni streams
value. Now, on HTTP/3 layer initialization, haproxy preemptively checks
flow control limit on streams via a new function
qcc_fctl_avail_streams(). If credit is already expired due to a too
small initial value, haproxy preemptively closes the connection using
H3_ERR_GENERAL_PROTOCOL_ERROR. This behavior is better as haproxy is now
the initiator of the connection closure.

This should be backported up to 2.8.

(cherry picked from commit 805a070ab920d14b22a6b7beac3b0648e684b2d2)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 47a4954c3974b85fc1b30ea723bf1d809e66e630)
[cf: context adjustment]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
include/haproxy/mux_quic-t.h
include/haproxy/mux_quic.h
src/h3.c
src/mux_quic.c