Last modified: 2012-11-27 11:26:31 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T44133, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 42133 - Thumbnails for local uploads broken on Wikivoyage
Thumbnails for local uploads broken on Wikivoyage
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Media storage (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 41184
  Show dependency treegraph
 
Reported: 2012-11-15 02:31 UTC by Erik Moeller
Modified: 2012-11-27 11:26 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Erik Moeller 2012-11-15 02:31:40 UTC
Thumbnails aren't being generated on Wikivoyage. Example:
http://en.wikivoyage.org/wiki/File:Map_of_Agra_Fort.jpg

Thumbnail request fails as error 401:
http://upload.wikimedia.org/wikivoyage/en/thumb/4/47/Map_of_Agra_Fort.jpg/763px-Map_of_Agra_Fort.jpg

Only tested (with test upload as well) on en.wv, but may exist in other languages as well.

en.wikivoyage allows local fair use uploads under an EDP.
Comment 1 Faidon Liambotis 2012-11-15 03:03:28 UTC
Interesting corner case. So what happens is:

The request comes from the caching layer to Swift; from there, our rewrite handler in the pipeline tries to fetch it from Swift itself, and if that 404s, then it forwards it to imagescalers/MediaWiki.

However, since in this case the container doesn't exist, Swift defaults to 401, presumably for security reasons: attackers should not get 404 for missing containers, as this would allow them to brute force container names until they get a 401 (information disclosure).

So the request never gets passed on to imagescalers, and imagescalers never create the containers, so we're essentially deadlocked.

I'm reluctant to also forward 401s to imagescalers. The only solution I can see -other than creating them by hand in the rare cases we add wikis- would be for MediaWiki to be even more smart and create thumb containers when originals are made. I know very little of MediaWiki's Swift architecture though, so I can't speak for the feasibility of this.

I created the en.wv container by hand and it seems to work now; I didn't do the same for the other languages though, in case Aaron or someone else wants to test things.
Comment 2 Erik Moeller 2012-11-15 03:09:31 UTC
Confirmed working on en.wv, thanks. As standard operating procedure we should implement whatever the final fix is on all wikis, even ones with local uploads disabled, as they may always change their mind about wanting to enable them.
Comment 3 Erik Moeller 2012-11-27 02:42:04 UTC
This seems to be fixed on all wikis now so closing as fixed.
Comment 4 Faidon Liambotis 2012-11-27 11:26:31 UTC
How was this fixed? Aaron, did you create the containers or did you fix MediaWiki to somehow create them? We should note this for next time :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links