On 4/25/22 08:13, Amaury Denoyelle wrote:
I would not put too much faith in it for the near future. The OpenSSL team seems to have put aside a simple QUIC API integration in favor of a brand new full QUIC stack, which should take quite some time. So for now, manually rebuilding your SSL library seems the only way to go
Ah. Not Invented Here syndrome?
We already experienced this kind of problems but we though we have fixed them. It seems the connection closure it not always properly handle on haproxy side, which left the client with no notification that it should open a new connection. It may help to increase the timeout client to be greater than the default QUIC idle timeout, which is hardcoded to 10s on haproxy side. For haproxy.org, we use a value of 1m and it seems to be working. Please tell me if this makes your problem disappears or not.
My client timeout is set to 15 seconds in the "defaults" section, which is larger than that hardcoded default. Should I go with something higher?
We did not have enough time to work on POST so there is still bugs in this part. I just recently fixed two bugs which may be enough to fix your situattion with the latest 2.6-dev7. However, I still have issues when I use large payloads. Thanks for your kind compliment for haproxy reliability. We hope one day we will reach this level for QUIC but for now this objectif is still far.
I was testing with the master branch from https://github.com/haproxy/haproxy.git. Just pulled down the latest changes, built it, and installed it. Now I am sometimes seeing different behavior on the large POST. It will load a page quickly sometimes, returning to the same page with blank fields, just as it would when first going there. Another time, apache returned a 504 error, which is very weird. When haproxy got the 504, it sent its own error page.
If there is anything I can do to help troubleshoot, give me instructions on how to do it.
Thanks, Shawn
