mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2026-02-05 09:21:42 +01:00
da4d9fe5a4
If a read shutdown is encountered on the first packet of a connection right after the data and the last analyser is unplugged at the same time, then that last data chunk may never be forwarded. In practice, right now it cannot happen on requests due to the way they're scheduled, nor can it happen on responses due to the way their analysers work. But this behaviour has been observed with new response analysers being developped. The reason is that when the read shutdown is encountered and an analyser is present, data cannot be forwarded but the BF_SHUTW_NOW flag is set. After that, the analyser gets called and unplugs itself, hoping that process_session() will automatically forward the data. This does not happen due to BF_SHUTW_NOW. Simply removing the test on this flag is not enough because then aborted requests still get forwarded, due to the forwarding code undoing the abort. The solution here consists in checking BF_SHUTR_NOW instead of BF_SHUTW_NOW. BF_SHUTR_NOW is only set on aborts and remains set until ->shutr() is called. This is enough to catch recent aborts but not prevent forwarding in other cases. Maybe a new special buffer flag "BF_ABORT" might be desirable in the future. This patch does not need to be backported because older versions don't have the analyser which make the problem appear.