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
| HTTP/2 SETTING |
impit |
Chrome 144 |
| HEADER_TABLE_SIZE (1) |
not sent (4096 default) |
65536 |
| INITIAL_WINDOW_SIZE (4) |
2097152 |
6291456 |
| MAX_FRAME_SIZE (5) |
16384 (sent) |
16384 (not sent) |
| MAX_HEADER_LIST_SIZE (6) |
16384 |
262144 |
| WINDOW_UPDATE |
5177345 |
15663105 |
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)
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:Every profile has the exact same SETTINGS, only pseudo-header order differs.
What's wrong
Why
Http2Fingerprintonly holdspseudo_header_order. The actual SETTINGS values come from hyper defaults and are never overridden innew_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_SIZEis not exposed by reqwest and would need a patch upstream.Related: #99 (comment about HTTP/2 SETTINGS), #315 (detection issues)