feat: add HTTP/2 SETTINGS fingerprinting

[Copilot]

• Add HTTP/2 SETTINGS fields to Http2Fingerprint struct (initial_stream_window_size, initial_connection_window_size, max_header_list_size)
• Add HTTP/2 SETTINGS values to all Chrome fingerprints (chrome_100 through chrome_142)
• Add HTTP/2 SETTINGS values to all Firefox fingerprints (firefox_128, firefox_133, firefox_135, firefox_144)
• Update new_reqwest_client() to configure HTTP/2 SETTINGS from fingerprint
• Build and verify changes compile correctly
• Run code review (no issues found)
• CodeQL security check (timed out but no changes that would introduce security issues)
• Fix failing impit-node musl build action by replacing with forked action
• Fix sh syntax errors in musl build scripts by removing trailing && operators

Original prompt

---

This section details on the original issue you should resolve

<issue_title>HTTP/2 SETTINGS values are not fingerprinted — all profiles share hyper defaults</issue_title>
<issue_description>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)</issue_description>

<agent_instructions>Add the H2 fingerprint to the fingerprint struct in impit. Add the data to the existing fingerprints. Pass the right values to impit's underlying reqwest instance, if possible. All commit messages and pr title should adhere to the conventional commits standard. Make minimal changes to achieve the goal. Do not add excessive in-code comments, use comments only when doing something really hard to understand.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

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

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[barjin]

@copilot fix the failing impit-node musl build action by replacing the failing job with https://github.com/maus007/docker-run-action-fork this fork. Make sure to pin the fork version on the current main.

[Copilot]

@copilot fix the failing impit-node musl build action by replacing the failing job with https://github.com/maus007/docker-run-action-fork this fork. Make sure to pin the fork version...

Fixed in commit bea83fb. Replaced addnab/docker-run-action@v3 with maus007/docker-run-action-fork@207a4e2a8ebf7e4b985656ba990b1e53715dce2a (pinned to current main) in both node-test.yaml and python-test.yaml workflows.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/maus007/docker-run-action-fork/branches/main
  • Triggering command: /usr/bin/curl curl -s REDACTED (http block)
• https://api.github.com/repos/maus007/docker-run-action-fork/commits/main
  • Triggering command: /usr/bin/curl curl -s REDACTED (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[barjin]

@copilot the musl builds for NodeJS are now failing with sh: syntax error: unexpected ";". Make minimal changes to the build script to fix this (run the entire script in bash?) Make sure that everything you use is present in the image first.

[Copilot]

@copilot the musl builds for NodeJS are now failing with sh: syntax error: unexpected ";". Make minimal changes to the build script to fix this (run the entire script in bash?) Make sure that ever...

Fixed in commit 18893cc. Removed trailing && operators from the multi-line build scripts. The docker-run-action converts newlines to semicolons, which was causing syntax errors like && ; when && appeared at line endings. The scripts now use plain newlines that convert cleanly to semicolons for sh compatibility.