]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: stream: properly handle client aborts during redispatch
authorWilly Tarreau <w@1wt.eu>
Fri, 12 Jan 2018 09:42:12 +0000 (10:42 +0100)
committerWilly Tarreau <w@1wt.eu>
Fri, 12 Jan 2018 09:47:48 +0000 (10:47 +0100)
commitd651ba14d44a7350b4506e9de7c7b44cc18a6bff
tree5eeb68a94758b0c10f1a7e4545282168a2173c18
parentec5e84552a0a2e0767431731c4f40d5627dc7bdd
BUG/MEDIUM: stream: properly handle client aborts during redispatch

James Mc Bride reported an interesting case affecting all versions since
at least 1.5 : if a client aborts a connection on an empty buffer at the
exact moment a server redispatch happens, the CF_SHUTW_NOW flag on the
channel is immediately turned into CF_SHUTW, which is not caught by
check_req_may_abort(), leading the redispatch to be performed anyway
with the channel marked as shut in both directions while the stream
interface correctly establishes. This situation makes no sense.
Ultimately the transfer times out and the server-side stream interface
remains in EST state while the client is in CLO state, and this case
doesn't correspond to anything we can handle in process_stream, leading
to poll() being woken up all the time without any progress being made.
And the session cannot even be killed from the CLI.

So we must ensure that check_req_may_abort() also considers the case
where the channel is already closed, which is what this patch does.
Thanks to James for providing detailed captures allowing to diagnose
the problem.

This fix must be backported to all maintained versions.
src/stream.c