]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: mux-h2: make use of http-request and keep-alive timeouts
authorWilly Tarreau <w@1wt.eu>
Fri, 18 Mar 2022 14:57:34 +0000 (15:57 +0100)
committerWilly Tarreau <w@1wt.eu>
Fri, 18 Mar 2022 16:43:34 +0000 (17:43 +0100)
commit15a4733d5d6af9540449b3e2981ab196b41317ee
tree5607d5c76a8ab3559ed882391a5cbf0261d66d49
parent3439583dd64cc2b0603fd4dac73b7b9506b826bc
BUG/MEDIUM: mux-h2: make use of http-request and keep-alive timeouts

Christian Ruppert reported an issue explaining that it's not possible to
forcefully close H2 connections which do not receive requests anymore if
they continue to send control traffic (window updates, ping etc). This
will indeed refresh the timeout. In H1 we don't have this problem because
any single byte is part of the stream, so the control frames in H2 would
be equivalent to TCP acks in H1, that would not contribute to the timeout
being refreshed.

What misses from H2 is the use of http-request and keep-alive timeouts.
These were not implemented because initially it was hard to see how they
could map to H2. But if we consider the real use of the keep-alive timeout,
that is, how long do we keep a connection alive with no request, then it's
pretty obvious that it does apply to H2 as well. Similarly, http-request
may definitely be honored as soon as a HEADERS frame starts to appear
while there is no stream. This will also allow to deal with too long
CONTINUATION frames.

This patch moves the timeout update to a new function, h2c_update_timeout(),
which is in charge of this. It also adds an "idle_start" timestamp in the
connection, which is set when nb_cs reaches zero or when a headers frame
start to arrive, so that it cannot be delayed too long.

This patch should be backported to recent stable releases after some
observation time. It depends on previous patch "MEDIUM: mux-h2: slightly
relax timeout management rules".
src/mux_h2.c