HTTP/2 fingerprint
An HTTP/2 fingerprint identifies a client from how it opens and drives the connection, rather than from the content of its headers.
An HTTP/2 fingerprint identifies a client from how it opens and drives the connection, rather than from the content of its headers. It is derived from frames, so it survives any amount of header editing and applies to every request on the connection.
#Where the signal lives
The first thing each endpoint sends after the connection preface is a SETTINGS frame. Which parameters a client chooses to send, what values it gives them and in what order are all implementation choices, and they are consistent for a given build.
| Signal | Why it varies between clients |
|---|---|
| SETTINGS parameters sent | A client may omit any parameter and inherit the protocol default |
| Values chosen | Flow-control and frame-size preferences differ by implementation |
| Initial WINDOW_UPDATE | Some clients immediately enlarge the connection window; others do not |
| Pseudo-header order | :method, :authority, :scheme and :path are emitted in a fixed per-client order |
| Priority information | Sent by some clients, absent in others |
#The defaults are the reference point
RFC 9113 gives initial values for the settings an endpoint does not send: the initial stream flow-control window is 65,535 octets and the maximum frame payload is 16,384 octets. A client that never mentions either inherits both, so the set of parameters it does send is itself distinguishing. The registry of parameter identifiers is maintained by IANA.
#What this means for scraping
Matching a browser’s TLS handshake and then driving the connection with a general-purpose HTTP library produces a contradiction: a browser handshake followed by a library’s frame pattern. The mismatch is a stronger signal than either half on its own, in the same way a browser user agent on a scripting client’s handshake is.
Consistency across layers is the requirement. Either the whole stack imitates the browser, or you use the browser.
#Commonly confused with
TLS fingerprinting happens before any HTTP frame exists. HTTP/2 fingerprinting happens after the handshake succeeds, so a target can accept your connection and still classify you on the frames that follow.