On Thu, Dec 15, 2022 at 08:40:59PM -0700, Shawn Heisey wrote: > On 12/15/22 09:47, Shawn Heisey wrote: > > The version of curl with http3 support is not available in any of the > > distro repos for my Ubuntu machines, so I found a docker image with it. > > That works in cases where a browser won't switch, but that's because it > > never tries TCP, it goes straight to UDP. The problem doesn't break H3, > > it just breaks a browser's ability to transition from TCP to UDP. > > With the provided patch, the h3 is working well on the machine with this > URL: > > https://http3test.elyograg.org/ > > But it doesn't work correctly on the machine with this URL: > > https://admin.elyograg.org/
Both work for me using firefox (green flash after reload). (...) > TLDR: I also have another oddity. The basement server is part of a > pacemaker cluster which starts a virtual IP and haproxy on one of the > servers, with the server in question having the highest resource placement > setting. Two of the servers in the cluster are bare metal, the third is a > VM running on a third machine, providing a tiebreaker vote so the cluster > works properly without STONITH. Settings prevent the resources from > starting on the VM, and cause haproxy to always be co-located with the > virtual IP. I had to go with a VM because the third machine is running > Ubuntu 22.10 and I couldn't form the cluster with different versions of > pacemaker/corosync/pcsd on that machine compared to the other two. OK that's indeed a significant difference. > If I bind quic4@0.0.0.0:443 then UDP/443 requests to that virtual IP do not > work. But if I bind quic4@192.168.217.170:443 which is that virtual IP, > then UDP/443 requests do work. Expected (even though annoying). It's likely that responses are sent from the native IP address instead of the virtual one. That's actually due to QUIC relying on UDP, and UDP not being well supported by the good old BSD socket API (you can't specify the address to send from). We have a work around for this in 2.8-dev, which comes with other benefits but for now it's better to limit it to setups with less than a few thousands QUIC connections (yours very likely qualifies based on your explanation). I remembered we noted this limitation somehwere but can't find it anymore. Maybe it was just in the announce message. At least we need to make it more prominent (e.g. in the "bind" keyword documentation). You indeed need to bind to both the native and the virtual IP addresses (you can have the two on the same "bind" line, delimited by comma). Hoping this helps, Willy
