-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Buffer not convertible to image ? (yes it can) #8
Comments
yes it can. currently is dealing (in my projects) with binary payloads. take a look to this two videos: |
yes, I am currently testing locally with a node.js app.
thats on my body variable, then I do:
then I use part.data and try to save it somewhere:
Interesting, when I use
The produced string displays: and if we transform the image to base64 before sending it, the string ends in: btw, I originally wanted to process the image before writing it somewhere or uploading it to S3, so I was trying:
But graphics magick wasnt understanding the buffer I was using, so thats why I wanted to first write the unmodified file somewhere before troubleshooting Image Magick. :( |
Ok, I found the error, it is on my side. Since I am using json-server for this, I was handling my post request this way: server.post('/products', (req, res) => {
At this point, if we log body, we would get something like this:
Then I was using this line of code to get the body Buffer in one variable like this:
NOW THIS IS THE BUG, my error was that I was converting the Buffer to string like this:
where the parse-multipart is actually able to parse the Buffer without being a string.
And now I can write the correct image this way:
*Before this bugfix, I was able to write a file but as a corrupted image on disk |
One more thing: Aws. It preprocess your binary payloads and take care of the conversion issues, so you should pass your binary payloads in base64 everytime. |
about your last message: "Conclusion, don't mess with the Buffer ^^", im sure is due to this: One more thing: Aws. It preprocess your binary payloads and take care of the conversion issues, so you should pass your binary payloads in base64 everytime. |
yes, I am aware of it, thank you for the reminding. I skipped that step to make it easier to debug, and at the end I added more complexity that caused the bug! ^^ Anyways I am happy with the end result! It feels good to have a productive week after all! |
Unfortunately by testing the "Lambda-Proxy integration", this returns to be an issue, since the payload is handled by AWS in the form of: (JSON.Stringified for testing purposes...)
In attempts to transform the body to another Buffer's format, I got the following results:
After that I haven't been able to recover the image file inside the lambda... :( |
Once the image file arrives in the form of:
data: <Buffer 41 41 41 41 42 42 42 42 ... >
It can not be directly converted to an image file. Is there a way to transform this data payload into a readable buffer?
The text was updated successfully, but these errors were encountered: