MEDIUM: stconn: Properly handle large buffers during a receive

While large buffers are still unused internally, functions receiving data
from endpoint (connections or applets) were updated to block the receives
when channels are using large buffer and the data forwarding was started.

The goal of this patch is to be able to flush large buffers at the end of
the analyzis stage to return asap on regular buffers.

diff --git a/src/stconn.c b/src/stconn.c
index c4a96d4fef3d55d8cb78dc74f47885984ae1b18d..770722d1320a56de065c3b38e87943bb5cfb1d72 100644 (file)
--- a/src/stconn.c
+++ b/src/stconn.c
@@ -1378,6 +1378,10 @@ int sc_conn_recv(struct stconn *sc)
        if (!sc_alloc_ibuf(sc, &(__sc_strm(sc)->buffer_wait)))
                goto end_recv;
 
+       if ((ic->flags & CF_WROTE_DATA) && b_size(sc_ib(sc)) > global.tune.bufsize) {
+               sc_need_room(sc, -1);
+               goto done_recv;
+       }
        /* For an HTX stream, if the buffer is stuck (no output data with some
         * input data) and if the HTX message is fragmented or if its free space
         * wraps, we force an HTX deframentation. It is a way to have a
@@ -2063,6 +2067,11 @@ int sc_applet_recv(struct stconn *sc)
        if (!sc_alloc_ibuf(sc, &appctx->buffer_wait))
                goto end_recv;
 
+       if ((ic->flags & CF_WROTE_DATA) && b_size(sc_ib(sc)) > global.tune.bufsize) {
+               sc_need_room(sc, -1);
+               goto done_recv;
+       }
+
        /* For an HTX stream, if the buffer is stuck (no output data with some
         * input data) and if the HTX message is fragmented or if its free space
         * wraps, we force an HTX deframentation. It is a way to have a