Page MenuHomePhabricator

Thumbnail purging inconsistent for shared image repositories
Closed, ResolvedPublic

Description

When deleting images the previous generated thumbnails are still available via
their absolute URL:
http://de.wikipedia.org/wiki/Spezial:Wiederherstellen/Bild:Brigitte_Mohnhaupt.jpg
was deleted on 14th Feb. 2007 as copyvio but
http://upload.wikimedia.org/wikipedia/commons/thumb/c/c1/Brigitte_Mohnhaupt.jpg/250px-Brigitte_Mohnhaupt.jpg
is still available (at least at writing this bug).

If not too expensive please call the purge function at time of deleting the image.


Version: 1.11.x
Severity: normal

Details

Reference
bz9053

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:36 PM
bzimport set Reference to bz9053.
bzimport added a subscriber: Unknown Object (MLST).

The purge function is called at delete time.

There are currently issues with the specific additional thumbnail
storage layer for commons.

robchur wrote:

*** Bug 9949 has been marked as a duplicate of this bug. ***

  • Bug 10686 has been marked as a duplicate of this bug. ***

I believe we've got this one sorted out now; thumb requests for sizes that aren't available (due to being at or larger than the original file size) used to be incorrectly served out and then saved onto the thubmnail cache server used for Commons.

This file would never get purged through the automatic system since it wasn't present on the master server.

The invalid requests no longer return a 200 OK code, so they don't get saved onto the thumb server; thus they won't get stuck like this anymore.