From: Christopher Faulet <cfaulet@haproxy.com>
Date: Tue, 29 Nov 2016 13:49:54 +0000 (+0100)
Subject: BUG/MINOR: http: Keep the same behavior between 1.6 and 1.7 for tunneled txn
X-Git-Tag: v1.8-dev1~315
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=3235957685f2eb4797a302a773a0f8776f068463;p=thirdparty%2Fhaproxy.git

BUG/MINOR: http: Keep the same behavior between 1.6 and 1.7 for tunneled txn

In HAProxy 1.6, When "http-tunnel" option is enabled, HTTP transactions are
tunneled as soon as possible after the headers parsing/forwarding. When the
transfer length of the response can be determined, this happens when all data
are forwarded. But for responses with an undetermined transfer length this
happens when headers are forwarded. This behavior is questionable, but this is
not the purpose of this fix...

In HAProxy 1.7, the first use-case works like in 1.6. But the second one not
because of the data filtering. HAProxy was always trying to forward data until
the server closes the connection. So the transaction was never switched in
tunnel mode. This is the expected behavior when there is a data filter. But in
the default case (no data filter), it should work like in 1.6.

This patch fixes the bug. We analyze response data until the server closes the
connection only when there is a data filter.

[wt: backport needed in 1.7]
---

diff --git a/src/proto_http.c b/src/proto_http.c
index 05c028fed8..1ba36e7d7a 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -7025,8 +7025,9 @@ http_msg_forward_body(struct stream *s, struct http_msg *msg)
 		goto missing_data_or_waiting;
 	}
 
-	if (!(msg->flags & HTTP_MSGF_XFER_LEN) && !(chn->flags & CF_SHUTR)) {
-		/* The server still sending data */
+	if (!(msg->flags & HTTP_MSGF_XFER_LEN) && !(chn->flags & CF_SHUTR) &&
+	    HAS_DATA_FILTERS(s, chn)) {
+		/* The server still sending data that should be filtered */
 		goto missing_data_or_waiting;
 	}
 	msg->msg_state = HTTP_MSG_ENDING;