BUG/MEDIUM: mux-h1: Continue to process request when switching in tunnel mode
When input data are processed, if the request is switched in tunnel mode on a
protocol upgrade, we must continue the processing. Otherwise, pending input data
will only be processed on the next wakeup. So when new input data are received,
on a timeout expiration or shutdown. Worst, if the input buffer is full when it
happens, only a timeout or a shutdown will unblock the situation.
This patch should fix the issue #737. It must be backported as far as 1.9. The
bug does not seem to affect the 2.0 and 1.9 because, on a protocol upgrade, the
request is switched in tunnel mode when the response is sent to the client. But
the bug is present, so the backport remains necessary.
(cherry picked from commit 23021ad7f1d9d0e924aa5e5c6c4103b51a805af0)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 4814c74842d13dcf8d948910902f248263f80eed)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit cd12873354da09aead5c953a778a895b3ddc8823)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
diff --git a/src/mux_h1.c b/src/mux_h1.c
index 1254f2c..0ec519a 100644
--- a/src/mux_h1.c
+++ b/src/mux_h1.c
@@ -1515,9 +1515,12 @@
else if (h1m->state == H1_MSG_DONE) {
if (!(h1m->flags & H1_MF_RESP) && h1s->status == 101)
h1_set_req_tunnel_mode(h1s);
- else if (h1s->req.state < H1_MSG_DONE || h1s->res.state < H1_MSG_DONE)
+ else if (h1s->req.state < H1_MSG_DONE || h1s->res.state < H1_MSG_DONE) {
h1c->flags |= H1C_F_IN_BUSY;
- break;
+ break;
+ }
+ else
+ break;
}
else if (h1m->state == H1_MSG_TUNNEL) {
ret = h1_process_data(h1s, h1m, htx, &h1c->ibuf, &total, count, buf);