502 error when using non-encoded URLs and no Accept: image/webp

[MidnightDesign]

When I try to retrieve an image without modifications using https://<distribution>.cloudfront.net/<s3-key> in Chrome, it is served just fine (in WEBP format), but when I try to do the same thing in Safari, I get an HTTP 502 response with the following body: {"message": "Internal server error"}.

This seems to be related to the Accept request header; when I change it from Chrome's default text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 to text/html,application/xhtml+xml,application/xml;q=0.9,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 (remove the image/webp), I get the same error.

I've tried to disable AutoWebP, but it doesn't make a difference.

[beomseoklee]

@MidnightDesign I'm sorry to hear you had an issue. Can you share more details about the error (CloudWatch Logs) and how I can reproduce the issue? I've tried with simple jpg file on Safari and Chrome, and both worked.

[MidnightDesign]

@beomseoklee Thank you for the quick response.

First of all, I just tried it with another image and it worked just fine; with the image/webp header, I get the WEBP file, without it I get the (original) PNG.

But the original image still doesn't work.
In the ServerlessImageHandler-ApiLogs-... log group I get the message 81.217.15.245 - - [09/Apr/2020:16:39:47 +0000] "GET /{proxy+} HTTP/1.1" 502 36 5c740d4e-5331-4eba-acd9-0888eac6d08.
In the /aws/lambda/ServerlessImageHandler-ImageHandlerFunction-... log group I get:

START RequestId: 52f3f47c-da84-4e18-a840-6d1b367d4efc Version: $LATEST
2020-04-09T16:44:52.777Z	52f3f47c-da84-4e18-a840-6d1b367d4efc	INFO	{
  resource: '/{proxy+}',
  path: '/keepersport/KS406/KS406-D2.png',
  httpMethod: 'GET',
  headers: {
... (let me know if you need the full message)
2020-04-09T16:44:53.946Z	52f3f47c-da84-4e18-a840-6d1b367d4efc	INFO	ImageRequest {
  requestType: 'Thumbor',
  bucket: '...',
  key: '...',
  edits: {},
  ContentType: 'image/png',
  LastModified: 'Fri, 31 Jan 2020 13:13:30 GMT',
  CacheControl: 'max-age=31536000,public',
  originalImage: <Buffer 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 09 c4 00 00 09 c4 08 06 00 00 00 2e 73 f5 3d 00 00 00 19 74 45 58 74 53 6f 66 74 77 61 72 65 00 ... 4404676 more bytes>
}
[ERROR] [1586450696093] LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413.
END RequestId: 52f3f47c-da84-4e18-a840-6d1b367d4efc
REPORT RequestId: 52f3f47c-da84-4e18-a840-6d1b367d4efc	Duration: 3321.88 ms	Billed Duration: 3400 ms	Memory Size: 1024 MB	Max Memory Used: 429 MB	

[MidnightDesign]

@beomseoklee Can you deduce anything from that?

[MidnightDesign]

This seems to be somewhat cache-related.

If I request an image first with the image/webp header, then the 502 is returned on subsequent requests without it.

If I request an image first without the header value, subsequent requests work both with and without it.

[beomseoklee]

@MidnightDesign I guess Lambda 413 is related to the payload size.
Would you mind sharing the original image and edits you used?

[MidnightDesign]

Here you go: https://d3p0lb6nhbndhk.cloudfront.net/keepersport/KS406/KS406-D2.png

I'm not using any edits in this case. I'm expecting lambda to just forward the original image.

Edit: Actually, that serves the WebP version. Here's the original.

[MidnightDesign]

Ping @beomseoklee

[beomseoklee]

@MidnightDesign I'm sorry for the late response. I've tested this one, and I can confirm that this is related to the response body size.

Using WEBP format, the response body size was about 188,068 bytes. However, with pure PNG format, the response body size was about 6,852,680 bytes which is bigger than AWS Lambda's limit.

We are considering how we can dealing with the return image which is bigger than AWS Lambda's limit.

I'm sorry for your inconvenience at this time.

[amcfarlane]

@beomseoklee would the Lambda limit have been an issue added with v5? I've just tried updating from v4 > v5 and had to revert back because we're getting a larger number of HTTP 502 responses with the following body: {"message": "Internal server error"}. In v4 this doesn't happen.

[beomseoklee]

@amcfarlane We fixed wrong webp option in v5. In v4.2, even though you don't choose to use webp automatically, it converted the format to webp. We fixed this issue, and that might cause a bigger image size.

[beomseoklee]

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