Migrating from Thumbor to SharpJS

[onassar]

Hi there -
Going through the flow to update my CloudFormation stack, and wondering if there's any good documentation on what's supported by SharpJS relative to Thumbor.

I'm finding it a tad confusing as to how to actually rewrite URLs, and what parts are supported (eg. full-fit-in, quality filters etc).

Is there any solid tutorials, documentation or examples I could follow?

[dscpinheiro]

Hi @onassar,

The list of supported Thumbor filters is available on the implementation guide: https://s3.amazonaws.com/solutions-reference/serverless-image-handler/latest/serverless-image-handler.pdf

AppendixD: List of Supported Thumbor Filters

[onassar]

Thanks; I took a look at that but didn't see the same transformations (eg. specifying just a width/height without a specific thing like full-fit-in).

Let me take a closer look and re-open this ticket if I can't find it.
Thanks for the quick reply!

[onassar]

Hi -
I've finally gone ahead and read through the Appendix, and am still a tad confused (aka can't get the Backward Compatibility features working).

Here is a sample URL using the 4.0 version (with SharpJS):
https://d1dlp8obae9u89.cloudfront.net/eyJidWNrZXQiOiJhcHAubG9jYWwuZ2V0c3RlbmNpbC5jb20iLCJrZXkiOiJhc3N0Ym9ybmRhMnciLCJlZGl0cyI6eyJncmF5c2NhbGUiOnRydWV9fQ==

This was created using the following run in your console:

copy(
    'https://d1dlp8obae9u89.cloudfront.net/' +
    btoa(
        JSON.stringify(
            {
                bucket: 'app.local.getstencil.com',
                key: 'asstbornda2w',
                edits: {
                    grayscale: true
                }
            }
        )
    )
);

This will copy the above URL to your clipboard, which works fine.

However, when I then follow the Appendix, I should be able to request the same (type of) image using the following URL:
https://d1dlp8obae9u89.cloudfront.net/filters:grayscale()/asstbornda2w

The error upon requesting that URL is:

{"status":400,"code":"RequestTypeError","message":"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."}

The image is a valid type.

---

Notice that the CDN hostname is the same, the filter is the same, and the object key is the same.

From the guide, it reads:

Thumbor image requests can be specified as normal, with filters and other relevant properties added on as suffixes to the default CloudFront ApiEndpoint. For example: https://.cloudfront.net/filters:grayscale()/image.png

Would appreciate some guidance.
Thanks!

[dscpinheiro]

Hi @onassar,

It looks like the image-request function expects the key name to contain the file extension:
https://github.com/awslabs/serverless-image-handler/blob/9ccdb7180c7881eb78c220f3958b671d968c16dd/source/image-handler/image-request.js#L160-L185

Would it be possible to check if problem still happens if the extension is present? For example:

{
  bucket: 'my-bucket',
  key: 'file.jpg',
  edits: {
    grayscale: true
  }
}

[onassar]

So the problem is that the object doesn't actually have a filename extension. That's by design. When I append a filename extension that matches the Content Type of the file, the URL becomes:
https://d1dlp8obae9u89.cloudfront.net/filters:grayscale()/asstbornda2w.jpg

But then the error (quite naturally) becomes:

{"status":500,"code":"NoSuchKey","message":"The specified key does not exist."}

It seems like the mistake here is the presumption that an object always has a file extension.

[onassar]

Happy Holidays! Also: bump ;-)

[dscpinheiro]

Hi @onassar,

As mentioned before, this is expected behavior of the solution at this time, but we'll keep this issue open and we will address it if there's enough demand for it.

For the next release, we're focusing on integrating the open PRs (https://github.com/awslabs/serverless-image-handler/pulls).

[onassar]

Okay thanks for the response. I would imagine it's not uncommon for people to omit file extensions, but I can't be sure.

[ianjamieson]

I know there are linked issues, but just for prosperity I would like to highlight I have this problem here:

#188

We do not use file extensions in our S3 bucket.

[G-Lenz]

We've added limited support for files without extensions in v5.2.0. Any image filters that use Amazon Rekognition (content moderation and smart cropping) will not work with files that do not have an extension.