]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MINOR: http: Keep the same behavior between 1.6 and 1.7 for tunneled txn
authorChristopher Faulet <cfaulet@haproxy.com>
Tue, 29 Nov 2016 13:49:54 +0000 (14:49 +0100)
committerWilly Tarreau <w@1wt.eu>
Tue, 29 Nov 2016 16:03:01 +0000 (17:03 +0100)
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]

src/proto_http.c

index 05c028fed8f8a74aee3f614f75a5bae24ae8ed4f..1ba36e7d7a4e88e08d250fc91a57bb7ba07a9eaa 100644 (file)
@@ -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;