Feature Request: Option to limit max dimension of output image

[diegoatpitch]

I would like to limit the dimensions of output images no matter what was requested.

Example:

• Original image: 24000x13500 (16:9) JPEG
• Server config: IMGPROXY_MAX_OUTPUT_DIMENSION=8000
• Request: /_/rs:fit:10000:5625/plain/my-image.jpeg
  • Resulting image resolution: 8000x4500
• Request: /_/plain/my-image.jpeg
  • Resulting image resolution: 8000x4500

I hope that makes sense and is helpful to others.

[DarthSim]

Hey @diegoatpitch!

Could you provide a use case for this feature?

[diegoatpitch]

The main use case is to reduce our CDN billing in a single shot.
Image sizes are calculated dynamically and on the client side. Sometimes we have some unnecessarily large images being requested.
We also are in a unique situation where we can't force all users to newer versions of the software, so adding this limit to client side would take at least 6 months to reach 90% of all of our requests.

Since this would be a server side configuration option it would help mitigate possible DoS attacks on instances without signature. I know this is not the ideal security scenario, but for us would help a great deal with mitigation.

[DarthSim]

We received a similar request some time ago. We didn't move forward with it because it does not actually prevent DoS attacks: imgproxy has a few processing options besides width and height that can be used for DoS.

We were in the same situation as you when developing our website. We have a demo on our website that allows you to resize an image and apply filters dynamically, thus we can't rely on pre-generated URLs. So we made an API that generates and signs imgproxy URLs based on the provided options. That API also checks the provided options so they match the restrictions. I would offer you to use the same approach.

Since we need to show the imgproxy URL on our site, our API just returns the URL, but you can make it to make a redirect. The API is very simple and responds in a millisecond while running on the smallest GCR instance.

The difference between our cases is that our API requires width and height to be provided while in your case, as far as I understood, it is not required. In this case, I'd offer to use a default preset: default=width:8000/height:8000. This should work because of two things:

1. The default preset is always applied before the processing options from the URL.
2. When the enlarge option is not used, imgproxy doesn't enlarge images, so the width and height options here will be treated as "maximum width" and maximum height. Of course, these options can be overwritten by the URL, but your API will take care of this.

The API is so simple that I could build a draft of it with a language I am familiar with if you like.

[koenpunt]

Requesting a large image could cause resource exhaustion, especially in kubernetes. We've seen pods being killed which had a memory limit of 768m. For now we've increased the memory limit, but limiting the output size would be a better solution.