Re: Is tune.quic.backend.max-idle-timeout missing from the documentation?

On 6/28/23 08:17, Nick Ramirez wrote: The HAProxy source code indicates that there is a directive named 'tune.quic.backend.max-idle-timeout': haproxy/src/cfgparse-quic.c at f473eb72066e02d44837fd77110b6ca5bdea97e2 · haproxy/haproxy (github.com)

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi, Great, thanks for this. Will "option http-no-delay" be required to activate this particular tweak or is that general advice? We'll certainly mention it in our reverse proxy documentation either way. B. > On 28 Jun 2023, at 04:44, Willy Tarreau wrote: > > Hi Robert, > > On Tue, Jun 27,

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi Tim, On Wed, Jun 28, 2023 at 04:12:57PM +0200, Tim Düsterhus wrote: > Hi > > On 6/23/23 13:14, Willy Tarreau wrote: > > But you're aware that what you're asking for is a direct violation of > > basic HTTP messaging rules stating that no agent may depend on chunk > > delivery due to anything

Is tune.quic.backend.max-idle-timeout missing from the documentation?

The HAProxy source code indicates that there is a directive named 'tune.quic.backend.max-idle-timeout': haproxy/src/cfgparse-quic.c at f473eb72066e02d44837fd77110b6ca5bdea97e2 · haproxy/haproxy (github.com)

Re: haproxy indefinitely delays the delivery of small http chunks with slz

Hi On 6/23/23 13:14, Willy Tarreau wrote: But you're aware that what you're asking for is a direct violation of basic HTTP messaging rules stating that no agent may depend on chunk delivery due to anything along the chain possibly having to buffer some of the data for analysis or