]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MINOR: mux-quic: only set EOS on RESET_STREAM recv
authorAmaury Denoyelle <adenoyelle@haproxy.com>
Wed, 24 May 2023 08:49:44 +0000 (10:49 +0200)
committerAmaury Denoyelle <adenoyelle@haproxy.com>
Wed, 24 May 2023 12:39:17 +0000 (14:39 +0200)
commit37d78997ae90794b820da1c4263037f183aca24a
treee3314c6e8c3bfe03c5c2f9396351cc1a2623455c
parent8de35925f71c80df61e950e3714783f096f7f228
MINOR: mux-quic: only set EOS on RESET_STREAM recv

A recent review was done to rationalize ERR/EOS/EOI flags on stream
endpoint. A common definition for both H1/H2/QUIC mux have been written
in the following documentation :
 ./doc/internals/stconn-close.txt

In QUIC it is possible to close each channels of a stream independently
with RESET_STREAM and STOP_SENDING frames. When a RESET_STREAM is
received, it indicates that the peer has ended its transmission in an
abnormal way. However, it is still ready to receive.

Previously, on RESET_STREAM reception, QUIC MUX set the ERR flag on
stream-endpoint. However, according to the QUIC mechanism, it should be
instead EOS but this was impossible due to a BUG_ON() which prevents EOS
without EOI or ERR. This BUG_ON was only present because this case was
never used before the introduction of QUIC. It was removed in a recent
commit which allows us to now properly set EOS alone on RESET_STREAM
reception.

In practice, this change allows to continue to send data even after
RESET_STREAM reception. However, currently browsers always emit it with
a STOP_SENDING as this is used to abort the whole H3 streams. In the end
this will result in a stream-endpoint with EOS and ERR_PENDING/ERR
flags.

This should be backported up to 2.7.
src/mux_quic.c