CycleTLS
CycleTLS copied to clipboard
Danny-Dasilva
Streams and binary support for responses ?
Description
First of all, thank you for your time in maintaining this project.
I would like to know if it is currently possible to retrieve the HTTP response body in binary?
Is there any particular reason for the decision to return a string instead of a binary? The latter would have allowed anyone to do whatever they wanted, so I don't understand the choice made here.
Allowing the response to be streamed via the Streams API could also be a non-negligible addition for interesting use cases (implementing an HTTP proxy server to bypass a site's CORS).
Issue Type
Performance, Feature Request
Operating System
No response
Node Version
Other
Golang Version
Other
Relevant Log Output
No response
The primary reason was ease of use and how data is transferred from the golang side. I'll see where/how we can update the repo to support this.
The primary reason was ease of use and how data is transferred from the golang side. I'll see where/how we can update the repo to support this.
I would be willing to contribute to add binary and stream support to the library. Unfortunately this is my first experience with Go. If you are willing to give me some assistance I can work on it without any problem. Do you have a means of contact?
happy to get contributions, there's a public discord in the homepage of the repo https://discord.gg/gsmxMHrwhu, I can answer implementation questions there
might help if an api to create a ja3 capable http.Client could be exposed, , if we have an http.Client instance, this issue could also be solved. I think my issue could also help with this one. https://github.com/Danny-Dasilva/CycleTLS/issues/281
might help if an api to create a ja3 capable http.Client could be exposed, , if we have an http.Client instance, this issue could also be solved. I think my issue could also help with this one. https://github.com/Danny-Dasilva/CycleTLS/issues/281
Sorry for the delay. The problem encountered here is in no way related to your problem.
The problem here is caused by the JSON serialization of commands during WebSocket communication between the client and the JS library.
The only way to correct the problem is to replace the JSON serialization with binary serialization (with protobuf for example). But for reasons of simplicity, performance and lightness, I preferred to define the binary data structure by hand.