Feature Request: Provide a way to access final generated headers before sending the request

[PurpleTape]

Hi, first of all, thank you for creating and maintaining impit-node. It's a very useful library for mimicking real browser fingerprints.

Currently, the library works as a "black box" where it internally merges default headers, fingerprint-generated headers, and user-provided headers before sending the request. However, there is no programmatic way to access this final, merged set of headers before the request is dispatched.

This limitation, while keeping the API simple, prevents the library from being used in several advanced and critical scenarios. I believe that exposing these final headers would significantly increase the library's power and flexibility.

Use Cases Where Access to Final Headers is Needed

Here are some concrete scenarios where this functionality is not just helpful, but essential:

1. Debugging and Verification (Most Common)
When trying to bypass bot detection, it's crucial to know the exact headers being sent.

• Problem: Was my custom User-Agent correctly applied, or was it overwritten by the fingerprint generator? What sec-ch-ua-* headers were sent along with it?
• Current Workflow: Developers have to work blindly or rely on external tools like proxy servers (Fiddler, Charles) or reflection services (like httpbin.org) to inspect the final request. This complicates and slows down the development and debugging cycle.

2. Request Signing (Critical Blocker)
Many modern APIs (e.g., AWS S3, and many custom enterprise APIs) require requests to be cryptographically signed. The signature is almost always calculated over a canonicalized string that includes the HTTP method, path, and a precise list of headers.

• Problem: It's impossible to generate a correct signature without knowing the full list of headers that impit will add to the request. A signature created using only the user-provided headers will be invalid, causing the request to fail with a 403 Forbidden or Invalid Signature error.

3. Advanced Logging and Auditing
In production environments, it's often necessary to have detailed logs of all outgoing requests for post-mortem analysis, auditing, or security compliance.

• Problem: Logging only the user-provided options gives an incomplete picture of the actual HTTP request. A complete log should include the final headers to be truly useful for diagnosing issues.

4. Dynamic & Conditional Logic
Application logic might need to change based on the generated fingerprint.

• Problem: Imagine you want to add a custom header based on the generated User-Agent. For example: "If the User-Agent is Chrome, add X-Browser-Engine: Blink". This is impossible without first knowing what User-Agent was generated.

5. Cache Key Generation
For effective response caching, the cache key must be deterministic and incorporate all inputs that can affect the server's response. This includes headers like Accept-Language.

• Problem: Without knowing the final headers generated by impit, it's impossible to create a reliable and accurate cache key before the request is made.

Proposed Solution

The most straightforward and non-intrusive way to solve this would be to add a new method to the Impit class that exposes the header generation logic.

A new helper method: getFinalHeaders()

This method would take the same arguments as fetch (url and options) but would return the calculated headers instead of making a request.

import { Impit } from 'impit';

const impit = new Impit({ browser: 'chrome' });

const url = "https://example.com";
const options = {
    method: 'POST',
    headers: {
        'X-Custom': 'my-value'
    }
};

// New proposed method
const finalHeaders = await impit.getFinalHeaders(url, options);

// Now we can use these headers, for example, to create a signature
// const signature = createSignature(finalHeaders);
// options.headers['Authorization'] = signature;

console.log(finalHeaders);

// And then perform the actual fetch
// const response = await impit.fetch(url, options);

Conclusion

This would unlock all the use cases mentioned above without complicating the primary fetch API. It would make impit a much more powerful and versatile tool for professional developers.

Thank you for your consideration!

[barjin]

Hello and thank you for your interest in this project!

To me, it would make more sense to allow users to construct the Request object (MDN docs for native fetch impl). This way, the user could create the Request object separately, inspect it, potentially update parts of it and send it afterwards. All this while still following the JS's native fetch API.

Would something like this work for your use-case?

const impit = new Impit({ browser: 'chrome' });

const originalRequest = new impit.Request(
  "https://example.com",
  { headers: { ... } },
);

const signedRequest = new impit.Request(originalRequest, {
   headers: { 
      ...originalRequest.headers, 
      authorization: getSignedHash(oldRequest) 
   },
});

await impit.fetch(signedRequest).

Thank you for bringing this to our attention, we'll try looking into this.