Image handler V4.1 cannot access objects inside S3 folder

[Karlen92]

I found the following code is serverless-image-handler lambda function code.

parseImageKey(event, requestType) {
        if (requestType === "Default") {
            // Decode the image request and return the image key
            const decoded = this.decodeRequest(event);
            return decoded.key;
        } else if (requestType === "Thumbor" || requestType === "Custom") {
            // Parse the key from the end of the path
            const key = (event["path"]).split("/");
            return key[key.length - 1];
        } else {
            // Return an error for all other conditions
            throw ({
                status: 400,
                code: 'ImageEdits::CannotFindImage',
                message: 'The image you specified could not be found. Please check your request syntax as well as the bucket you specified to ensure it exists.'
            });
        }
    }

In the following lines

 const key = (event["path"]).split("/");
 return key[key.length - 1];

the function splits the path with /, which is also delimiter for s3 folders, as a result if I request with this url

mycf.cloudfront.net/fit-in/800x1000/images/004ac6-1572505735720.png

It actually seeks for

mycf.cloudfront.net/fit-in/800x1000/004ac6-1572505735720.png

Correct me if I'm wrong, or may be there is another way to access objects inside folder, or environment variable that could be attached before key.

Thanks in advance.

[tapughose]

@Karlen92 , thank you for reaching out. We are aware of the issue and there is an active PR with the fix which is not merged yet.

[OBrown92]

The fix in the PR is unfortunately not working for me. Is it somehow possible to deploy the 3.1 version again and then try to update it with the solution in the PR? Would be so nice if this will make it finally in the production version.

[Karlen92]

@OBrown92 download your code from lambda, edit the function in the lines I mentioned, and upload it to lambda, It works for me now in that way.

[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