Resources

How do Browser and Website Negotiate Which HTTP Version is Used?

HTTP version selection is not a single handshake. It is a layered discovery and fallback process, and the result differs between a first visit and a repeat visit.

A browser connecting to a website must make two decisions that are more independent than they appear: first, whether to use TCP or UDP as the transport; and second, which HTTP version to run on top of that transport. The two decisions interact in a way that requires three separate mechanisms to resolve fully.

1. The Three Discovery and Negotiation Mechanisms

The full protocol selection process involves three mechanisms, each solving a different part of the problem.

The reason all three are needed comes down to a fundamental constraint: TCP and UDP are mutually exclusive transports for a given connection.

HTTP/1.1 and HTTP/2 run over TCP. HTTP/3 runs over QUIC, which uses UDP. Once a browser opens a TCP connection to a server, it cannot negotiate its way onto QUIC on that same connection. ALPN can only select among protocols that run on the transport already chosen. A client that starts with TCP can negotiate H1 or H2 via ALPN, but it has no way to reach H3 from there.

This is the gap that Alt-Svc and DNS HTTPS records fill. Both are mechanisms for a client to learn, independently of the current TCP connection, that the server also speaks H3 on a UDP port.

2. TLS/TCP ALPN: Choosing H1 or H2 on a TCP/TLS Connection

ALPN (Application-Layer Protocol Negotiation, RFC 7301) is a TLS extension that lets the client and server agree on which application protocol to run, during the TLS handshake itself, before any HTTP traffic is exchanged.

The client includes a list of protocol identifiers in its TLS ClientHello:

ALPN: h2, http/1.1

The server selects one token from the list and confirms it as part of the TLS handshake. The connection then uses that protocol. If no ALPN extension is used, HTTPS clients traditionally assume HTTP/1.1. If ALPN is used but no common protocol can be selected, the handshake may fail rather than silently falling back.

H3 also uses ALPN — its token is h3. But H3's TLS handshake runs inside QUIC, not over TCP. The ALPN token h3 is therefore negotiated within a QUIC connection, after the transport-level decision to use UDP has already been made. A server cannot offer h3 in a TCP TLS handshake because there is nothing on that TCP connection that can carry QUIC frames. The transport selection must come first.

In practice, a browser opening a fresh TCP connection to a server will negotiate H2 if the server offers it, and fall back to H1 otherwise. H3 is not reachable from this TCP/TLS path; it must be discovered before opening the connection, or learned from a previous HTTP response.

3. Alt-Svc: Discovering HTTP/3 After an HTTP Response

The Alt-Svc response header (RFC 7838, extended for H3) allows a server to advertise that an alternative service is available at a given protocol and port. A typical H3 advertisement looks like this:

alt-svc: h3=":443"; ma=86400

The ma value (max-age) tells the browser how long to cache this advertisement, in seconds. After receiving and caching this header, the browser may attempt a QUIC connection to that host on subsequent visits, often before opening a new TCP connection.

This is the mechanism behind the behavior commonly observed in Chrome and Firefox: HTTP/2 on the first visit, HTTP/3 on the second. The browser has no prior knowledge that H3 is available, so it opens a TCP connection and negotiates H2. The server's response includes Alt-Svc, the browser caches it, and the next connection uses QUIC.

The consequences for SSE gateways are direct. A gateway that strips Alt-Svc from responses will prevent the browser from ever learning about H3. Both sides of the gateway may then stay on H2 or H1 indefinitely, even if the origin server fully supports H3.

4. DNS HTTPS Records: Discovering HTTP/3 Before Connecting

DNS HTTPS resource records (RFC 9460) are a newer mechanism that moves protocol discovery earlier in the process — before the first TCP or UDP packet is sent to the server.

When a browser resolves a hostname, it can query not just for A and AAAA address records but also for an HTTPS record. This record carries a list of supported ALPN tokens and, optionally, explicit port numbers and priority values. A typical HTTPS record for a site supporting H3, H2, and H1 looks like this in DNS zone file presentation format:

sse-testcenter.org.  IN  HTTPS  1  .  alpn="h3,h2,http/1.1"

If the browser receives this record before making a connection, it knows immediately that QUIC/H3 is available. It can attempt a QUIC connection on the first visit, without needing a prior TCP exchange to learn about Alt-Svc.

This explains the behavior observed in SSE TestCenter testing: Safari tends to use HTTPS records aggressively enough to reach H3 on the first visit, while Chrome and Firefox often show the more familiar Alt-Svc pattern — H2 first, H3 after reload. Safari has implemented DNS HTTPS record support and uses it for early protocol selection. Chrome supports the records too but has historically relied more heavily on the Alt-Svc path.

The HTTPS record also carries a priority field. Multiple records with different priorities let the server express a preference order — lower numbers are preferred. This is what the SSE TestCenter hostname matrix uses to indicate which protocol a host prefers.

When a gateway intercepts DNS queries and omits HTTPS records from responses, browsers lose early H3 discovery. Safari falls back to HTTP/2 or HTTP/1.1; even on the first connection there is no QUIC attempt.

5. The Actual Decision Flow: First Visit, Fallback, Repeat Visit

Putting the three mechanisms together, here is how a browser decides which protocol to use.

First visit, no prior DNS or Alt-Svc cache:

1. DNS resolver returns A/AAAA records and, if supported, an HTTPS record.
2. HTTPS record present with h3 in the ALPN list → browser attempts QUIC on the advertised port. If QUIC succeeds, H3 is used. If QUIC fails (e.g. UDP blocked), browser falls back to TCP.
3. No HTTPS record, or HTTPS record has no h3 → browser opens a TCP connection. ALPN negotiation selects H2 or H1. Response may contain Alt-Svc.

This results in the following decision matrix:

Repeat visit with Alt-Svc cached:

1. Browser has a cached Alt-Svc entry for this host pointing to H3.
2. Browser attempts QUIC directly. If it succeeds, H3 is used. If QUIC fails, browser falls back to TCP and negotiates H2 or H1.
3. A failed QUIC attempt may cause the browser to de-prioritize or temporarily ignore the cached Alt-Svc entry, so subsequent visits retry TCP until a successful H3 connection re-establishes the cache.

Browser differences in practice:

Note that this table describes direct connections. A gateway in the path can change any of these outcomes independently.

6. Why This Matters for SSE Gateways

A Security Service Edge gateway can affect all three mechanisms independently, and each intervention has distinct, observable consequences.

DNS interception — suppressing or modifying HTTPS records

Many SSE products act as the DNS resolver for managed clients. A gateway that does not forward or synthesize HTTPS records effectively removes early H3 discovery. Browsers that rely on DNS HTTPS records (notably Safari) will not attempt QUIC on the first visit; they fall back to TCP and negotiate H2. The gateway may never see a QUIC connection from the browser at all.

Alt-Svc stripping

A gateway that terminates the browser's TLS connection and re-originates a new upstream connection will receive the server's Alt-Svc header on the upstream side. Whether that header is forwarded to the browser is a product decision. Stripping it prevents Chrome and Firefox from learning about H3, keeping the browser on H2 regardless of what the origin supports.

ALPN on the browser side vs. the server side

A terminating gateway presents its own TLS handshake to the browser and a separate one to the origin. It can offer a different ALPN set on each side. A gateway that only offers http/1.1 to the browser will keep the browser on H1 even if it connects H2 or H3 upstream itself. Conversely, a gateway may offer H2 to the browser while using H1 upstream — the browser sees a modern protocol, but the upstream connection has no multiplexing.

QUIC blocking

Corporate firewalls and some SSE products block outbound UDP traffic, or specifically block UDP port 443. This prevents all QUIC connections regardless of what DNS records or Alt-Svc headers say. Browsers detect the failure and fall back to TCP. The gateway may intentionally cause this to keep all traffic on inspectable TCP paths.

All of these effects are visible through the SSE TestCenter Hostname Matrix. The protocol widget on each page shows what actually reached the server, the peer IP identifies the connection source, and the strict per-hostname ALPN enforcement makes the gateway's upstream behavior observable directly.

For a deeper treatment of both mechanisms — complete Alt-Svc syntax, all HTTPS record service parameters, a side-by-side comparison table, and dig commands for inspecting records directly — see DNS HTTPS Records and Alt-Svc.