tree 468390b104830b5aaa16eabc533fbe735074f5fa
parent cdd2c36291e057e505a25f10c128ae90c946891a
author Willy Tarreau <w@1wt.eu> 1569917520 +0200
committer Willy Tarreau <w@1wt.eu> 1570803468 +0200
encoding latin1

BUG/MEDIUM: mux-h2: do not enforce timeout on long connections

Alexandre Derumier reported issue #308 in which the client timeout will
strike on an H2 mux when it's shorter than the server's response time.
What happens in practice is that there is no activity on the connection
and there's no data pending on output so we can expire it. But this does
not take into account the possibility that some streams are in fact
waiting for the data layer above. So what we do now is that we enforce
the timeout when:
  - there are no more streams
  - some data are pending in the output buffer
  - some streams are blocked on the connection's flow control
  - some streams are blocked on their own flow control
  - some streams are in the send/sending list

In all other cases the connection will not timeout as it means that some
streams are actively used by the data layer.

This fix must be backported to 2.0, 1.9 and probably 1.8 as well. It
depends on the new "blocked_list" field introduced by "MINOR: mux-h2:
add a per-connection list of blocked streams". It would be nice to
also backport "ebtree: make eb_is_empty() and eb_is_dup() take a const"
to avoid a build warning.

(cherry picked from commit c2ea47fb18664ac68d94da2fe0b30e1a626aa869)
[wt: adjusted context]
Signed-off-by: Willy Tarreau <w@1wt.eu>