Image passed through handler loses Content-Type

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.

[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

[ofir-shapira-como]

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