]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MEDIUM: mux-h1: Don't loop on the headers parsing if the read0 was received
authorChristopher Faulet <cfaulet@haproxy.com>
Mon, 10 Dec 2018 14:30:06 +0000 (15:30 +0100)
committerWilly Tarreau <w@1wt.eu>
Mon, 10 Dec 2018 19:50:59 +0000 (20:50 +0100)
If a server sends part of headers and then close its connection, the mux H1
reamins blocked in an infinite loop trying to read more data to finish the
parsing of the message. The flag CS_FL_REOS is set on the conn_stream. But
because there are some data in the input buffer, CS_FL_EOS is never set.

To fix the bug, in h1_process_input, when CS_FL_REOS is set on the conn_stream,
we also set CS_FL_EOS if the input buffer is empty OR if the channel's buffer is
empty.

src/mux_h1.c

index f7026c9c56a527e38178d5371836cff4275eed8f..fa3ffa8d06c77cbaaad1be68ed6b3fd669da487d 100644 (file)
@@ -1304,11 +1304,14 @@ static size_t h1_process_input(struct h1c *h1c, struct buffer *buf, int flags)
        else {
                h1_release_buf(h1c, &h1c->ibuf);
                h1_sync_messages(h1c);
+               h1s->cs->flags &= ~(CS_FL_RCV_MORE | CS_FL_WANT_ROOM);
+       }
 
+       if ((h1s->cs->flags & CS_FL_REOS) && (!b_data(&h1c->ibuf) || htx_is_empty(htx))) {
+               h1s->cs->flags |= CS_FL_EOS;
                h1s->cs->flags &= ~(CS_FL_RCV_MORE | CS_FL_WANT_ROOM);
-               if (h1s->cs->flags & CS_FL_REOS)
-                       h1s->cs->flags |= CS_FL_EOS;
        }
+
        return total;
 
   parsing_err: