>>! In T66214#2106748, @faidon wrote:
> This isn't currently possible with the existing tech and without some rearchitecturing, so it's not just a matter of URL rewriting in VCL as has been already proposed. (upload.wikimedia.org traffic is directed directly to Swift, which knows nothing about the possible thumbnail sizes)

Agreed, we'd need to at least change some of the backend logic behind thumb.php and the 404-magic to resolve those edge cases... in which case we might be halfway towards making the existing system not awful without a URL reform ;)

>> Secondary use case: local caching of those images is simplified if the caching properties of those thumbnail URLs are more predictable.
> 
> Could you elaborate on that? Are you talking about content-hashed or other versioned URLs that always point to the same version of the image and can be locally cached or do you mean something else by predictable?

Version stability yes; this can be achieved without hash-based IDs by always including a timestamp with the link/reference provided in the web pages/APIs/etc.

>> Tertiary use case: there's a lot of use on mobile of squared-off images in lists/menus, and specially-cropped 'hero' images on articles. Having a cleaner thumb URL API should make it easier to extend it to move more of that cropping to the server-side, simplifying client code and reducing the amount of data transferred over mobile networks by pre-cropping unseen edges before download.
> 
> *Nod*, I remember hearing about this use case before. It doesn't seem to have been thought of in the existing strawman proposal so far and I agree that it's definitely something that we should keep in mind when talking about a "thumb API".

Yeah this is mostly a 'keep in mind we need to be able to extend whatever API we end up with, cleanly' reminder. The existing parameters stuffed into the thumbnail filenames (such as time point for videos, page for multi-page PDF/TIFF/DjVu, etc) are awkward and hard to parse or generate.