Hacker News Reader

Comment by jeffbee | Hacker News Reader

But users don't type or even see the URI scheme any more. It is also an implementation detail.

I just think it's weird that we've left ourselves without any way to send a client directly to an HTTP/3 site. Instead they _must_ establish a TCP connection to the site and be redirected via Alt-Svc headers to HTTP/3.

View on HN

I am not going to claim myself if this is "right" or "wrong" but there is some work on that being done via https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... - see https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...

Previously, though only 2 comments across 4 posts:

https://hn.algolia.com/?q=https%3A%2F%2Fblog.cloudflare.com%...

What's the backwards compatibility story for that? Links just don't work for older browsers? Why spend all the time making H3 work seamlessly with H2 if we're only going to introduce a new scheme that only works in new HTTP clients?

Elsewhere in the thread, it sounds like there's a DNS way to suggest http/3. If adoption is high, clients might end up doing something like happy eyeballs; send tcp syns as well as the udp equivalents, and use whichever comes back first or use them all but prefer the fastest one, etc.

According to Apple (I don't own an iPhone) if you have iOS 14 and go into the Experimental Features settings and turn on support for draft HTTP/3 then it will try to do SVCB (that's the "DNS way to suggest http/3") and if it concludes that HTTP/3 is possible and there's no contraindication it will race an HTTP/3 connection vs HTTP/2

If it notices that HTTP/3 always loses or fails, it will gradually stop trying on the rationale that your network is broken so it's a waste of time.

If your site uses Cloudflare, this Just Works™ since Cloudflare will answer HTTP/3 and emit DNS records saying it speaks HTTP/3 so there's no new work for you. Otherwise, to enable it you'd need to either create SVCB records in your DNS (your DNS server may need to be updated) or use the Alt-Svc: feature and give up on the performance improvement for first visits.

Home > Settings > Safari > Experimental Features, for Safari on iOS 14.

Home > Settings > Developer, for anywhere in iOS 14 that uses the system HTTP library.

Note that you'll need a device with development mode enabled for the latter.

https://developer.apple.com/wwdc20/10111 has more details near the end.

That's not true unless the server is set up to handle redirecting. Every time I go to unifi.home.arpa:8443 I get the message:

    Bad Request
    This combination of host and port requires TLS.

I have to explicitly type the https:// for it to work.

To restate my comment in more precise terms, users do not care which protocol of { HTTP/0, HTTP/1, HTTP/2, HTTP/3 } their browser selects and uses when communicating with the remote server at whatever URL they entered. They expect the URL to work, and they don't care how.

The Unifi issue you cite is due to a series of problems that are related to the http:// to https:// migration, most of which Unifi could have easily discovered and mitigated had they cared to. I'm really disappointed in Unifi here, but the browser is at fault, too.

First: Your browser's fallback process for handling "the user entered an invalid URI" is attempting http:// first, rather than https:// first.

Second: The Unifi is responding over http:// with a completely useless error page, rather than a redirect to https:// at the same port.

Third: The Unifi probably isn't setting a Strict-Transport-Security header on responses to https://:8443, which means that your browser can't learn a better default.

Fourth: If the Unifi's instructions tell you to enter "unifi.home.arpa:8443" rather than "https://unifi.home.arpa:8443", their instructions are clearly wrong. (If you're not following their instructions precisely as written, that would explain your discover of the prior three; I can't say I blame you — I would have left it off too.)

Reply on news.ycombinator.com