]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MEDIUM: mux-h1: Disable splicing for chunked messages
authorChristopher Faulet <cfaulet@haproxy.com>
Tue, 5 Nov 2019 15:24:27 +0000 (16:24 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Wed, 6 Nov 2019 09:14:27 +0000 (10:14 +0100)
The mux H1 announces the support of the TCP splicing. It only works for payload
data. It works for messages with an explicit content-length or for tunnelled
data. For chunked messages, the mux H1 should normally not try to xfer more than
the current chunk through the pipe. Unfortunately, this works on the read side
but the send is completely bogus. During the output formatting, the announced
size of chunks does not handle the size that will be spliced. Because there is
no formatting when spliced data are sent, the produced message is malformed and
rejected by the peer.

For now, because it is quick and simple, the TCP splicing is disabled for
chunked messages. I will try to enable it again in a proper way. I don't know
for now if it will be backportable in previous versions. This will depend on the
amount of changes required to handle it.

This patch fixes a part of the issue #356. It must be backported to 2.0 and 1.9.

src/mux_h1.c

index 66ffdb70bcfc19f71df3580fd27c9cfc454bb58e..c47db476db0169893620135e1098b83f72ca8c14 100644 (file)
@@ -2661,7 +2661,7 @@ static int h1_rcv_pipe(struct conn_stream *cs, struct pipe *pipe, unsigned int c
 
        TRACE_ENTER(H1_EV_STRM_RECV, cs->conn, h1s,, (size_t[]){count});
 
-       if (h1m->state != H1_MSG_DATA && h1m->state != H1_MSG_TUNNEL) {
+       if ((h1m->flags & H1_MF_CHNK) || (h1m->state != H1_MSG_DATA && h1m->state != H1_MSG_TUNNEL)) {
                h1s->flags &= ~(H1S_F_BUF_FLUSH|H1S_F_SPLICED_DATA);
                TRACE_STATE("disable splicing on !(msg_data|msg_tunnel)", H1_EV_STRM_RECV, cs->conn, h1s);
                if (!(h1s->h1c->wait_event.events & SUB_RETRY_RECV)) {