Le 29/06/2017 à 14:52, Brian Loss a écrit :
On Sat, Jun 03, 2017 at 00:19:19 +0000, Willy Tarreau wrote:
On Fri, Jun 02, 2017 at 06:17:38PM +0000, Bernard McCormack wrote:
> I've done some more testing. After changing the frontend ngnix to use '''
> proxy_http_version 1.1'''
> The errors stopped occurring. I wonder if it has to do with how haproxy
> handles http/1.0 request?
no because there is no fundamental difference between the two. However I
suspect that when you force nginx to 1.0 and it doesn't know the response,
it only uses close mode which triggers what looks like an haproxy bug. But
when you enable 1.1, it uses chunked encoding and there's no such issue
anymore.
I'll have a look.
Cheers,
Willy
We are seeing this as well on 1.7.5. The problem seems to be intermittent--it
doesn't happen very often when I hit a system with almost no load, but is
happening very frequently on a high load system. I don't believe it is causing
any issues other than the log message.
Hi,
I already proposed a patch to fix this bug in another thread[1]. I have
had no feedback yet. Could you check it please ?
[1] https://www.mail-archive.com/haproxy@formilux.org/msg26543.html
--
Christopher Faulet
diff --git a/src/proto_http.c b/src/proto_http.c
index e5f67e5..521743a 100644
--- a/src/proto_http.c
+++ b/src/proto_http.c
@@ -6958,14 +6958,6 @@ int http_response_forward_body(struct stream *s, struct channel *res, int an_bit
if ((msg->flags & HTTP_MSGF_TE_CHNK) || (msg->flags & HTTP_MSGF_COMPRESSING))
res->flags |= CF_EXPECT_MORE;
- /* If there is neither content-length, nor transfer-encoding header
- * _AND_ there is no data filtering, we can safely forward all data
- * indefinitely. */
- if (!(msg->flags & HTTP_MSGF_XFER_LEN) && !HAS_DATA_FILTERS(s, res)) {
- buffer_flush(res->buf);
- channel_forward_forever(res);
- }
-
/* the stream handler will take care of timeouts and errors */
return 0;
@@ -7042,9 +7034,20 @@ http_msg_forward_body(struct stream *s, struct http_msg *msg)
goto missing_data_or_waiting;
}
- /* 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;
+ /* This check can only be true for a response. HTTP_MSGF_XFER_LEN is
+ * always set for a request. */
+ if (!(msg->flags & HTTP_MSGF_XFER_LEN)) {
+ /* The server still sending data that should be filtered */
+ if (!(chn->flags & CF_SHUTR) && HAS_DATA_FILTERS(s, chn))
+ goto missing_data_or_waiting;
+ /* There is no data filtering (or no more data to filter) but at
+ * least one active filter on the stream. So force infinite
+ * forwarding here. */
+ else if (HAS_FILTERS(s)) {
+ buffer_flush(chn->buf);
+ channel_forward_forever(chn);
+ }
+ }
msg->msg_state = HTTP_MSG_ENDING;
