Stop delivery of WebP images

[martin]

Hi.

We are using the current template v4.2. When updating the stack we had temporarily activated the AutoWebP parameter.

But since we don't need this function, we deactivated it again. For this I clicked "update" and select "use current template", but in the next step I set "AutoWebP" to "No".

Nevertheless we still get images in WebP format. Can anyone confirm this behaviour? We have deleted the cache several times, the changeover is more than 3 days ago now. Any ideas?

[beomseoklee]

@martin Sorry for your inconvenience. Currently, there's a small bug related to what you explained.

https://github.com/awslabs/serverless-image-handler/blob/19cbc3ce759d7c8d8ddc35081972d7ac1daf0c71/source/image-handler/image-request.js#L289-L300

You can fix this one to the below source code, and then you can upload the rebuilt zip file to your Lambda function.

    getOutputFormat(event) {
        const autoWebP = process.env.AUTO_WEBP;
        if (autoWebP === 'Yes' && event.headers.Accept && event.headers.Accept.includes('image/webp')) {
            return 'webp';
        } else if (this.requestType === 'Default') {
            const decoded = this.decodeRequest(event);
            return decoded.outputFormat;
        }

        return null;
    }

Once again, I'm sorry to hear that you are experiencing the issue, and we will include the fix to the next release.

[adrienne]

@beomseoklee - I don't actually know how to fix this via the zip file. I installed this through the automated installer and I'm not actually super familiar with how to make changes?

[beomseoklee]

@adrienne I'll provide you the easiest way. You can update your stack with the below beta version which includes the fix and some other features.

https://solutions-features-reference.s3.amazonaws.com/serverless-image-handler/v4.2.1-beta.2/serverless-image-handler.template

[walhallyus]

@beomseoklee I have the same issue, images are served as webp, I was able to force them to jpeg with "toFormat":"jpeg" parameter on edits and worked, but now I have also added "jpeg":{"quality":100,"chromaSubsampling":"4:4:4"} and I'm getting internal server error response.
I have updated servces to 4.2.1-beta.2 template but still getting webp images and if I add both parameters(toFormat and jpeg) getting {"message": "Internal server error"}

Here is my json config
"edits": {"withMetadata":true,"normalise":true,"sharpen":true,"toFormat":"jpeg","jpeg":{"quality":100,"chromaSubsampling":"4:4:4"}}

[beomseoklee]

@walhallyus Do you have more specific logs on your CloudWatch logs?

[martin]

Thanks @beomseoklee. I run the beta template in a new stack. AutoWebP is disabled.

But the response headers look like this:

• Content-Type: image/webp
• Date: Tue, 14 Apr 2020 09:27:26 GMT
• Last-Modified: Tue, 24 Mar 2020 06:42:02 GMT
• X-Cache: Miss from cloudfront

The file command means it's a JPEG. So only the Content-Type is still wrong. With version v 4.1 i get the content-type image.

[jcebuck]

@adrienne I'll provide you the easiest way. You can update your stack with the below beta version which includes the fix and some other features.

https://solutions-features-reference.s3.amazonaws.com/serverless-image-handler/v4.2.1-beta.2/serverless-image-handler.template

@beomseoklee thanks. If we run off this stack can we update to the stable channel when it is released - quite seamlessly?
What if we've made updates to the Lambda functions? I guess we just have to re-apply them after updating?

[beomseoklee]

@jcebuck If you have changed anything on your Lambda functions and you deploy the update, your Lambda functions source code would be replaced to the update, which means you would lose what you have customized, so you can re-apply them after updating as you mentioned.

[beomseoklee]

@martin Can you share the edits you used if it is possible to share?

[walhallyus]

I have:
'LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413.'
and
'The type of request you are making could not be processed. Please ensure that your original image is of a supported file type (jpg, png, tiff, webp) and that your image request is provided in the correct syntax. Refer to the documentation for additional guidance on forming image requests.'
But this is with the same image, I only add "toFormat":"jpeg","jpeg":{"quality":100,"chromaSubsampling":"4:4:4"} and i get this errors

[beomseoklee]

@walhallyus
'The type of request you are making could not be processed. Please ensure that your original image is of a supported file type (jpg, png, tiff, webp) and that your image request is provided in the correct syntax. Refer to the documentation for additional guidance on forming image requests.' would be from favicon.ico if you accessed from browsers.

Generally, 413 error is related to that your request or response body size is too big to process on Lambda. You can see the error code at here. Meanwhile, would you mind sharing the original image if it's possible so that I can see if it is really related to the payload size?

[bs-thomas]

@beomseoklee Interestingly, I'm getting the exact same error as @walhallyus

Can you check this image for me please @beomseoklee if possible? Not sure how to check this.

My question also is, why would the image affect payload size? It's grabbing from S3, right? I tried a 30MB JPG, and it worked like a charm. But when I use a 4MB PNG it returned 413.

Your help is appreciated.

[walhallyus]

@beomseoklee i have tested with large images and I get "message": "Endpoint request timed out"
here is the picture:

json:
{"bucket": "mu-bucket","key": "IMG_20200408_194147.jpg","edits": {"withMetadata":true,"normalise":true,"sharpen":true,"toFormat":"jpeg","jpeg":{"quality":100,"chromaSubsampling":"4:4:4"}}}

[jcebuck]

@walhallyus Do you get a 413 error or Endpoint request timed out?

Does this also happen with small or normal sized images?