From: Willy Tarreau <w@1wt.eu>
Date: Wed, 29 Nov 2017 14:41:32 +0000 (+0100)
Subject: BUG/MEDIUM: h2: don't report an error after parsing a 100-continue response
X-Git-Tag: v1.9-dev1~639
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=872855998bd03d5224e0e5cd6aef9b91e2a6de1d;p=thirdparty%2Fhaproxy.git

BUG/MEDIUM: h2: don't report an error after parsing a 100-continue response

Yves Lafon reported a breakage with 100-continue. In fact the problem
is caused when an 1xx is the last response in the buffer (which commonly
is the case). We loop back immediately into the parser with what remains
of the input buffer (ie: nothing), while it is not expected to be called
with an empty response, so it fails.

Let's simply get back to the caller to decide whether or not more data
are expected to be sent.

This fix needs to be backported to 1.8.
---

diff --git a/src/mux_h2.c b/src/mux_h2.c
index 6857c8d720..4567b8ff04 100644
--- a/src/mux_h2.c
+++ b/src/mux_h2.c
@@ -2800,10 +2800,11 @@ static int h2s_frt_make_resp_headers(struct h2s *h2s, struct buffer *buf)
 			h2s->st = H2_SS_CLOSED;
 	}
 	else if (h1m->status >= 100 && h1m->status < 200) {
+		/* we'll let the caller check if it has more headers to send */
 		h1m->state = HTTP_MSG_RPBEFORE;
 		h1m->status = 0;
 		h1m->flags = 0;
-		goto next_header_block;
+		goto end;
 	}
 	else
 		h1m->state = (h1m->flags & H1_MF_CLEN) ? HTTP_MSG_BODY : HTTP_MSG_CHUNK_SIZE;