-
Notifications
You must be signed in to change notification settings - Fork 523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Image passed through handler loses Content-Type #103
Comments
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! |
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). |
@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. |
Hi, this issue also breaks common libraries like .NET Core HttpClient, in addition to Facebook's crawlers. |
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 |
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:
As you can see, the
Content-Type
header is correctly reported asimage/png
. However, if I ask for the image via the Cloudfront Distribution in front of the Serverless Image Handler pipeline, theContent-Type
header is incorrectly reported asimage
with no MIME subtype.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
:This error does not appear to be dependent on the image type. Here is a JPEG from the same bucket:
And the same JPEG delivered through the handler:
This appears to be a new issue introduced with the latest version of the Serverless Image Handler— this problem did not occur previously.
The text was updated successfully, but these errors were encountered: