consider enabling QUIC by default

[marten-seemann]

Chrome has enabled QUIC for a large fraction of Chrome Stable. quic-go has been supporting draft-29 for a while now, and will add support for draft-32 in the next release (in case Chrome adds support for that version, which, as far as I know, they don't plan at this point).
quic-go has been the default transport in IPFS and Filecoin for a few months already.

We might want to find a solution for #3055 first (or disable Retry entirely), so users will actually enjoy the reduced handshake latency (1 round-trip instead of 2 in the case of TLS 1.3 over TCP).

[Y-A-K-E]

If quic is enabled by default, AJAX or pjax requests PHP sites to not work

[marten-seemann]

@Y-A-K-E Why would that be? If so, that would be a bug. Can you share some more details?

[mholt]

Overall I'm open to this. Maybe later, once HTTP/3 is finalized and has broad client support.

As a data point, here's one case study where not binding to UDP by default is preferred: https://twitter.com/itstelesphoreo/status/1333457155324846085

[francislavoie]

We'll definitely want to add a disable_http3 option, to flip it from opt-in (currently) to opt-out.

[marten-seemann]

Overall I'm open to this. Maybe later, once HTTP/3 is finalized and has broad client support.

@mholt HTTP/3 is (basically) finalized. The QUIC transport documents have completed IETF Last Call a while back. The documents are now in the RFC editor queue, so it will still take a few months until the final RFCs are published. However, nobody expects any protocol changes at this point.
Chrome has enabled IETF QUIC by default, see https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html.

As a data point, here's one case study where not binding to UDP by default is preferred: https://twitter.com/itstelesphoreo/status/1333457155324846085

This boils down to how to configure the address:port in the Caddyfile. Currently, saying domain:443 means listen on TCP port 443, and with HTTP/3 enabled to also listen on port 443 for QUIC. Do we need a way to specify an alternative UDP port?
As QUIC support is advertised via Alt-Svc, any port would be discoverable by browsers after the first visit to the site. Of course, in the future, browsers might race a TCP and QUIC connection to the respective 443 ports, so having QUIC default to 443 definitely makes sense.

We'll definitely want to add a disable_http3 option, to flip it from opt-in (currently) to opt-out.

@francislavoie +1

[mholt]

Do we need a way to specify an alternative UDP port?

That might be useful sooner or later. Does the quic-go API have that ability? If so, we can find a way to expose it in Caddy.

so having QUIC default to 443 definitely makes sense.

I agree; am just noting that there are cases where it will need to be configurable.

Thanks!

[marten-seemann]

Does the quic-go API have that ability? If so, we can find a way to expose it in Caddy.

quic-go doesn't really care about the port. You pass a net.PacketConn to quic-go, so this entirely in the caller's responsibility.

[sagudev]

QUIC is now finalised. https://datatracker.ietf.org/doc/html/rfc9000

[awfulcooking]

👀

[francislavoie]

We still need to solve #3055, #4348, and #4372 first, I think.

[mholt]

Yeah, probably no way this is going to happen until the feature is no longer experimental. But, sometime in the future, I do think it can happen.

[bt90]

Looks like there is only a single showstopper left: #3055

As the final HTTP/3 core specs are very very very close, it would be cool if caddy would be one of the first to officially support it 😉

[mholt]

@bt90 I agree. @marten-seemann can you please review #4707? It's not done yet, but I want to make sure I'm on the right track with AcceptToken().

Can people also please test that branch (http3-default). It'd be good to know how many things this will break before we release it sometime after v2.5.0.

[francislavoie]

There's also #4294 btw, i.e. strict_sni_host and client authentication not working with HTTP3. My understanding is that tls.ConnectionState doesn't get filled because 0-RTT means the handshake gets completed asynchronously.

[mholt]

Good point; we probably won't be able to enable HTTP/3 if client auth is configured.

[otbutz]

With #4819 being fixed in the latest release, these are the missing bits:

• HTTP3 + strict_sni_host always results in 403 status #4294
• disable QUIC Retries when not under load #3055
• Outdated TLS certificate on HTTP/3 requests after renewal #4849

[mholt]

@otbutz Yep! #4294 might be more of an edge case, and apparently depends on something upstream in Go that we don't have (yet?) -- it only affects connections that use strict_sni_host, which I rarely see outside of TLS Mutual Auth scenarios (which are also rare).

As for #3055, I'm nearly done with that in #4707. I am just waiting for some thoughts/feedback from @marten-seemann about how to verify tokens.

But yeah, I'd be ready to get this into a prerelease as soon as it's ready.

[bt90]

Possibly #4849

[mholt]

Finally done in #4707. HTTP/3 will be enabled by default in Caddy 2.6.