Hi Shawn,
responding to all your messages at once.
On Sun, Apr 10, 2022 at 04:16:55PM -0600, Shawn Heisey wrote:
> On 4/9/2022 3:30 AM, Willy Tarreau wrote:
> > I'd encourage you to place QUIC in a separate haproxy process.
>
> I have this working.
>
> On another system where things are less important, I want to try and run it
> all in one haproxy process. Is that doable?
Yes of course! I suggested to use a separate process to ease your
manipulations and experiments, but the normal way to do that in the
long run will obviously be to have all in one process.
On Sun, Apr 10, 2022 at 04:48:43PM -0600, Shawn Heisey wrote:
> On 4/10/2022 4:35 PM, Shawn Heisey wrote:
> > I *DID* have it working. It seems to have stopped working and I do not
> > know what I did to break it. :) The http/3 checker page still says
> > everything's OK.
>
> Ah, I figured it out! It seems that ssl_fc is not set to true for encrypted
> quic connections. With this line in the config, it just continually
> redirects:
>
> redirect scheme https unless { ssl_fc }
>
> I think that's probably a bug. A workaround could maybe be found, if there
> is another condition I can use for the redirect that will redirect tcp/80
> connections but not tcp/443 or udp/443.
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.
Among the workarounds you could use, one consists in setting a name to your
"quic" bind line using the "name" directive. You can then match it using
the "so_name" fetch method.
> I am not seeing this in the system with two haproxy processes ... I had
> removed that line from the config I used for 2.6, since it was always https.
Not sure which one is what at this step :-/
On Sun, Apr 10, 2022 at 05:25:57PM -0600, Shawn Heisey wrote:
> All the fiddling has revealed that Chrome is a lot better at HTTP/3 than
> Firefox. Firefox seems to completely ignore the alt-svc header most of the
> time. Then suddenly it will work, with no idea why the behavior changed.
For me it was the opposite. Firefox always accepts it, and Chrome only
accepts it if it references port 443.
> A lot of the requests (even from Chrome) are still reaching the server as
> HTTP/2 though, and never handled by the haproxy 2.6 instance. I can't tell
> if the problem is the browser or something in my haproxy config.
Might just be related to the "ma=" value in alt-svc. After the header
value expires, the browser will use H1/H2 again for the next request,
and most likely retrieve extra components from this connection once it's
ready. What I'm observing is that a first load shows me a blue lightning
(H2) and an immediate reload a green one (H3). If I wait a bit too long
it's back to blue until the next reload.
On Sun, Apr 10, 2022 at 06:05:50PM -0600, Shawn Heisey wrote:
> On 4/10/2022 5:54 PM, Shawn Heisey wrote:
> > That would be a much simpler setup than duplicating the entire front end
> > so one handles TCP and the other UDP. I will do that. And if a future
> > version enables ssl_fc for quic with TLS, I can drop that frontend.
>
> This is what I have done for that frontend. So nice and clean. This is a
> setup I could live with long-term, if it's determined that ssl_fc shouldn't
> be enabled for quic.
It should eventually work though it's possibly broken for now, we've noted
in the todo list to check how the SSL fetch methods work. I'm expecting some
surprises, but we'll see :-)
Willy
