Hi Willy, Agree with that. However, maybe a "common H2 troubleshooting guide" should be provided so options like h2-workaround-bogus-websocket-clients will be highlighted if any trouble arise.
-- Ionel GARDAIS Tech'Advantage CIO - IT Team manager ----- Mail original ----- De: "Willy Tarreau" <w...@1wt.eu> À: "haproxy" <haproxy@formilux.org> Envoyé: Samedi 15 Avril 2023 11:32:49 Objet: [*EXT*] Opinions desired on HTTP/2 config simplification 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 -- 232 avenue Napoleon BONAPARTE 92500 RUEIL MALMAISON Capital EUR 219 300,00 - RCS Nanterre B 408 832 301 - TVA FR 09 408 832 301
