Page MenuHomePhabricator

Reply with HTTP 302 (temporarily moved) instead of HTTP 500 when a full-sized thumbnail is requested
Open, NormalPublic

Description

The current MediaWiki behavior, when requesting a thumbnail directly (i.e. by constructing a thumbnail URL, not via the API) is as follows:

  • if the size is smaller than the original image size, the thumbnail is served (assuming the wiki is configured to resize images of that type at all)
  • if the size is larger than the original, a HTTP 500 is returned (except for vector images, where "original size" is a pretty vague concept)
  • if the size equals the original, and the thumbnail would be significantly different from the original (more specifically, when mustRender() returns true for that file - e.g. files with EXIF rotations, or files which need to be converted to a different format for browser compatibility), the thumbnail is served
  • if the size equals the original, and the thumbnail would be essentially the same as the original, a HTTP 500 is returned.

The last step is presumably done to avoid wasting storage space on thumbnails when the original file would be just as good (which might or might not be a good idea, see T67383), but it is very confusing from a client point of view and makes it hard to construct a reliable thumbnail URL without having very detailed knowledge of the file. (The API can always be used to retrieve the correct URL, but that has a nontrivial time overhead.) See T70320 for an example of problems caused by this.

A better solution would be to return a HTTP 302 to the original file instead, so that the original is still used instead of a superfluous thumbnail when possible, but requests which do not need to fail don't.

Event Timeline

Tgr created this task.Nov 25 2014, 10:27 PM
Tgr updated the task description. (Show Details)
Tgr raised the priority of this task from to Needs Triage.
Tgr changed Security from none to None.
Tgr added a subscriber: Tgr.
Gilles triaged this task as Normal priority.Nov 26 2014, 4:12 PM
Gilles added a subscriber: Gilles.
aaron added a subscriber: aaron.Jul 17 2015, 8:52 PM

Also for T77697, having two CDN buckets (one for thumbs and one for originals) would be easier if this special case did not exist. Actual HTTP 200s would be desired for that use case however, rather than 302s.

Restricted Application added subscribers: Matanya, Aklapper. · View Herald TranscriptJul 17 2015, 8:52 PM
Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:31 PM
Restricted Application added a subscriber: Steinsplitter. · View Herald TranscriptSep 4 2015, 6:31 PM
bearND added a subscriber: bearND.Nov 10 2016, 5:33 PM

Sounds like this is an implementation proposal for T74328.

Restricted Application added a project: Commons. · View Herald TranscriptNov 10 2016, 5:33 PM
Tgr added a comment.Nov 10 2016, 6:36 PM

The ideal solution would be to do this + cache redirects in Varnish and somehow resolve them internally (ie. return the content cached for the redirected URL instead, with a HTTP 200). No idea how hard that is.

Restricted Application added a subscriber: Poyekhali. · View Herald TranscriptNov 10 2016, 6:36 PM
Tgr added a comment.Nov 10 2016, 6:47 PM

Sounds like this is an implementation proposal for T74328.

That task is about asking for a larger size than what exists; this is about asking the same size as the original, but in a wrong way. They should probably handled the same way though.

Change 332425 had a related patch set uploaded (by Mholloway):
thumb.php: Redirect rather than throwing 400 if requested width >= original

https://gerrit.wikimedia.org/r/332425

Change 332425 abandoned by Mholloway:
thumb.php: Redirect rather than throwing 400 if requested width >= original

Reason:
Seems not viable as written. Discussion to be continued on the linked Phab tasks.

https://gerrit.wikimedia.org/r/332425