BUG/MEDIUM: mux-h1: Properly close H1C if an error is reported before sending data
authorChristopher Faulet <cfaulet@haproxy.com>
Thu, 23 Jan 2025 09:31:41 +0000 (10:31 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Thu, 23 Jan 2025 10:33:21 +0000 (11:33 +0100)
commita324db489a0130bbaebbcd65cc29c6ac317681c8
tree01e2b23e7aeb9e2cfcdb1bff67449bc548282dbc
parent3ab7f050039aabefb6bc495c5ab47d320a2f1d77
BUG/MEDIUM: mux-h1: Properly close H1C if an error is reported before sending data

It is possible to have front H1 connections waiting for the client timeout
while they should be closed because a conneciton error was reported before
sebding an error message to the client. It is not a leak because the
connections are closed when the timeout expires but it is a waste of
ressources, especially if the client timeout is high.

When an early error message must be sent to the client, if an error was
already detected, no data are sent and the output buffer is released. At
this stage, the H1 connection is in CLOSING state and it must be
released. But because of a bug, this is not performed. The client timeout is
rearmed and the H1 connection is only closed when it expires.

To fix the issue, the condition to close a H1C must also be evaluated when
an error is detected before sending data.

It is only an issue with idle client connections, because there is no H1
stream in that case and the error message is generated by the mux itself.

This patch must be backported as far as 2.8.

(cherry picked from commit b18e988e0dabbb0c382d2dfb5b8701670a386dde)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit b833cbcf08ca7c9263e3be9112de8c7478a87ace)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
src/mux_h1.c