Hacker News Reader

Comment by noway421 | Hacker News Reader

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?

View on HN

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.

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.

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.

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/cron...

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.)

Yep, just like IPv4 didn't, HTTP/1 and H2 aren't going anywhere anytime soon.

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.

Adoption was also slow because there were lots of legacy switches and routers that did not support it. Upgrades took a long time.

> 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.

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.

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.

HTTP2 is probably first one to go or be replaced. You can live without it or update it to whatever next thing.

nit: It is HTTP/1.1 . HTTP/1.0 have long gone

I'm pretty sure I saw HTTP/1.0 in a PLC's status page recently.

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.

Reply on news.ycombinator.com