From: Christopher Faulet <cfaulet@haproxy.com>
Date: Fri, 8 Jul 2022 07:22:17 +0000 (+0200)
Subject: BUG/MEDIUM: http-ana: Don't wait to have an empty buf to switch in TUNNEL state
X-Git-Tag: v2.7-dev2~81
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=52fc0cbaadf01a91b18465034b58c32188f7606a;p=thirdparty%2Fhaproxy.git

BUG/MEDIUM: http-ana: Don't wait to have an empty buf to switch in TUNNEL state

When we want to establish a tunnel on a side, we wait to have flush all data
from the buffer. At this stage the other side is at least in DONE state. But
there is no real reason to wait. We are already in DONE state on its
side. So all the HTTP message was already forwarded or planned to be
forwarded. Depending on the scheduling if the mux already started to
transfer tunneled data, these data may block the switch in TUNNEL state and
thus block these data infinitly.

This bug exists since the early days of HTX. May it was mandatory but today
it seems useless. But I honestly don't remember why this prerequisite was
added. So be careful during the backports.

This patch should be backported with caution. At least as far as 2.4. For
2.2 and 2.0, it seems to be mandatory too. But a review must be performed.
---

diff --git a/src/http_ana.c b/src/http_ana.c
index 021ad753b4..4b74dd60d0 100644
--- a/src/http_ana.c
+++ b/src/http_ana.c
@@ -4433,10 +4433,6 @@ static void http_end_request(struct stream *s)
 			 * poll for reads.
 			 */
 			channel_auto_read(chn);
-			if (b_data(&chn->buf)) {
-				DBG_TRACE_DEVEL("waiting to flush the request", STRM_EV_HTTP_ANA, s, txn);
-				return;
-			}
 			txn->req.msg_state = HTTP_MSG_TUNNEL;
 		}
 		else {
@@ -4556,10 +4552,6 @@ static void http_end_response(struct stream *s)
 		 */
 		if (txn->flags & TX_CON_WANT_TUN) {
 			channel_auto_read(chn);
-			if (b_data(&chn->buf)) {
-				DBG_TRACE_DEVEL("waiting to flush the respone", STRM_EV_HTTP_ANA, s, txn);
-				return;
-			}
 			txn->rsp.msg_state = HTTP_MSG_TUNNEL;
 		}
 		else {