From f1cc5d0eaf8ac56ef574d7349e34a255b149869a Mon Sep 17 00:00:00 2001 From: Christopher Faulet Date: Wed, 8 Feb 2017 09:45:13 +0100 Subject: [PATCH] BUG/MEDIUM: filters: Do not truncate HTTP response when body length is undefined Some users have experienced some troubles using the compression filter when the HTTP response body length is undefined. They complained about receiving truncated responses. In fact, the bug can be triggered if there is at least one filter attached to the stream but none registered to analyze the HTTP response body. In this case, when the body length is undefined, data should be forwarded without any parsing. But, because of a wrong check, we were starting to parse them. Because it was not expected, the end of response was not correctly detected and the response could be truncted. So now, we rely on HAS_DATA_FILTER macro instead of HAS_FILTER one to choose to parse HTTP response body or not. Furthermore, in http_response_forward_body, the test to not forward the server closure to the client has been updated to reflect conditions listed in the associated comment. And finally, in http_msg_forward_body, when the body length is undefined, we continue the parsing it until the server closes the connection without any on filters. So filters can safely stop to filter data during their parsing. This fix should be backported in 1.7 --- src/proto_http.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/src/proto_http.c b/src/proto_http.c index 23a7dc452..80ba5660b 100644 --- a/src/proto_http.c +++ b/src/proto_http.c @@ -6829,7 +6829,7 @@ int http_process_res_common(struct stream *s, struct channel *rep, int an_bit, s } skip_header_mangling: - if ((msg->flags & HTTP_MSGF_XFER_LEN) || HAS_FILTERS(s) || + if ((msg->flags & HTTP_MSGF_XFER_LEN) || HAS_DATA_FILTERS(s, rep) || (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_TUN) { rep->analysers &= ~AN_RES_FLT_XFER_DATA; rep->analysers |= AN_RES_HTTP_XFER_BODY; @@ -6980,8 +6980,8 @@ int http_response_forward_body(struct stream *s, struct channel *res, int an_bit * keep-alive is set on the client side or if there are filters * registered on the stream, we don't want to forward a close */ - if ((msg->flags & HTTP_MSGF_TE_CHNK) || !msg->body_len || - HAS_FILTERS(s) || + if ((msg->flags & HTTP_MSGF_TE_CHNK) || !(msg->flags & HTTP_MSGF_XFER_LEN) || + HAS_DATA_FILTERS(s, res) || (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_KAL || (txn->flags & TX_CON_WANT_MSK) == TX_CON_WANT_SCL) channel_dont_close(res); @@ -7073,11 +7073,10 @@ 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) && - HAS_DATA_FILTERS(s, chn)) { - /* The server still sending data that should be filtered */ + /* The server still sending data that should be filtered */ + if (!(msg->flags & HTTP_MSGF_XFER_LEN) && !(chn->flags & CF_SHUTR)) goto missing_data_or_waiting; - } + msg->msg_state = HTTP_MSG_ENDING; ending: