Chrome136 emulation missing HTTP/2 setting causing Akamai detection

[gregl155]

Hi! Love rnet's protocol-level emulation approach! I found one issue with the Chrome136 profile.

The Issue

Real Chrome 136 sends 5 HTTP/2 SETTINGS during connection:

HEADER_TABLE_SIZE = 65536
ENABLE_PUSH = 0
INITIAL_WINDOW_SIZE = 6291456
MAX_HEADER_LIST_SIZE = 262144
UNKNOWN_SETTING_31386 = 3814263365  ← Missing in rnet

rnet Chrome136 only sends the first 4. This causes different HTTP/2 Akamai fingerprint hashes:

• Real browser: bad541c167b7b74e8b573127ea385fcb
• rnet: 52d84b11737d980aef856699f885ca86

Impact

Akamai-protected sites can detect this instantly since they fingerprint the HTTP/2 SETTINGS frame.

Test Code

import rnet
from datetime import timedelta

client = rnet.blocking.Client(emulation=rnet.Emulation.Chrome136)
response = client.get('https://tls.peet.ws/api/all', timeout=timedelta(seconds=30))
data = response.json()

print(data['http2']['akamai_fingerprint'])
# Missing the :3814263365 part that real Chrome has

Environment

• rnet: 3.0.0rc16
• Python: 3.13

Note

Your TLS fingerprint is spot-on! Just this one HTTP/2 setting needs to be added. This setting appeared in Chrome 130+ and is used by Akamai for bot detection.

Happy to provide more test data if needed. Thanks for the awesome library!

[0x676e67]

Interestingly, I never noticed that version 136 was like this. Will it remain like this in later versions? At least I don't see this HTTP/2 setting on macOS Chrome.

[gregl155]

You're absolutely right! I just tested Chrome 143 on my Mac and confirmed
it does NOT have UNKNOWN_SETTING_64026.

Chrome 142: check attached
Chrome 143: Does NOT have this setting
142_browser_testf.json

Do you think this is significant for akamai to block me?

[0x676e67]

To be honest, I'm not quite sure how it happened; I don't know for sure right now.

[gregl155]

do you plan to cover 143 in the near future?

[0x676e67]

Looking at the data you provided, there's even a frame setting with the ID UNKNOWN_SETTING_6906. Normally, browser requests wouldn't have such a frame setting that's not standardized in the RFC. I'm guessing it might be a custom frame setting by Akamai. I'm not sure if my guess is correct because I have no idea whether browsers can send custom frame requests like this.

[0x676e67]

I'm fairly certain that Chrome 142 on my macOS/Windows system doesn't send such a request, because I check the data fingerprint every time I update.