CycleTLS
CycleTLS copied to clipboard
Danny-Dasilva
Image types are base 64 encoded. v0.0.19+
Description
Images are by default base64 encoded, when that make no sense for the Go version of CycleTLS...
Unless your planning on directly dumping a image directly from CycleTLS to JS on the browser side.
That means any program in Go that:
- Raw Save the Image on the server
- Converts the Image on the server before sending it out (and again.
Is forced to deal with the overhead of a) encode the image to base64 (cycleTLS) and then decode that same base64 image back to a []byte. What i am doing right now ... Imagine images that are 8MB+ in size, ...
The final delivery needs to be the developers choice if he is sending a raw image or a base64 one because of JS reciever) This feels like a solution that fits a specific developer choice but introduces overhead for just about all other users. When it really needed to have been a flag.
Also, why are bodies even send with string, and not with io reader interface available. It feels like what people need is a basic CycleTLS for fingerprint free connections but things like base64 encoding, js output really belong on the end user side.
Issue Type
No response
Operating System
No response
Node Version
None
Golang Version
None
Relevant Log Output
No response
Hey, good call on this. This was raised in this issue and is being worked on by @RealAlphabet on his fork https://github.com/RealAlphabet/CycleTLS/commits/main, the main concern is breaking changes on the javascript side but this should be do-able
Description
Images are by default base64 encoded, when that make no sense for the Go version of CycleTLS...
Unless your planning on directly dumping a image directly from CycleTLS to JS on the browser side.
That means any program in Go that:
- Raw Save the Image on the server
- Converts the Image on the server before sending it out (and again.
Is forced to deal with the overhead of a) encode the image to base64 (cycleTLS) and then decode that same base64 image back to a []byte. What i am doing right now ... Imagine images that are 8MB+ in size, ...
The final delivery needs to be the developers choice if he is sending a raw image or a base64 one because of JS reciever) This feels like a solution that fits a specific developer choice but introduces overhead for just about all other users. When it really needed to have been a flag.
Also, why are bodies even send with string, and not with io reader interface available. It feels like what people need is a basic CycleTLS for fingerprint free connections but things like base64 encoding, js output really belong on the end user side.
Issue Type
No response
Operating System
No response
Node Version
None
Golang Version
None
Relevant Log Output
No response
This is not related to a specific choice of the developer but to a limitation caused by the serialization of commands and responses in JSON during WebSocket communication between the CycleTLS instance and the JavaScript part.
I agree with you that this should be up to the user to choose and that CycleTLS should not manipulate the data received.
For this reason, as Danny explained in his message, I am currently working on a new binary communication mechanism via WebSocket between the library and the client. This will resolve the issues you are currently experiencing as well as enable the following things.
- Obtain raw, unmanipulated data.
- Support for Streams in JS.
- Cancellable queries in JS.
Note: For the last two features, my PR is not specifically aimed at implementing them on the Go library side. If it works great, otherwise too bad it will require another PR.
Also, don't hesitate to contribute to CycleTLS if you have specific needs that you think could be useful to everyone.
