Feature Request: Add Chrome 142 Browser Emulation Support

[orangehaired]

Is your feature request related to a problem? Please describe.

I'm frustrated when I need to emulate the latest Chrome browser version but rnet only supports up to Chrome 141. As Chrome 142 is now released and being used by real users, not having this emulation makes it harder to properly mimic current browser behavior and can lead to detection by anti-bot systems that check for outdated browser versions.

Describe the solution you'd like

I would like rnet to add support for Chrome 142 browser emulation, including:

• Adding Emulation.Chrome142 to the available browser emulations
• Implementing proper TLS fingerprints for Chrome 142
• Including correct HTTP/2 settings and headers for Chrome 142
• Updating the documentation to list Chrome 142 in the supported browsers

Describe alternatives you've considered

• Using Chrome 141 as a fallback, but this may not match the latest browser fingerprints
• Manually configuring TLS and HTTP/2 settings, but this requires deep knowledge of Chrome's internals
• Using other libraries, but rnet has the best performance and fingerprint accuracy

Additional context

Chrome 142 is currently available and being actively used. Having up-to-date browser emulations is important for maintaining compatibility with modern web services and avoiding detection. The sooner this is added, the better it will be for all rnet users who need the latest browser support.

Thank you for maintaining this great library @0x676e67

[orangehaired]

Maybe we could build a dynamic fingerprint detection tool similar to gospider007/fp? This tool can automatically detect JA3, JA4, and HTTP/2 fingerprints from real browser clients. Having something like this could help keep rnet's fingerprints up-to-date automatically whenever new browser versions are released, making the maintenance process more sustainable. I need your ideas because I want to contribute to this project @0x676e67

[0x676e67]

There is no change in the fingerprints of chrome 132 to 142. You only need to update the version number of the user-agent string. If you want the template to be updated, you can submit the enumeration of Chrome142 to PR, which was released by wreq-util yesterday.

[orangehaired]

Regarding serialized spec strings for ClientHello and HTTP2 headers (like in gospider007/fp):

rnet uses structured configuration instead of serialized strings, like this

tls_options = TlsOptions(curves_list="X25519:P-256:P-384", ...)http2_options = Http2Options(initial_window_size=16777216, ...)

also serialized way:
16030106d2010006ce0303b0c5e893b5b7aef27fa325daf401f05...

Supporting serialized fingerprint specs (similar to gospider007/fp) would be useful for: quick fingerprint testing, integration with fingerprint databases.

Are you interested in supporting serialized fingerprint spec strings as an alternative configuration method? Or should we stick with the current structured approach? @0x676e67

Btw I opened PR (#409)

[0x676e67]

These string fingerprints are a piece of shit💩, the information does not match, and the extension cannot be accurately configured.

[0x676e67]

I don't plan to support automation, because there is very little information that can be provided. At the same time, I need to adapt the fingerprint data of other platforms. Automation alone can't do it at all. At the same time, I may need to adapt new extensions for the library, which can only be done by manually updating the data set.