-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP/3 does not work properly. Browsers mostly do not choose h3 over h2. #4372
Comments
On safari clients the headers it expects are here 👍 |
Not sure what you mean. Did you try safari against https:/wiki.tnonline.net? |
I don't have a curl handy that supports --http3 :-) But I am almost sure that the http3checker.net issue is that they refer to h3/h3-29 as HTTP3, and <= h3-27 as QUIC. Supporting just h3/-29 seems fine. Firefox is using h3 after the first connection to Caddy. I found that if you do a Ctrl-Shift-r refresh in Firefox, it will use HTTP/2, before learning to use h3 again. Can play with that behaviour on https://http3.is |
Prefer an appropriate DNS entry: https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ The e.g the HTTPS DNS entry for Cloudflare: https://dns.google/query?name=cloudflare.com&rr_type=HTTPS |
Hi. I've now updated to FireFox now claims wiki.tnonline.net - HTTP/3 is used I am guessing this is due to some configuration error, but I can't understand what exactly. All vhosts in Caddy have almost identical configurations.
I've added the HTTPS dns entries, but it seems didn't help in this case =(. Seems a little fickle. Perhaps the HTTPS records work best for subdomains only.
You might be right here. https://gf.dev/http3-test seem a more reliable checker. |
The DNS lookup lists two entries for the main domain: https://dns.google/query?name=tnonline.net&rr_type=HTTPS&ecs= |
Indeed. I added the '.' and 'tnonline.net.' as a way to see if this would make any difference. It unfortonately did not. According to https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ there should only be a need for '.' for the main domain. |
@mholt i think we can close here. HTTP3 support works as expected. |
@Forza-tng do you agree? Are your concerns resolved? I'm not totally following this discussion, so excuse me if I'm missing context. |
@francislavoie the concerns expressed by OP are not an issue with caddy itself. There are basically two things at play here:
|
Hi. I am experiencing some odd behaviour with regard to http/3.
Caddy version: v2.4.5 h1:P1mRs6V2cMcagSPn+NWpD+OEYUYLIf6ecOa48cFGeUg=
Caddyfile:
Vhost Caddyfile:
When I use cURL I can force http3 connection:
However browsers such as FireFox, Chromium and Opera do not always choose h3 connection. I could not understand why, so I tried checking with the online service https://www.http3check.net/ which shows some weird result. It allowed me to export the qlog file (attached).
https://www.http3check.net/?host=wikidev.tnonline.net
While https://www.http3check.net/?host=http3.is gives the expected results
I've added a QLog output.
wikidev.tnonline.net.qlog-json.txt
Caddy Logfile:
vhost logfile:
The text was updated successfully, but these errors were encountered: