HTTP/2 SETTINGS values are not fingerprinted — all profiles share hyper defaults #385

All browser profiles in impit produce the same HTTP/2 Akamai fingerprint regardless of the selected browser. The SETTINGS frame values are hyper's defaults, not real browser values.

Tested all 17 profiles against tls.peet.ws/api/all:

chrome         2:0;4:2097152;5:16384;6:16384|5177345|0|m,a,s,p   ❌
chrome100      2:0;4:2097152;5:16384;6:16384|5177345|0|m,a,s,p   ❌
chrome142      2:0;4:2097152;5:16384;6:16384|5177345|0|m,a,s,p   ❌
firefox144     2:0;4:2097152;5:16384;6:16384|5177345|0|m,p,a,s   ❌

Real Chrome:   1:65536;2:0;4:6291456;6:262144|15663105|0|m,a,s,p ✅

Every profile has the exact same SETTINGS, only pseudo-header order differs.

What's wrong

Why

Http2Fingerprint only holds pseudo_header_order. The actual SETTINGS values come from hyper defaults and are never overridden in new_reqwest_client().

Practical impact

Akamai Bot Manager uses the HTTP/2 fingerprint as a detection signal. Correct TLS (JA3/JA4) alone is not enough — Akamai returns 403 when the HTTP/2 fingerprint doesn't match a real browser. This is likely less of an issue with Cloudflare, which explains why it hasn't surfaced earlier.

For comparison: curl_cffi and wreq-js (both using BoringSSL) produce the correct HTTP/2 fingerprint and pass Akamai checks.

Fix

4 of 5 values are already configurable via reqwest:

builder
    .http2_initial_stream_window_size(6_291_456)
    .http2_initial_connection_window_size(15_728_640)
    .http2_max_header_list_size(262_144);

HEADER_TABLE_SIZE is not exposed by reqwest and would need a patch upstream.

Related: #99 (comment about HTTP/2 SETTINGS), #315 (detection issues)