Le 05/08/2020 à 12:22, Oliver Kelly a écrit :
I've opened https://github.com/haproxy/haproxy/issues/798
Here is a patch for the 1.8. Could you validate it fixes your issue ?
It fixes a bug introduced in 2.0 by the commit 6ad7cd981 ("BUG/MEDIUM: mux-h2:
Emit an error if the response chunk formatting is incomplete"). But it only
happens with H1 chunk responses. On the 2.0, a good workaround is to enable the
HTX mode.
On Wed, Aug 5, 2020 at 7:51 PM Bram Gillemon <b...@x-plose.be
<mailto:b...@x-plose.be>> wrote:
I upgraded the server to the 2.2 LTS version and i have the same behaviour
in that version.
If needed i can provide a testing environment.
If the 2.2 also fail, it may be an totally unrelated bug. Because there is no
longer the legacy HTTP mode on this version. So I need more info. Could you open
a new issue on Github please ?
--
Christopher Faulet
>From d9915f4757e717b27a4760411166b0ffbd03e137 Mon Sep 17 00:00:00 2001
From: Christopher Faulet <cfau...@haproxy.com>
Date: Wed, 5 Aug 2020 14:37:13 +0200
Subject: [PATCH] BUG/MEDIUM: mux-h2: Don't fail if nothing is parsed for a
legacy chunk response
The parsing of incomplete chunk formatting in legacy HTTP mode was fixed by the
commit 6ad7cd981 ("BUG/MEDIUM: mux-h2: Emit an error if the response chunk
formatting is incomplete"). But a bug was introduced. When nothing is parsed, an
error is also returned. It may happens if the parsing is stopped just after a
chunk CRLF. When we try to parse the following chunk size, if there is no more
data to parse, an protocol error is returned. It is obviously wrong.
The patch was directly introduced on 2.0, there is no upstream commit ID for
this patch.
This patch is related to issue #798 and reported in comment in issue #768. It
must be backported to 1.8.
---
src/mux_h2.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/src/mux_h2.c b/src/mux_h2.c
index e37159b7a..d5ef6f37b 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -3303,9 +3303,15 @@ static int h2s_frt_make_resp_data(struct h2s *h2s, struct buffer *buf)
if (h1m->state == HTTP_MSG_CHUNK_CRLF) {
ret = h1_skip_chunk_crlf(buf, -buf->o, 0);
if (ret <= 0) {
- /* FIXME: bad contents. how to proceed here when we're in H2 ? */
- h1m->err_pos = ret;
- h2s_error(h2s, H2_ERR_INTERNAL_ERROR);
+ /* FIXME: bad contents or truncated response. how to proceed here when we're in H2 ?
+ * It should not happen except if opposite connection was closed.
+ * Note: check there is at least something to parse to be sure the chunk crlf
+ * is truncated.
+ */
+ if (max) {
+ h1m->err_pos = ret;
+ h2s_error(h2s, H2_ERR_INTERNAL_ERROR);
+ }
goto end;
}
bo_del(buf, ret);
@@ -3318,9 +3324,15 @@ static int h2s_frt_make_resp_data(struct h2s *h2s, struct buffer *buf)
ret = h1_parse_chunk_size(buf, -buf->o, 0, &chunk);
if (ret <= 0) {
- /* FIXME: bad contents. how to proceed here when we're in H2 ? */
- h1m->err_pos = ret;
- h2s_error(h2s, H2_ERR_INTERNAL_ERROR);
+ /* FIXME: bad contents or truncated response. how to proceed here when we're in H2 ?
+ * It should not happen except if opposite connection was closed.
+ * Note: check there is at least something to parse to be sure the chunk crlf
+ * is truncated.
+ */
+ if (max) {
+ h1m->err_pos = ret;
+ h2s_error(h2s, H2_ERR_INTERNAL_ERROR);
+ }
goto end;
}
--
2.26.2
