serverless-image-handler icon indicating copy to clipboard operation
serverless-image-handler copied to clipboard

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

Open senk8 opened this issue 3 years ago • 3 comments

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 avatar Jan 20 '23 05:01 senk8

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

dougtoppin avatar Jan 22 '23 16:01 dougtoppin

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. image. 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 avatar Apr 15 '24 12:04 ChiSamurai

@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 avatar Apr 15 '24 17:04 simonkrol

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

mrb avatar Jun 13 '24 15:06 mrb

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 avatar Jun 14 '24 16:06 simonkrol

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

simonkrol avatar Jun 27 '24 20:06 simonkrol