Skip Navigation
Issue Tracker @lemm.ee issue_tracking_bot @lemm.ee
BOT

[BE] Include support for handling image limits in the API #3655

github.com Include support for handling image limits in the API · Issue #3655 · LemmyNet/lemmy

Requirements Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support Did you check to see if this issue already exists? Is this only a feature request? Do not p...

Include support for handling image limits in the API · Issue #3655 · LemmyNet/lemmy

Requirements

  • [X] Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
  • [X] Did you check to see if this issue already exists?
  • [X] Is this only a feature request? Do not put multiple feature requests in one issue.
  • [X] Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Is your proposal related to a problem?

Some admins want to manage the amount of storage needed for image uploads and so have instituted limits on image sizes. Examples include lemmy.ee at 100kB (https://lemm.ee/post/25065) and beehaw.org at 4000x4000 (https://github.com/LemmyNet/lemmy/issues/3473#issuecomment-1620520547).

There does not seem to be a way to set, enforce or expose these rules via the API, so these appear to be implemented in NGINX, giving a 413 Payload Too Large error in the case of lemm.ee.

As a result, when a client app is attempting to upload an offending image, all it can currently tell the user is that the image is somehow too large and that they must find out for themself what the rules are.

Describe the solution you'd like.

The ideal would be that the instance handles the required resizing for the user.

If this is not seen as an attractive approach, it would then be extremely helpful for client apps if this information could be exposed via the API, so that they could query this information before attempting an upload and automatically handle the resizing to the instance's requirements on the user's behalf.

My initial inclination is that the bounding-box limit would generally be easier for developers to work with.

Describe alternatives you've considered.

The lemm.ee link above suggests that users should use other image hosts if their files are too large, but this is not an attractive option for app developers or end users, as if either requires the developers to make a choice of third-party host on behalf of their users (which some will doubtless have reasons for disliking) or it requires the users to make choices or take actions which they may not understand. Most users in most cases would rather just see their images resized, perhaps with a note in the app to inform them that this had happened in case they wanted to deal with this differently.

Additional context

No response

0
0 comments