Full kudos to Caddy for being the first out the door with working HTTP/3 support.

Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable.

> Caddy

Benefited from Lucas https://clemente.io/ ... full credit to him, and the various people who worked on the IETF test implementations that then became various production implementations.

I don't credit Caddy with this as they were downstream and just received the good work done. Not that Caddy is bad, but singling them out ignores those that did the hard work.

> Are there downsides to HTTP/3? When HTTP/2 came out there was discussions about why not to enable

1. HTTP/1 and HTTP/2 were natural rate limiters to your application... can your app cope when all requests arrive in a much shorter time window? The traffic pattern goes from somewhat smooth, to somewhat bursty and spikey. If your assets come from a dynamic endpoint or you have authorization on your endpoint that results in database lookups... you'll want to load test real world scenarios.

2. There are amplification potentials when you pass HTTP/3 through layers that map to HTTP/2 and HTTP/1 (the optimisations in the small payload to H3 are "undone" and amplify through H2 and H1 protocols)

3. HTTP/3 combined the transport protocol benefits and the HTTP protocol benefits with TLS benefits... all good, but it is harder for DDoS protection as proxies and middle boxes can no longer differentiate as easily the good traffic from the bad, and may not have visibility over what constitues good at all.

Largely though... worth enabling. And for a good while the last of my points is mitigated by disabling H3 as you'll degrade to H2 cleanly.

For sure, as a Caddy maintainer, all credit goes to the contributors of https://github.com/lucas-clemente/quic-go. Early on this was mostly Lucas Clemente, but Marten Seemann has been the primary maintainer for quite a while now, including the transition from QUIC to HTTP/3. https://github.com/lucas-clemente/quic-go/graphs/contributor...