]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MINOR: mux-h2: refresh the idle_timer when the mux is empty
authorWilly Tarreau <w@1wt.eu>
Tue, 30 May 2023 13:42:35 +0000 (15:42 +0200)
committerWilly Tarreau <w@1wt.eu>
Wed, 31 May 2023 08:45:30 +0000 (10:45 +0200)
commitf279a2f148419efd3ecdbe84789ca97f297a6450
tree2f54e54c24dccfe946a2f7a3b804831a207cbb8a
parentd68f8b5a4af7bfc44cced622634e1f2b6e910af8
BUG/MINOR: mux-h2: refresh the idle_timer when the mux is empty

There's a rare case where on long fat pipes, we can see the keep-alive
timeout trigger before the end of the transfer of the last large object,
and the connection closed a bit quickly after the end of the transfer
because a GOAWAY is queued. The data are not destroyed, except that
the WINDOW_UPDATES from the client arriving late while the last data
are being drained by the socket buffers may at some point trigger a
reset, and some clients might choke a bit too early on these. Let's
make sure we only arm the idle_start timestamp once the output buffer
is empty. Of course it will still not cover for the data pending in the
socket buffers but it will at least let those in the buffer leave in
peace. More elaborate options can be used to protect the data in the
kernel buffers, such as the one described in GH issue #5.

It's very likely that this old issue was emphasized by the following
commit in 2.6:
  15a4733d5 ("BUG/MEDIUM: mux-h2: make use of http-request and keep-alive timeouts")

and the behavior probably changed again with this one in 2.8, which
was backported to 2.7 and scheduled for 2.6:
  d38d8c6cc ("BUG/MEDIUM: mux-h2: make sure control frames do not refresh the idle timeout")

As such this patch should be backported to 2.6 after some observation
period.
src/mux_h2.c