Blog

How HTTP/2 Settings Frames Identify a Client

HTTP/2 does not begin with a request. It begins with each side announcing how it wants the connection to behave, and those announcements differ between implementations in stable ways.

An HTTP/2 connection opens with negotiation

Immediately after the connection is established, the client sends a settings frame declaring limits such as the maximum number of concurrent streams and the size of the header table.

These values are chosen by whatever library is speaking the protocol. Application code above it usually has no say and often no visibility.

The server sends its own settings in return, and both sides then operate within the agreed limits for the life of the connection.

Settings values differ by implementation

There is no single correct set of values, so implementers pick defaults that suit their design. Those defaults persist across versions and are consistent across every installation.

The combination of which settings appear, in what order, and with what values is therefore characteristic of a family of clients rather than of any one user.

Because the values arrive before any request, a server can classify the client before deciding how to handle the first page it asks for.

Stream priority and window sizes add detail

Beyond settings, clients differ in how they express priority between concurrent streams and how they size flow-control windows as data arrives.

Browsers implement elaborate priority schemes because page loading benefits from fetching stylesheets before images. Simple clients typically implement none of that.

The absence of a priority scheme is as informative as any particular scheme, since a real browser loading a page has a strong reason to express one.

The signal sits below application code

Nothing here is reachable from the page. A script cannot read or alter the connection's settings, and altering them means changing the networking stack itself.

That places the signal in the same category as the TLS handshake: a property of the software stack rather than of anything the page or the user configured.

It also means the signal cannot be checked from the browser side, which is why it appears only in server-side and edge detection.

Limits of the signal

The signal identifies a client family, not a person. Everyone using the same browser version presents effectively the same connection preamble.

Its value is in consistency checking. When the connection-level behaviour and the application-level claims describe different software, the mismatch is what carries information.