How does a browser know if a site supports HTTP/3?

Question

I have a kind of the same question as How does a browser know if a site supports HTTP/2?. I am wondering how the browser knows website support http3.

I am using safari and turned on the http3 support. Then I go to https://cloudflare-quic.com and the protocol is h3-29. I think my safari explores this website using h3 protocol. How does it know it?

Answer 1

The spec defines 'Discovering an HTTP/3 Endpoint':

An HTTP origin can advertise the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame (ALTSVC), using the "h3" ALPN token.

In this case, Alt-Svc is present:

$ curl -i https://cloudflare-quic.com
HTTP/2 200 
...
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400

So a browser receiving this response can attempt its next connection using those three draft versions on the same server, on UDP port 443.

Answer 2

2023 Answer:

Most browsers now support the use of a new DNS record type, HTTPS, to connect with HTTP/3 directly, without an initial connection on an older protocol. This is an improvement over the Alt-Svc header method because it (from the spec):

enables many of the benefits of Alt-Svc without waiting for a full HTTP connection initiation (multiple roundtrips) before learning of the preferred alternative, and without necessarily revealing the user's intended destination to all entities along the network path.

A website can advertise it supports HTTP/3 by use of a DNS zone file entry as follows:

example.com. 3600 IN HTTPS 1 . alpn="h3"

More info:

• IETF Draft spec: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https

• Article on CloudFlare blog: https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

Note that, despite mainstream browser support, the HTTPS record is still in draft, and many hosts won't let you put an HTTPS record type in the zone file. You'll probably need to use one of the bigger DNS providers, such as Google Cloud DNS, AWS, Cloudflare etc., or your own DNS server.

---

If you want to verify your HTTPS record, dig won't do it (at least in the version I have). Instead, you can use the drill tool that comes with ldns.

For example, google.com has this HTTPS record:

(0) > drill google.com HTTPS       
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25201
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; google.com.  IN      HTTPS

;; ANSWER SECTION:
google.com.     544     IN      HTTPS   1 . alpn=h2,h3

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 18 msec
;; SERVER: 8.8.8.8
;; WHEN: Thu Nov  2 11:33:02 2023
;; MSG SIZE  rcvd: 53

Answer 3

It either learns about the capability of the site via a HTTPS record in DNS or else it learns about it via a http/1.1 or http/2 connection (on TCP).

I suppose it could also just give it a go and see if it connects.

Browsers also apparently retain some memory of sites they visited previously.

Long term I would hope that http/3 becomes the default and browsers have to treat older versions as the exception to be detected but that situation is probably eons away.