BUG/MEDIUM: filters: Do not truncate HTTP response when body length is undefined
authorChristopher Faulet <cfaulet@haproxy.com>
Wed, 8 Feb 2017 08:45:13 +0000 (09:45 +0100)
committerWilly Tarreau <w@1wt.eu>
Wed, 8 Feb 2017 18:08:38 +0000 (19:08 +0100)
commitf1cc5d0eaf8ac56ef574d7349e34a255b149869a
treed6edc489d41ffc5af8831b8efc88017bf4113ebe
parent0d94576c74a4e6cef050b6cddb513fd9a363cf6c
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