]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MINOR: http-ana: Update analyzers on both sides when switching in TUNNEL mode
authorChristopher Faulet <cfaulet@haproxy.com>
Tue, 18 Apr 2023 09:01:51 +0000 (11:01 +0200)
committerChristopher Faulet <cfaulet@haproxy.com>
Tue, 18 Apr 2023 16:57:04 +0000 (18:57 +0200)
The commit 9704797fa ("BUG/MEDIUM: http-ana: Properly switch the request in
tunnel mode on upgrade") fixes the switch in TUNNEL mode, but only
partially. Because both channels are switch in TUNNEL mode in same time on
one side, the channel's analyzers on the opposite side are not updated
accordingly. This prevents the tunnel timeout to be applied.

So instead of updating both sides in same time, we only force the analysis
on the other side by setting CF_WAKE_ONCE flag when a channel is switched in
TUNNEL mode. In addition, we must take care to forward all data if there is
no DATAa TCP filters registered.

This patch is related to the issue #2125. It is 2.8-specific. No backport
needed.

src/http_ana.c

index 8c92fa75f346ded25952603dee553b7a2742aaf6..c16cfc3ee2d13a683ea9af69733c0176859aa06f 100644 (file)
@@ -4256,8 +4256,8 @@ static void http_end_request(struct stream *s)
                         */
                        channel_auto_read(&s->req);
                        txn->req.msg_state = HTTP_MSG_TUNNEL;
-                       channel_auto_read(&s->res);
-                       txn->rsp.msg_state = HTTP_MSG_TUNNEL;
+                       if (txn->rsp.msg_state != HTTP_MSG_TUNNEL)
+                               s->res.flags |= CF_WAKE_ONCE;
                }
                else {
                        /* we're not expecting any new data to come for this
@@ -4318,6 +4318,8 @@ static void http_end_request(struct stream *s)
                s->scb->flags |= SC_FL_SND_NEVERWAIT;
                if (HAS_REQ_DATA_FILTERS(s))
                        chn->analysers |= AN_REQ_FLT_XFER_DATA;
+               else
+                       c_adv(chn, htxbuf(&chn->buf)->data - co_data(chn));
        }
        channel_auto_close(chn);
        channel_auto_read(chn);
@@ -4364,10 +4366,10 @@ static void http_end_response(struct stream *s)
                 * direction, and sometimes for a close to be effective.
                 */
                if (txn->flags & TX_CON_WANT_TUN) {
-                       channel_auto_read(&s->req);
-                       txn->req.msg_state = HTTP_MSG_TUNNEL;
                        channel_auto_read(&s->res);
                        txn->rsp.msg_state = HTTP_MSG_TUNNEL;
+                       if (txn->req.msg_state != HTTP_MSG_TUNNEL)
+                               s->req.flags |= CF_WAKE_ONCE;
                }
                else {
                        /* we're not expecting any new data to come for this
@@ -4416,6 +4418,8 @@ static void http_end_response(struct stream *s)
                s->scf->flags |= SC_FL_SND_NEVERWAIT;
                if (HAS_RSP_DATA_FILTERS(s))
                        chn->analysers |= AN_RES_FLT_XFER_DATA;
+               else
+                       c_adv(chn, htxbuf(&chn->buf)->data - co_data(chn));
        }
        channel_auto_close(chn);
        channel_auto_read(chn);