On Wed, Apr 13, 2022 at 08:16:06AM -0600, Shawn Heisey wrote:
> On 4/13/22 02:42, Amaury Denoyelle wrote:
> > Ok this seems related to 'option abortonclose'. Without this, I do not
> > have a 400 error. Can you confirm me this behavior on your side please ?
>
> If I remove that, it works. I can have my webmail served via http/3 and
> login still works, which it didn't before because all POST requests were
> getting a 400.
> What am I losing or gaining by removing abortonclose? I read the docs on
> it, and wasn't able to work out whether I want it or not. Will this failure
> when configuring abortonclose be considered a bug?
Currently, this option is buggy when used with a QUIC listener. This is
indeed a bug and will be fixed in a future patch.
> The reasons for that option being in the config are lost to the antiquities
> of time. Most of my config is stolen from a setup I once built at an old
> ${DAYJOB} that was actually doing load balancing. For my personal setups, I
> mainly use haproxy for SSL offloading and making multiple private-side web
> servers available through a single public IP address.
By default, connection are kept opened in haproxy side even if the
client has closed it. This is required because it's impossible for
haproxy to detect a full close or only a sending channel close. In the
last case, haproxy can still deliver the response and then fully close
the connection. This is conform to the default http specification and is
useful when dealing with clients tools such as netcat which rely heavily
on this behavior.
If all your clients are browsers and the traffic is enough to fill the
haproxy queue, it is useful to activate abortonclose. When a user hits
the "STOP" loading page of the browser, the connection is immediatly
close on haproxy, which liberate some resources to handle other
connections.
So to summary, this option should be activated if you only have browsers
as client and the traffic is big enough to saturate haproxy queues.
I hope this will clarify your thoughts,
--
Amaury Denoyelle
