[Feature Request]: How i can use different header orders for each request?

[luigip02]

How i can use different header orders for each request?.

[thewebscraping]

Hi @luigip02 ,

In the current version, you can use a different header order per request by passing the headerOrder parameter (CamelCase, to match the Go binary) to the request functions.

Important: Manually changing header order is risky. Each browser has a fixed header order that matches its TLS fingerprint. If your tls_identifier (e.g. chrome_133) does not match the custom headerOrder, anti-bot systems (Cloudflare, Akamai, etc.) may detect the mismatch and block the request (403 or blacklist).

Only customize headerOrder if you understand the fingerprinting implications.

tls_requests.get(
    "https://example.com", 
    headerOrder=[
        "accept",
        "user-agent",
        "content-type",
        "accept-encoding"
    ]
)

[luigip02]

i tested and isn't working

this should be the right result

[thewebscraping]

Hi @luigip02

Thanks for reporting and testing this issue.

We’ve fixed the per-request headerOrder handling and the shared config bug in the latest release.
The fix is included in v1.2.3, which has now been merged and released.

Please update to the latest version and try again:

pip install -U wrapper-tls-requests==1.2.3

If you still notice any unexpected behavior after upgrading, feel free to reopen the issue or share a minimal reproducible example.
Thanks again for your feedback!

[luigip02]

still same thing, i updated with your command

[thewebscraping]

@luigip02
Can you provide the current code you are requesting, specifically the headers, headerOrder?

[luigip02]

import tls_requests

class Test_tls:
def init(self):
self.session = tls_requests.Client(client_identifier='chrome_144')

def start(self):
    headers = {
        "cache-control": "max-age=0",
        "sec-ch-ua": "\"Not(A:Brand\";v=\"8\", \"Chromium\";v=\"144\", \"Google Chrome\";v=\"144\"",
        "sec-ch-ua-mobile": "?0",
        "sec-ch-ua-platform": "\"macOS\"",
        "upgrade-insecure-requests": "1",
        "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36",
        "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
        "sec-fetch-site": "none",
        "sec-fetch-mode": "navigate",
        "sec-fetch-user": "?1",
        "sec-fetch-dest": "document",
        "accept-encoding": "gzip, deflate, br, zstd",
        "accept-language": "it-IT,it;q=0.9,en-US;q=0.8,en;q=0.7",
        "priority": "u=0, i",
    }
    
    response = self.session.get("https://tls.peet.ws/api/all", headers=headers, headerOrder=[
        "cache-control",
        "sec-ch-ua",
        "sec-ch-ua-mobile",
        "sec-ch-ua-platform",
        "upgrade-insecure-requests",
        "user-agent",
        "accept",
        "sec-fetch-site",
        "sec-fetch-mode",
        "sec-fetch-user",
        "sec-fetch-dest",
        "accept-encoding",
        "accept-language",
        "priority",
    ])
    print(response.status_code, response.text)

bot = Test_tls()
bot.start()

[thewebscraping]

@luigip02
One more note for verification

Since https://tls.peet.ws/api/all sorts headers alphabetically, you should not rely on header order in the response to validate behavior.

Instead, please check the TLS fingerprint values, for example:

ja3 = data.get("tls", {}).get("ja3_hash")
ja4 = data.get("tls", {}).get("ja4")

or compare the full tls fingerprint block (ja3, ja4, ciphers, extensions, etc.).

chrome_144 may not be supported at this time. If you test with different supported client_identifier (e.g. chrome_124 vs chrome_133), you should see different JA3 / JA4 values, which confirms that the TLS fingerprint and client profile are applied correctly.

Header order differences cannot be reliably validated using tls.peet.ws output alone.

Hope this clarifies