Image passed through handler loses Content-Type

[wolfmcnally]

I am using the most recent (June 2019) version of the Serverless Image Handler. I have a bucket set up with source images. Here is an example of the headers returned from an image in the source bucket:

$ curl --head https://hijinnks-images.s3.amazonaws.com/3MODIaQ6oMzipQjW8BJltHaP6ra9mijhCA4Nkh7kP0U.png
HTTP/1.1 200 OK
x-amz-id-2: avRA+ztvXve8GcRi9hUl/qVaGexG2+MaCF2wDyUw9DHkqAt0clC5CxqqJ7EkWpuDGKWL4OOX2qY=
x-amz-request-id: 94E65A7B90E31B32
Date: Sun, 16 Jun 2019 06:08:11 GMT
Last-Modified: Fri, 14 Jun 2019 09:40:02 GMT
ETag: "026e65d25892062bf186de4917975615"
Accept-Ranges: bytes
Content-Type: image/png
Content-Length: 230040
Server: AmazonS3

As you can see, the Content-Type header is correctly reported as image/png. However, if I ask for the image via the Cloudfront Distribution in front of the Serverless Image Handler pipeline, the Content-Type header is incorrectly reported as image with no MIME subtype.

$ curl --head https://d1567g7kv270k0.cloudfront.net/3MODIaQ6oMzipQjW8BJltHaP6ra9mijhCA4Nkh7kP0U.png
HTTP/2 200 
content-type: image
content-length: 311473
date: Sun, 16 Jun 2019 06:05:45 GMT
x-amzn-requestid: c777ac00-8ffc-11e9-b697-f31138bb4941
access-control-allow-origin: *
access-control-allow-headers: Content-Type, Authorization
x-amz-apigw-id: bW9Y8GesIAMFYMQ=
access-control-allow-methods: GET
x-amzn-trace-id: Root=1-5d05dc39-ab9c2724dbab732dce1bba5a;Sampled=0
access-control-allow-credentials: true
age: 170
x-cache: Hit from cloudfront
via: 1.1 b052e5b910437a7391e6af4158f04edb.cloudfront.net (CloudFront)
x-amz-cf-pop: LAX3-C2
x-amz-cf-id: qQrq31i5BCo393UQA3r2108FNDzcMJLU2X66yO36TtXEBIK62K06EA==

The above URL is for the unmodified version of the image. The same problem occurs when I append a Base64-encoded Sharp request for cropping to 400x300. The Content-Type field is also incorrectly reported as image:

$ curl --head https://d1567g7kv270k0.cloudfront.net/eyJidWNrZXQiOiJoaWppbm5rcy1pbWFnZXMiLCJrZXkiOiIzTU9ESWFRNm9NemlwUWpXOEJKbHRIYVA2cmE5bWlqaENBNE5raDdrUDBVLnBuZyIsImVkaXRzIjp7InJlc2l6ZSI6eyJ3aWR0aCI6NDAwLCJoZWlnaHQiOjMwMH19fQ==
HTTP/2 200 
content-type: image
content-length: 230931
date: Sun, 16 Jun 2019 06:11:16 GMT
x-amzn-requestid: 8cc0209e-8ffd-11e9-af2e-8def4168eff4
access-control-allow-origin: *
access-control-allow-headers: Content-Type, Authorization
x-amzn-remapped-content-length: 230931
x-amz-apigw-id: bW-MqGbgIAMFT2A=
access-control-allow-methods: GET
x-amzn-trace-id: Root=1-5d05dd84-90c77daf49feb2fd9aa96531;Sampled=0
access-control-allow-credentials: true
x-cache: Miss from cloudfront
via: 1.1 bd310f631d1314e239dc9cd04967c61f.cloudfront.net (CloudFront)
x-amz-cf-id: V_G1bM04mkbz5DnCDJxqzqGbO074iiS2BJIncpMlfv-WIy46RnunJg==

This error does not appear to be dependent on the image type. Here is a JPEG from the same bucket:

$ curl --head https://hijinnks-images.s3.amazonaws.com/-c1iN7Rj6z3nflyiYzHmOn2C2WcNF57Elq1AtVBlBlA.jpg
...
Content-Type: image/jpeg
...

And the same JPEG delivered through the handler:

$ curl --head https://d1567g7kv270k0.cloudfront.net/-c1iN7Rj6z3nflyiYzHmOn2C2WcNF57Elq1AtVBlBlA.jpg
...
content-type: image
...

This appears to be a new issue introduced with the latest version of the Serverless Image Handler— this problem did not occur previously.

[hayesry]

Hey @wolfmcnally: thanks for bringing this to our attention. We'll look into the invalid content-type headers you've been seeing and provide an update when we have one!

[fabiovasini]

Probably there's a better way of solving this, but a workaround consists in using a regex to get the MIME type from the base64 image, then set the Content-Type header the that value in index.js (see the getResponseHeaders function).

[ahecht]

@biosini do you have a more specific example of how to implement this workaround? we're running into some issues where certain scrapers/validators (Facebook for one) are picky about the content-type being valid.

[ofir-shapira-como]

Hi, this issue also breaks common libraries like .NET Core HttpClient, in addition to Facebook's crawlers.

[beomseoklee]

We have updated our solution, and I believe your issue has been fixed. If you still see the issue with the latest version (v4.2), please feel free to reopen the issue.

You can refer to the recent changes here