]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
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)
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

index ed1d6a360ea65a9388860fb593538bfd0aeb6493..99cb37f0662f5d7c65b186640a058f1488da4257 100644 (file)
@@ -1307,7 +1307,7 @@ int qcc_recv_reset_stream(struct qcc *qcc, uint64_t id, uint64_t err, uint64_t f
        qc_free_ncbuf(qcs, &qcs->rx.ncbuf);
 
        if (qcs_sc(qcs)) {
-               se_fl_set_error(qcs->sd);
+               se_fl_set(qcs->sd, SE_FL_EOS);
                qcs_alert(qcs);
        }