The first 3 bytes determine whether the file is a .jpeg file

[senk8]

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.

[dougtoppin]

@senk8 thanks for your report. we will take a look at it and add it to our backlog

[ChiSamurai]

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.

[simonkrol]

@ChiSamurai

I think that's fair, I'll open this back up and discuss with the team if adding it makes sense.

Thanks,
Simon

[mrb]

@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.

[simonkrol]

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

[simonkrol]

Fixed in v6.2.6 to only use the first 2 bytes to determine if the image is a JPEG.