]> git.ipfire.org Git - thirdparty/haproxy.git/commit
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)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Wed, 18 Jun 2025 15:18:55 +0000 (17:18 +0200)
commit805a070ab920d14b22a6b7beac3b0648e684b2d2
treecb0b5463209ee7e614fee7b2216bc8c1f2e211a6
parentc807182ec9730acc15da6dd7853625ec74dfcf48
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.
include/haproxy/mux_quic-t.h
include/haproxy/mux_quic.h
src/h3.c
src/mux_quic.c