5 ms·

Can we use HTTP3 today? Is it widely supported?

unmole 3y ago
Yes. Google and Facebook have deployed HTTP/3 across their properties for quite some time now. Support in popular servers is not mature but if you're using a CDN like Cloudflare, it's trivial to enable HTTP/3 for your users.
noway421 3y ago
Wondering the same- how’s the compatibility with very restrictive networks? Say a university/corporate network that only allows port 443 and DPI’d 80 egress. QUIC won’t pass through that since it’s UDP. Can server and client reliably negotiate a fallback to http/2 in such a case?
- oefrha 3y ago
  HTTP/1.1 isn’t going anywhere in any popular server, so yeah, HTTP/2 fallback isn’t a problem. (HTTP/1.1 is basically required even if you just want to serve an https redirect on port 80, since h2 requires TLS. The clear text h2c protocol has no adoption AFAICT.)
- ignoramous 3y ago
  Yep, just like IPv4 didn't, HTTP/1 and H2 aren't going anywhere anytime soon.
  - wraptile 3y ago
    IPv4 is not going away because it's valuable (as in limited supply creates a market). HTTP 1.1 is already unusuable in modern web as you'll be instantly blocked by cloudflare and gang. HTTP2 is likely to follow in near future as replacing it will be much easier than replacing http1.1.
    - re-thc 3y ago
      Adoption was also slow because there were lots of legacy switches and routers that did not support it. Upgrades took a long time.
    - bheadmaster 3y ago
      > IPv4 is not going away because it's valuable (as in limited supply creates a market). That's what I've been telling my bros about crypto.
      - wraptile 3y ago
        I'm not sure you understand. IP scarcity means they are more valuable in the web automation context. IPv6 availability will make it harder to "price" web automation -> more bots online -> more captchas and privacy invasions. That's a real challenge that is hard to solve despite your snarky comments.
        bheadmaster 3y ago
        The IPv4 address scarcity means that bots cause a lot more collateral damage, because if your neighbor runs a bot from home, you'll most likely get banned too. Yeah, there's value in convenience of being able to block misbehaving IPv4 addresses. There's also value in burning CPU cycles to produce a transaction on a blockchain. Make of it what you will.
  - Ekaros 3y ago
    HTTP2 is probably first one to go or be replaced. You can live without it or update it to whatever next thing.
  - j16sdiz 3y ago
    nit: It is HTTP/1.1 . HTTP/1.0 have long gone
    - BenjiWiebe 3y ago
      I'm pretty sure I saw HTTP/1.0 in a PLC's status page recently.
    - Twirrim 3y ago
      Sadly, 1.0 is _still_ around. Rare, but it happens. I remember being gobsmacked several years ago that F5 LBs only supported HTTP/1.0 health checks. Doing HTTP/1.1 health checks required writing one specifically for it. Something the community had got sorted a long time ago.
- supriyo-biswas 3y ago
  Yes. Browsers typically initiate a TLS (TCP) connection to port 443 for HTTP1/2, and then upgrade to HTTP/3 based on the Alt-Svc header.
  - noway421 3y ago
    What if your browser receives Alt-Svc header and switches to http/3 on one network (say mobile data), but then you switch to a restrictive WiFi that has UDP disabled. All without restarting your browser/within one "session" of your http client. Wouldn't you start having connectivity issues that would be hard to troubleshoot? In that scenario, having http3 disabled is beneficial.
    - fridek 3y ago
      Changing network interfaces breaks connections and causes a new handshake. Browser session works at a different layer and doesn't prevent that. QUIC actually lets you migrate between connections (because the packets are identified by a connection ID in each UDP packet rather than a 5-tuple). Clients will typically re-test a connection occasionally and downgrade as needed for this to work.
  - fridek 3y ago
    This. There are also clients that with a little config will let cache the support level per-host, and even provide a list of hosts that the initial request should race TCP and QUIC to. https://developer.android.com/guide/topics/connectivity/cronet/reference/org/chromium/net/CronetEngine.Builder.html#addQuicHint(java.lang.String,%20int,%20int) https://developer.android.com/guide/topics/connectivity/cron...
paulddraper 3y ago
IIRC Chrome has whitelisted some domains, but requires a flag to enable it generally.
- fridek 3y ago
  QUIC is enabled by default for all domains across most major browsers: https://caniuse.com/http3 https://caniuse.com/http3 For Cloudflare HTTP/3 accounts for 28% of the traffic (https://radar.cloudflare.com/ https://radar.cloudflare.com/)
agildehaus 3y ago
It remains missing from Safari. It used to be offered as an experimental feature, but I don't seem to have it anymore on Safari 16.5.
- jeroenhd 3y ago
  You can enable http/3 just fine even if you also serve clients that are falling behind on web standards, as long as you also serve http/2 as a fallback. Safari not supporting isn't a problem unless your business only and specifically targets Safari, and even then it's a relatively painless way to help the few customers who run preview versions get a nicer experience.
- JimDabell 3y ago
  Safari added support for HTTP/3 in version 14, released in September 2020. That’s why it isn’t listed as an experimental feature any more. https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes https://developer.apple.com/documentation/safari-release-not... You can check with Cloudflare’s test page here: https://cloudflare-quic.com https://cloudflare-quic.com Alternatively, open up developer tools, go to the network panel, right-click on the headings and enable the protocol field. It will tell you which protocol was used for each request made by your browser. Obviously the server also needs to support HTTP/3 for a request to use HTTP/3.
  - agildehaus 3y ago
    Another user here commented that it's been enabled randomly for a subset of users. But not for me. And there's nothing on the web I've found about how to enable it. It was once on the Experimental menu, but no longer.
- shpx 3y ago
  It is supported and randomly enabled for ~50% of Safari 16 users, according to https://github.com/Fyrd/caniuse/pull/6664#issuecomment-1493451291 https://github.com/Fyrd/caniuse/pull/6664#issuecomment-14934...
petecooper 3y ago
Nginx 1.25 has HTTP/3 in its roadmap, first cut from that branch is scheduled to land tomorrow: https://trac.nginx.org/nginx/roadmap https://trac.nginx.org/nginx/roadmap
BucketsMcG 3y ago
We use it on our rinky-dink ecommerce site, and it represents 40% of requests at the moment. HTTP/1 and HTTP/2 are at 30% each. Our users skew a bit older, and definitely aren't techno-savvy (one scrolled past all the products and used the contact us page to ask for a printed product catalogue and order form...).
- esprehn 3y ago
  HTTP/1 is surprising, what browser is that coming from?
  - BucketsMcG 3y ago
    Can't tell, sorry, the cache service provider doesn't supply that info.

Yes. Google and Facebook have deployed HTTP/3 across their properties for quite some time now. Support in popular servers is not mature but if you're using a CDN like Cloudflare, it's trivial to enable HTTP/3 for your users.

noway421 3y ago

Wondering the same- how’s the compatibility with very restrictive networks? Say a university/corporate network that only allows port 443 and DPI’d 80 egress. QUIC won’t pass through that since it’s UDP. Can server and client reliably negotiate a fallback to http/2 in such a case?

oefrha 3y ago
HTTP/1.1 isn’t going anywhere in any popular server, so yeah, HTTP/2 fallback isn’t a problem. (HTTP/1.1 is basically required even if you just want to serve an https redirect on port 80, since h2 requires TLS. The clear text h2c protocol has no adoption AFAICT.)
ignoramous 3y ago
Yep, just like IPv4 didn't, HTTP/1 and H2 aren't going anywhere anytime soon.
- wraptile 3y ago
  IPv4 is not going away because it's valuable (as in limited supply creates a market). HTTP 1.1 is already unusuable in modern web as you'll be instantly blocked by cloudflare and gang. HTTP2 is likely to follow in near future as replacing it will be much easier than replacing http1.1.
  - re-thc 3y ago
    Adoption was also slow because there were lots of legacy switches and routers that did not support it. Upgrades took a long time.
  - bheadmaster 3y ago
    > IPv4 is not going away because it's valuable (as in limited supply creates a market). That's what I've been telling my bros about crypto.
    - wraptile 3y ago
      I'm not sure you understand. IP scarcity means they are more valuable in the web automation context. IPv6 availability will make it harder to "price" web automation -> more bots online -> more captchas and privacy invasions. That's a real challenge that is hard to solve despite your snarky comments.
      - bheadmaster 3y ago
        The IPv4 address scarcity means that bots cause a lot more collateral damage, because if your neighbor runs a bot from home, you'll most likely get banned too. Yeah, there's value in convenience of being able to block misbehaving IPv4 addresses. There's also value in burning CPU cycles to produce a transaction on a blockchain. Make of it what you will.
- Ekaros 3y ago
  HTTP2 is probably first one to go or be replaced. You can live without it or update it to whatever next thing.
- j16sdiz 3y ago
  nit: It is HTTP/1.1 . HTTP/1.0 have long gone
  - BenjiWiebe 3y ago
    I'm pretty sure I saw HTTP/1.0 in a PLC's status page recently.
  - Twirrim 3y ago
    Sadly, 1.0 is _still_ around. Rare, but it happens. I remember being gobsmacked several years ago that F5 LBs only supported HTTP/1.0 health checks. Doing HTTP/1.1 health checks required writing one specifically for it. Something the community had got sorted a long time ago.
supriyo-biswas 3y ago
Yes. Browsers typically initiate a TLS (TCP) connection to port 443 for HTTP1/2, and then upgrade to HTTP/3 based on the Alt-Svc header.
- noway421 3y ago
  What if your browser receives Alt-Svc header and switches to http/3 on one network (say mobile data), but then you switch to a restrictive WiFi that has UDP disabled. All without restarting your browser/within one "session" of your http client. Wouldn't you start having connectivity issues that would be hard to troubleshoot? In that scenario, having http3 disabled is beneficial.
  - fridek 3y ago
    Changing network interfaces breaks connections and causes a new handshake. Browser session works at a different layer and doesn't prevent that. QUIC actually lets you migrate between connections (because the packets are identified by a connection ID in each UDP packet rather than a 5-tuple). Clients will typically re-test a connection occasionally and downgrade as needed for this to work.
- fridek 3y ago
  This. There are also clients that with a little config will let cache the support level per-host, and even provide a list of hosts that the initial request should race TCP and QUIC to. https://developer.android.com/guide/topics/connectivity/cronet/reference/org/chromium/net/CronetEngine.Builder.html#addQuicHint(java.lang.String,%20int,%20int) https://developer.android.com/guide/topics/connectivity/cron...

paulddraper 3y ago

IIRC Chrome has whitelisted some domains, but requires a flag to enable it generally.

fridek 3y ago
QUIC is enabled by default for all domains across most major browsers: https://caniuse.com/http3 https://caniuse.com/http3 For Cloudflare HTTP/3 accounts for 28% of the traffic (https://radar.cloudflare.com/ https://radar.cloudflare.com/)

agildehaus 3y ago

It remains missing from Safari. It used to be offered as an experimental feature, but I don't seem to have it anymore on Safari 16.5.

jeroenhd 3y ago
You can enable http/3 just fine even if you also serve clients that are falling behind on web standards, as long as you also serve http/2 as a fallback. Safari not supporting isn't a problem unless your business only and specifically targets Safari, and even then it's a relatively painless way to help the few customers who run preview versions get a nicer experience.
JimDabell 3y ago
Safari added support for HTTP/3 in version 14, released in September 2020. That’s why it isn’t listed as an experimental feature any more. https://developer.apple.com/documentation/safari-release-notes/safari-14-release-notes https://developer.apple.com/documentation/safari-release-not... You can check with Cloudflare’s test page here: https://cloudflare-quic.com https://cloudflare-quic.com Alternatively, open up developer tools, go to the network panel, right-click on the headings and enable the protocol field. It will tell you which protocol was used for each request made by your browser. Obviously the server also needs to support HTTP/3 for a request to use HTTP/3.
- agildehaus 3y ago
  Another user here commented that it's been enabled randomly for a subset of users. But not for me. And there's nothing on the web I've found about how to enable it. It was once on the Experimental menu, but no longer.
shpx 3y ago
It is supported and randomly enabled for ~50% of Safari 16 users, according to https://github.com/Fyrd/caniuse/pull/6664#issuecomment-1493451291 https://github.com/Fyrd/caniuse/pull/6664#issuecomment-14934...

petecooper 3y ago

Nginx 1.25 has HTTP/3 in its roadmap, first cut from that branch is scheduled to land tomorrow: https://trac.nginx.org/nginx/roadmap https://trac.nginx.org/nginx/roadmap

BucketsMcG 3y ago

We use it on our rinky-dink ecommerce site, and it represents 40% of requests at the moment. HTTP/1 and HTTP/2 are at 30% each. Our users skew a bit older, and definitely aren't techno-savvy (one scrolled past all the products and used the contact us page to ask for a printed product catalogue and order form...).

esprehn 3y ago
HTTP/1 is surprising, what browser is that coming from?
- BucketsMcG 3y ago
  Can't tell, sorry, the cache service provider doesn't supply that info.