On 4/10/2022 11:32 PM, Willy Tarreau wrote:
Interesting, and not much surprising, given that SSL is handled a bit differently. I suspect we'll see other funny stuff. By the way, if you're receiving this in the second process from the first one and the first one is using HTTP to connect to the second, that would also explain it (in this case the communication between the two could be made over TLS and this rule would not match.
There should be no proxying between the two processes. I have 2.4.15 running the same config it already had, except for a few config lines that add the alt-svc header to some specific subdomains. Then I have 2.6-dev5, listening only on udp/443. I chose port 443 because of your note on haproxy.org saying that Chrome doesn't like an alternate port. If I should have proxying between the two processes instead, I will need some details about how to set that up. I deduced that there should be no connection between the two because if there is, killing the QUIC-enabled process would break things.
On another system, specifically the one I have in AWS, I upgraded to 2.6-dev5 and only have one process running. It always sets the alt-svc header. That was where I discovered ssl_fc isn't set for quic connections. I had implemented a workaround where I had a duplicate frontend only listening on udp/443. Then a kind soul pointed out that I could instead have the second frontend listen on port 80 and have a config that always redirects; that is a much more elegant solution.
I checked what Google uses in their alt-svc header for the ma value. It's 30 days. I adjusted mine to 7200 (2 hours). After I gain more confidence in my http/3 setup, I will increase it.
Thanks, Shawn
