gamzinav/haproxy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

BUG/MEDIUM: mux-h1: Properly handle empty message when an error is triggered

Browse Source 
When a 400/408/500/501 error is returned by the H1 multiplexer, we first try
to get the error message of the proxy before using the default one. This may
be configured to be mapped on /dev/null or on an empty file. In that case,
no message is emitted, as expected. But everything is handled as the error
was successfully sent.

However, there is an bug here. In h1_send_error() function, this case is not
properly handled. The flag H1C_F_ABRTED is not set on the H1 connection as it
should be and h1_close() function is not called, leaving the H1 connection in an
undefined state.

It is especially an issue when a "empty" 408-Request-Time-out error is emitted
while there are data blocked in the output buffer. In that case, the connection
remains openned until the client closes and a "cR--"/408 is logged repeatedly, every
time the client timeout is reached.

This patch must backported as far as 2.8.

(cherry picked from commit 0d4271cdae18780de79e1ce997d562f91eeee316)
Signed-off-by: Willy Tarreau <w@1wt.eu>
This commit is contained in:
Christopher Faulet 2024-09-03 14:10:29 +02:00 committed by Willy Tarreau
parent 657e745c16
commit dfefb9953e
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
src/mux_h1.c
View File

@ -3523,7 +3523,7 @@ static int h1_send_error(struct h1c *h1c)
b_is_null(h1c->px->replies[rc]->body.errmsg)) {
/* Empty error, so claim a success */
ret = 1;
goto out;
goto out_abort;
}
if (h1c->flags & (H1C_F_OUT_ALLOC|H1C_F_OUT_FULL)) {
@ -3555,6 +3555,7 @@ static int h1_send_error(struct h1c *h1c)
h1s_destroy(h1c->h1s);
}
out_abort:
h1c->flags = (h1c->flags & ~(H1C_F_WAIT_NEXT_REQ|H1C_F_ABRT_PENDING)) | H1C_F_ABRTED;
h1_close(h1c);
out: