tree dfb7cddbd833baaadcb8bfae3e53537ed5873287
parent c56b380082d5e06819ea6d382294e17c6ea2905a
author Christopher Faulet <cfaulet@haproxy.com> 1726507053 +0200
committer Christopher Faulet <cfaulet@haproxy.com> 1726559650 +0200

BUG/MEDIUM: cache/stats: Wait to have the request before sending the response

It seems obvious. On a classical workflow, the request headers analysis is
finished when these applets are woken up for the first time. So they don't
take care to really have the request to start to process it and to send the
response. But with a filter, it is possible to stop the request analysis
after the applet creation.

If this happens for the stats applet, this leads to a crash because we
retrieve the request start-line without checking if it is available. For the
cache applet, the response is just immediatly sent. And here it is a problem
if the compression is enabled. In that case too, this may lead to a crash
because the compression may be enabled but not initialized.

For a true server, there is no issue because the connection cannot be
established. The server is chosen only after the request analysis. The issue
with applets is that once created, an applet is quickly switched to the
established state. So it is probably a point that must be carefully reviewed
and probably reworked.

In the mean time, as a fix, in the cache and the stats applet, we just take
care to have the request before sending the response. This will do the
trick.

The patch must be backported as far as 2.6. On 2.6, the patch must be adapted.

(cherry picked from commit afc50f2445e02c778095cf4d7392c505f5af5278)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit faf9feac31da865fca309485cfb27ed52b776087)
[cf: The patch was adapted because these applets don't have internal buffers]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 045f7e58083f31823899f4451ac512168e6a830f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>