The first 3 bytes determine whether the file is a .jpeg file
Is your feature request related to a problem? Please describe. Hello! When I was using the serverless-image-handler, I could not view files with a specific magic number (i.e. FFD8FFED). This line seems to be the cause. https://github.com/aws-solutions/serverless-image-handler/blob/develop/source/image-handler/image-request.ts#L441
To Reproduce Place a file with magic number FFD8FFED in your S3 bucket and specify application/octet-stream for Content-Type.
The following error occurs.
{"status":500,"code":"RequestTypeError","message":"The file does not have an extension and the file type could not be inferred. Please ensure that your original image is of a supported file type (jpg, png, tiff, webp, svg). Refer to the documentation for additional guidance on forming image requests."}
Describe the feature you'd like
Can I make it so that only jpeg files use the first 3 bytes (FFD8FF) to determine the extension? Although there are almost no JPEG files with magic numbers that do not match a switch statement such as FFD8FFED, the first 3 bytes seem to be appropriate for determining 'image/jpeg'.
Best regards.
@senk8 thanks for your report. we will take a look at it and add it to our backlog
I would vote to open this ticket again. In our case we had a valid (see [https://www.w3.org/Graphics/JPEG/itu-t81.pdf](the W3 JPEG specs) (Page 32) JPEG with a comment marker.
. Imho the check for the JPEG magic number does only cover a small subset of all valid JSON file headers.
In combination with a S3 "content-type" metadata set to "binary/octet-stream" the service is not able to identify some valid JPEGs and to handle them.
@ChiSamurai
I think that's fair, I'll open this back up and discuss with the team if adding it makes sense.
Thanks, Simon
@simonkrol This is the same issue I'm facing -- arbitrary images (in my case, from iPhone camera rolls) seem to hit this bug, unless the files are re-saved and re-uploaded.
Hi @mrb, @ChiSamurai and @senk8,
We've decided to include this change, you should see it become available in the next minor/major release of Serverless Image Handler.
Thanks for your thoughts, Simon
Fixed in v6.2.6 to only use the first 2 bytes to determine if the image is a JPEG.