Amaury Denoyelle 47a61eb86d BUG/MINOR: mux_quic: do not exceed stream.max-concurrent on backend side ... Fix usage of stream.max-concurrent QUIC setting on the backend side. Contrary to frontend connections, this limit must be enforced by QUIC MUX directly. This is necessary as the peer may allow a larger number of concurrent streams via its flow control. First, QUIC TP initial max bidi streams value is now set to 0. This is fine as only the HTTP/3 client is expected to open bidirectional streams. The most important changes is performed in qcm_avail_streams(). The value first depends on the peer flow control. Now, it is further reduced if necessary to not exceed the configured BE stream.max-concurrent. Note that this new behavior may further increases current limitation on QUIC BE reuse when a QCS instance is kept while its upper stream layer is detached. In this case there is a risk that the connection is not reinserted in the correct server pool, as an idle or avail one. This is a breaking change as BE stream.max-concurrent keyword setting meaning is changed in effect. However, this does not necessitate extra warnings as the previous usage was in effect useless. Furthermore, QUIC on the backend side is still considered as experimental. This can be backported up to 3.3.		2026-05-20 14:42:03 +02:00
..
haproxy	BUG/MINOR: mux_quic: do not exceed stream.max-concurrent on backend side	2026-05-20 14:42:03 +02:00
import	MINOR: mjson: reintroduce mjson_next()	2026-04-14 10:57:21 +02:00
make	BUILD: makefile: add a qinfo macro to pass info in quiet mode	2025-01-08 11:26:05 +01:00