Semantic File URLs

[bs-thomas]

After switching over from Thumbor to Sharp, the URLs become hashed jibberish.

I was wondering if there is (or will be) an option to have a more semantic URL for these files?

The reason I'm asking is really for having meaningful filenames, and hopefully a little advantage on SEO as well.

https://webmasters.stackexchange.com/questions/102419/converting-default-normal-filenames-to-a-random-string-of-text-whats-better

Just for your reference, IMGIX makes use of query strings to achieve a similar effect. Something like this: https://www.example.com/some-file-name.jpg?w=1903&h=933&fit=crop

with the optional "signature" query string appended to the end like this to avoid spam abuse:
https://www.example.com/some-file-name.jpg?w=1903&h=933&fit=crop&s=V5kYnb7bdDaCfgeB

Your help is appreciated!

Thank you very much!

[beomseoklee]

Thanks for your opinion, @bs-thomas
The solution is still supporting some Thumbor style URLs. You can refer to the implementation guide Appendix D: list of Supported Thumbor Filters.

Would it be enough to answer your question or you actually need a new feature?

[bs-thomas]

Thanks for your prompt response @beomseoklee .

I understand that it supports the legacy Thumbor style URLs, but reading some previous issues it doesn't seem to be quite fully supported, and also thumbor's API and Sharp's API and methods seem very different. In the long run in terms of sustainability, I feel that this structure is going to face some limitations and other unexpected issues.

I noticed that this project has switched from Thumbor to Sharp, and I could imagine that when there is a better library in the future, the default would be switched over to that new library. That is a good move actually, and I fully support this, because packages come and go, and when there's a better vendor, we should use the better one.

However, what I thought is that we should keep the interface flexible, and consistent, regardless of which image resizing package we use behind. That will minimize breaking changes caused to users of this package. Does that sound reasonable to you?

My Recommendation

After giving a deeper thought, my recommendation is actually to not copy IMGIX's interface, because it does have some limitations.

For example, consider if I have two operations: (a) Rotate 45 degrees, (b) Flip horizontally, on Imgix, the query string would be "?flip=h&rot=45.0"

But note that depending on the sequence, there could be two different outputs:
(sequence 1) if you perform (a) first, then (b)
(sequence 2) if you perform (b) first, then (a)

So my recommendation is to use the following format (or any format with similar logic):
"?m[]=flip(h)&m[]=rot(45)"

How does the above recommendation sound? And what do you think of this, in general?

=====

Also, I forgot to thank you and the team last comment, for making such a beautiful system for resizing images on-the-fly. It's really a cost savings approach. To be frank, I'm paying hundreds of dollars monthly just for IMGIX right now, just for resizing images. Sounds ridiculous, and that's why I'm looking for alternatives like this one now.

Thank you very much!!

[ahardin]

I would like to see this supported as well. Another reason is to allow CloudFront wildcard signed cookies.

In my scenario, all images are private. I would like to be able to generate a signed cookie for my users that grants access to the handler at a path like /companyABC/*. If I understand correctly, the only other 2 options besides signed cookies would be signed URLs (not practical when getting a list of thousands or even hundreds of images), or a Lambda@Edge authorizer. The Lambda@Edge would probably work well, but it's another moving part.

I'll check out the legacy Thumbor URLs as a stop gap.

[TomasBelskis]

This is something that we would be interested in also, as we currently are forced to keep using version 3.1 as it still supports Semantic File URLs for the serverless image handler function.

I can see that version 4.* supports some of the Thumbor style URLs, but this doesn't guarantee the longevity of it? It would be just as much of a risk to migrate to 4.* and have the support removed in later versions of the image handler.

Can you guarantee that the Thumbor style URLs, will be supported for further version of the image handler? If you cannot then can this be a feature, as the base64 encoded URLs just don't make sense for our use case.

[ahardin]

I just switched over to using the legacy Thumbor format and they work fine and play nicely with signed cookies. But, I only need to do resizing, so very limited use case. And it's also worrisome that those could (and probably should) be pulled out in a future version.

@bs-thomas's suggestion of abstracting the URL format away from the underlying processing library is spot on. That's certainly the "right" software design choice (if there is such a thing).

[Furytron]

The changing URL based on the underlying library and the hash in the URL is definitely an issue, especially for semantics and SEO. I would agree with @bs-thomas 's suggestion of abstracting the URL format from whatever library is being used. Keeping the Thumbor style URL from version 3.1 and allowing it in version 4.* could solve this problem. However, S3 bucket subfolders are not supported in version 4 from what I see in the docs. That would also need to be fixed if that style was used.

[beomseoklee]

@Furytron actually the latest version, v4.2, supports image files in subfolder as a part of PR #130 . The document needs to be updated. I will ask to update the document.

[Furytron]

Thanks @beomseoklee thats good news. Is there plans for long term support of Thumbor? Or at least the URLs?

[beomseoklee]

@Furytron we are going to support Thumbor style URLs as many of users actually use Thumbor style URLs.

But for the original topic, we will think about what would be the best way to support.

[bs-thomas]

I also wanted to mention that the current "hashed" URLs are creating issues for my Javascript components.

My javascript component is a "file uploader", and after uploading, it will read the "extension" of the URL, and depending on the extension, decides if the uploaded DIV should display a thumbnail image (eg. PNG, JPG, GIF), or not (eg. PDF, DOCX, ZIP). Without the extension, it is unable to determined this.

I have also another advice regarding on Thumbor URLs. While I think support of this should be continued (because many users are still using it), I would like to bring up the point that it actually modifies the "original URL" by changing the "path to the file".

I feel that mutations /variations of the image are supposedly "still the same image", and is only a "variation of the same image", so I personally feel that the URL should not be modified. "Query strings" is a very good tool to define these variations / mutations, and thus my original suggestion as follows:

"https://example.com/some/path/to/s3/example-file.jpg?m[]=flip(h)&m[]=rot(45)"

Parsing the above URL requires close to zero effort. Any tool or programming language can extract the query string away with some native function (in PHP we have parse_url()), and there you go you immediately get the actual file URL location. No complicated logic required.

Query string parameter "m" (standards for mutation) is an "array", and should be processed sequentially from first to last. This allows the flexibility of applying the "same function" twice (like how Sharp allows you to "chain methods").

Then we can legitimately perform the following operation:
"https://example.com/some/path/to/s3/example-file.jpg?m[]=rot(90)&m[]=rot(90)&m[]=rot(-180)"

... and we get the original image back ;-)

[beomseoklee]

Thanks for you guys comments all.
I've created a beta version which can include query strings on URL.

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

The supported filters are same as legacy Thumbor style, so you can refer to the Serverless Image Handler documentation.

Here is the example usage:

• Resize: https://example.com/some/path/to/s3/example-file.jpg?width=300&height=300
• Resize + fit-in: https://example.com/some/path/to/s3/example-file.jpg?width=300&height=300&fit-in
• Resize + fit-in + grayscale: https://example.com/some/path/to/s3/example-file.jpg?width=300&height=300&filter:grayscale()
• Resize + fit-in + grayscale + rotate: https://example.com/some/path/to/s3/example-file.jpg?width=300&height=300&filter:grayscale()&filter:rotate(90)

Since Amazon API Gateway supports multiple query string parameters that have the same name, every filter query string would be adapted. See the Amazon API Gateway documentation regarding multiple query string parameters on Amazon API Gateway.

As this is not the production version (experimental version), I would recommend you to test this version, and if it looks good to you, you might be able to use this one on your production environment. If not, please don't use this one on your production environment.

Please let us know if you have any feedback so that we can hopefully add this feature in the next update.

[bs-thomas]

@beomseoklee Thank you very much for your prompt implementation of a beta. Really appreciate it!

To be frank I haven't yet had a chance to try it out. But I do notice one thing that may not be able to address. (Or it could be that I have misunderstood something?)

Consider the following example:
"https://example.com/some/path/to/s3/example-file.jpg?m[]=flip(h)&m[]=rot(45)"

As you see, if I do a "flip horizontally" first, then do "rotate 45 degrees", the end result is different than if I do "rotate 45 degrees" first, and then do "flip horizontally".

So the "sequence" of these transformations do matter.

How would the new implementation address this issue, and how does it prioritize the transformations?

Thank you very much!

[beomseoklee]

@bs-thomas I haven't tried the order of filters (Thumbor flipping seems available with -0x-0 size, but we don't have this feature), but I'm sure that edits JSON object will have keys with query strings order, so what you are asking would be fine.

[bs-thomas]

@beomseoklee Sorry maybe I wasn't so clear on my question.

The original topic in this issue was related to have some sort of "common interface" (regardless if it were Thumbor or Sharp) so it could be used as an abstracted interface for this image handler.

You have came up with the new beta implementation, which uses this format:
https://example.com/some/path/to/s3/example-file.jpg?width=300&height=300&filter:grayscale()&filter:rotate(90)

But what I mean is, the above format does not present any sequence (which it could yield different results if the filters were different from the example you gave).

=====

Your Example, you have:

1. width=300
2. height=300
3. filter:grayscale()
4. filter:rotate(90)

If we flip them around, yields same result:

1. width=300
2. height=300
3. filter:rotate(90)
4. filter:grayscale()

=====

However, if we modify your Example slightly, so "filter:grayscale()" becomes "filter:flip(h)"

1. width=300
2. height=300
3. filter:flip(h)
4. filter:rotate(90)

If we flip them around, yields a different result:

1. width=300
2. height=300
3. filter:rotate(90)
4. filter:flip(h)

=====

Another flawed example is the repetition of some filters. Try changing flip(h) to filter:rotate(90)

1. width=300
2. height=300
3. filter:rotate(90)
4. filter:rotate(90)

The result we want is the image rotated by 180 degrees.

However, he above example would yield the following URL, with two equivalent keys:
https://example.com/some/path/to/s3/example-file.jpg?width=300&height=300&filter:rotate(90)&filter:rotate(90)

The URL above will only capture "filter:rotate(90)" once, which yields the resulting image to be rotated by 90 degrees only, and not 180 degrees.

=====

So, what I'm trying to say is, can the interface you have designed, be upgraded such that this flexibility could be put into consideration?

(Previously, I had a recommendation for you, by using query string arrays ?m[]=filterA&m[]=filterB....

I'm sure there are other ways, but just wanted this to be addressed, together along with the solution obeying the "semantic URL" rules).

Thank you very much!