I agree defaulting to alpn h2,http/1.1 sooner (don't wait for 2.9), and even 2.6 would be fine IMO. Wouldn't be a new feature for 2.6, only a non breaking (AFAIK) default change...
I would have concerns making QUIC default for 443 ssl (especially prior to 2.8), but you are not suggesting that anyways. On Sat, Apr 15, 2023 at 5:33 AM Willy Tarreau <w...@1wt.eu> wrote: > > Hi everyone, > > I was discussing with Tristan a few hours ago about the widespread > deployment of H2 and H3, with Cloudflare showing that H1 only accounts > for less than 7% of their traffic and H3 getting close to 30% [1], > and the fact that on the opposite yesterday I heard someone say "we > still have not tried H2, so H3..." (!). > > Tristan said something along the lines of "if only proxies would enable > it by default by now", which resonated to me like when we decided to > switch some defaults on (keep-alive, http-reuse, threads, etc). > > And it's true that at the beginning there was not even a question about > enabling H2 by default on the edge, but nowadays it's as reliable as H1 > and used by virtually everyone, yet it still requires admins to know > about this TLS-specific extension called "ALPN" and the exact syntax of > its declaration, in order to enable H2 over TLS, while it's already on > by default for clear traffic. > > Thus you're seeing me coming with my question: does anyone have any > objection against turning "alpn h2,http/1.1" on by default for HTTP > frontends, and "alpn h3" by default for QUIC frontends, and have a new > "no-alpn" option to explicitly turn off ALPN negotiation on HTTP > frontends e.g. for debugging ? This would mean that it would no longer > be necessary to know the ALPN strings to configure these protocols. I > have not looked at the code but I think it should not be too difficult. > ALPN is always driven by the client anyway so the option states what we > do with it when it's presented, thus it will not make anything magically > fail. > > And if we change this default, do you prefer that we do it for 2.8 that > will be an LTS release and most likely to be shipped with next year's > LTS distros, or do you prefer that we skip this one and start with 2.9, > hence postpone to LTS distros of 2026 ? > > Even if I wouldn't share my feelings, some would consider that I'm > trying to influence their opinion, so I'll share them anyway :-) I > think that with the status change from "experimental-but-supported" to > "production" for QUIC in 2.8, having to manually and explicitly deal > with 3 HTTP versions in modern configs while the default (h1) only > corresponds to 7% of what clients prefer is probably an indicator that > it's the right moment to simplify these a little bit. But I'm open to > any argument in any direction. > > It would be nice to be able to decide (and implement a change if needed) > before next week's dev8, so that it leaves some time to collect feedback > before end of May, so please voice in! > > Thanks! > Willy > > [1] https://radar.cloudflare.com/adoption-and-usage >
