Http response code: 413

[vitalinfo]

I'm having 2 weeks conversation with AWS support, but without any results, hope somebody here will help me figure out what is going on.

Initial problem: for some images I've receive Internal server error with [ERROR] [1583405456446] LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413. on CloudWatch.

But, also I found today, that behaviour is much more odd, that I thought 2 weeks ago.

I have an image https://d3mnb0wkum09n0.cloudfront.net/eyJidWNrZXQiOiJjbGFzc3RhZy1zdGFnaW5nIiwia2V5Ijoic3RvcmUvZWJjSjhSOGpDSE04REpjVyIsImVkaXRzIjp7InJlc2l6ZSI6eyJ3aWR0aCI6MjA0OCwiaGVpZ2h0IjoyMDQ4LCJmaXQiOiJjb250YWluIn19fQ==

this link opens for Chrome, Firefox, Opera browsers (on different devices), but doesn't for Safari.

Looks like this image has been processed by CloudFormation (main question how?, because now I receive 413) and saved on CloudFront. But for some browsers it receives from the CloudFront, but for Safari it tries to proceed it again.

Of course main goal to fix 413 error, or at least found any workaround.
I'm using latest template https://s3.amazonaws.com/solutions-reference/serverless-image-handler/latest/serverless-image-handler.template

Any thoughts? Will be very appreciate for any ideas.

[beomseoklee]

@vitalinfo I'm sorry for your inconvenience.
I think the reason why you got 413 error is that your image size is pretty big, so it could exceed the AWS Lambda's invocation payload limit.

We will review the workaround or solution for this issue.

[vitalinfo]

@beomseoklee image size is 693Kb
I can't understand why it does work in one case and doesn't in another

[beomseoklee]

@vitalinfo Can you share the original image if you don't mind so that I can test exactly on the same page with you?

[vitalinfo]

@beomseoklee of corse,
Image:

edits config:

{"resize"=>{"width"=>2048, "height"=>2048, "fit"=>"contain"}}

[beomseoklee]

@vitalinfo Oh, you increased the size of the image, and I can see that the output of the image became around 8MB with your edits. That's why you get the 413 error.

The workaround can be put the output image to an Amazon S3 bucket, and load the image from the bucket. We will think about the best way so that everyone would be happy.

Once again, I'm sorry for your inconvenience.

[vitalinfo]

@beomseoklee thanks, will be great to have something like fallback_image

[beomseoklee]

The fallback image would be related to #137 , so please let us know your opinion for this one as well so that we can think of the best way for everyone.

[vitalinfo]

@beomseoklee I tried to do add new attribute to the params, like

{"bucket"=>"...", "key"=>"...", "edits"=>{"resize"=>{"width"=>2048, "height"=>2048, "fit"=>"contain"}}, "fallback"=>"origin"}

and return origin image, if fallback has been defined
but as I understand, isn't possible to catch 413 error inside the lambda code

[vitalinfo]

@beomseoklee ping

[beomseoklee]

@vitalinfo You are right. The error is generated by AWS Lambda itself, so it's hard to catch the error. The best way is to check the payload size, and if it's too big, then you can return fallback image before returning the result.

[vitalinfo]

@beomseoklee do you mean source/image-handler/image-handler.js -> modifiedImage size?

[beomseoklee]

@vitalinfo yes, or you can calculate processedRequest on source/image-handler/index.js.

[vitalinfo]

@beomseoklee Thanks
basically I've resolved my issue by add fallback image load handling on client side and add withoutEnlargement option to resize image config

I think we can close the issue

[vitalinfo]

@beomseoklee
I've faced with new problem
I've an image:

and when I try to apply such edits

{"backet"=>"...",
 "key"=>"...",
 "edits"=>
  {"resize"=>
    {"height"=>2048,
     "width"=>2048,
     "fit"=>"contain",
     "withoutEnlargement"=>true},
   "rotate"=>nil}}

it crashed with 413 error
any ideas how to prevent such crashes?
thanks

[beomseoklee]

@vitalinfo 413 error is related to AWS Lambda's limit. AWS Lambda's invocation payload limit is 6MB, so if the payload is larger than 6MB, it will throw 413 error. You can refer to AWS Lambda limits documentation.

For this issue, you cannot catch in the source code. Therefore, you might need to check the payload size first, and then when the payload is more than 6MB, you might need to put the image into Amazon S3 bucket, and return the new URL.

This issue is in our backload, so we are planning to implement this one at the next release.

[vitalinfo]

HI @beomseoklee , looks like problem is much trickier than just check payload size
f.e. I have 2 images, wich pretty much equal size

jpg resized successfully, but png doesn't

[demsey2]

I have the same issue but in my case, the problem is with png file 4.3MB which is lower than the limit

[beomseoklee]

Thanks for waiting. We've released v5.1.0 to mitigate this issue. The new version will throw an proper error message once your images exceed the Lambda limit.

@vitalinfo @demsey2 since we are using API Gateway Lambda proxy, we are encoding the image binary which causes bigger payload than the original image size. That's why you've faced an issue with images lower than the Lambda limit.