BUG/MINOR: mux-h1: don't keep fast-forwarding disabled for the next streams

H1C_F_CANT_FASTFWD is set on the H1 connection when the opposite endpoint of
the current stream does not support fast-forwarding (or when it failed). It
prevents the mux from announcing it may fast-forward data.  But it is never
cleared, so once a stream faced such an endpoint (e.g. a response produced
by an applet or with filters), zero-copy forwarding remains disabled for all
the next streams of a kept-alive frontend connection, and for all the
streams of all the clients reusing an idle backend connection. It only
affects performance.

This flag depends on the stream's opposite endpoint, so it is now cleared
when the H1 stream is destroyed, like H1C_F_WANT_FASTFWD.

This was introduced by commit 2d80eb5b7 ("MEDIUM: mux-h1: Add
fast-forwarding support") in 2.9. It may be backported as far as 3.0.

diff --git a/src/mux_h1.c b/src/mux_h1.c
index 906126c52da66eba1b40ba42e24513e0f3bcae15..27b96e427106dab97a8bd2c99bbc55085450598b 100644 (file)
--- a/src/mux_h1.c
+++ b/src/mux_h1.c
@@ -1094,7 +1094,7 @@ static void h1s_destroy(struct h1s *h1s)
 
                h1_release_buf(h1c, &h1s->rxbuf);
 
-               h1c->flags &= ~(H1C_F_WANT_FASTFWD|
+               h1c->flags &= ~(H1C_F_WANT_FASTFWD|H1C_F_CANT_FASTFWD|
                                H1C_F_OUT_FULL|H1C_F_OUT_ALLOC|H1C_F_OUT_MAYALLOC|
                                H1C_F_IN_SALLOC|H1C_F_IN_SMAYALLOC|
                                H1C_F_CO_MSG_MORE|H1C_F_CO_STREAMER);