Moving files breaks hotlinks to original file asset
OpenPublic

Description

Author: rd232

Description:
Hotlinking from external sites to Commons images is discouraged, but allowed (https://commons.wikimedia.org/wiki/Commons:REUSE#Hotlinking). Moving a file whilst creating a redirect unnecessarily breaks such hotlinks, because the upload.wikimedia.org URLs don't follow the redirect.

Example:

I've deleted this test, but the 404 page is exactly the same as for a deleted image.


Version: unspecified
Severity: major

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz35721.
bzimport created this task.Via LegacyApr 5 2012, 11:26 AM
MarkAHershberger added a comment.Via ConduitApr 5 2012, 6:30 PM

Was wondering about this the other day. Thanks!

Pine added a comment.Via ConduitMay 30 2012, 9:46 PM

I see how this is a problem, but I'm not sure that "high major" is the right importance if hotlinking from external sites is discouraged.

Rillke added a comment.Via ConduitJun 12 2012, 4:48 PM

Also, please don't expose internals like the hashed-directory-structure in the URL. Provide a stable id for each file-revision and one for each file-"stack".

Bawolff added a comment.Via ConduitJun 12 2012, 6:10 PM

(In reply to comment #3)

Also, please don't expose internals like the hashed-directory-structure in the
URL. Provide a stable id for each file-revision and one for each file-"stack".

Note, the hashed directories are "stable" since they will only change if the filename changes. While they are kind of internal-ish, I imagine removing them would cause more disruption to hotlinkers then any benefit it would have. I suppose both could be kept working, but really doesn't seem like all that important of a thing.

Krinkle added a comment.Via ConduitMar 16 2013, 2:33 PM

Perhaps this can be handled by the 404 handler for thumbnail generation?

Nemo_bis added a comment.Via ConduitJun 11 2013, 10:46 AM

Hotlinking is entirely legitimate; consensus has been often sought and never found to discourage it. Anyway, this can affect priority, but not severity, and this seems a major bug to me.

It is also for Wikimedia projects, by the way: e.g. http://fa.wikinews.org/?oldid=129251 produces on main page:
GET http://upload.wikimedia.org/wikipedia/commons/1/17/Wikinews_banner_22.png 404 (Not Found)

404 Not Found

The resource could not be found.

File not found: /v1/AUTH_43651b15-ed7a-40b6-b745-47666abf8dfe/wikipedia-commons-local-public.17/1/17/Wikinews_banner_22.png

Because [[commons:File:Wikinews_banner_22.png]] is a redirect.

Bawolff added a comment.Via ConduitJun 11 2013, 1:44 PM

(In reply to comment #6)

Hotlinking is entirely legitimate; consensus has been often sought and never
found to discourage it. Anyway, this can affect priority, but not severity,
and
this seems a major bug to me.

It is also for Wikimedia projects, by the way: e.g.
http://fa.wikinews.org/?oldid=129251 produces on main page:
GET http://upload.wikimedia.org/wikipedia/commons/1/17/Wikinews_banner_22.png
404 (Not Found)

404 Not Found

The resource could not be found.

File not found:
/v1/AUTH_43651b15-ed7a-40b6-b745-47666abf8dfe/wikipedia-commons-local-public.
17/1/17/Wikinews_banner_22.png

Because [[commons:File:Wikinews_banner_22.png]] is a redirect.

Note, that the sister project issue would also be fixed by bug 22390.

I agree this bug should be fixed for the hotlinkers (I would call it a normal priority issue).

Aklapper added a comment.Via ConduitMay 16 2014, 9:09 PM

I don't consider this a "major loss of function in an important area".
-> lowering severity.

Nemo_bis added a comment.Via ConduitMay 16 2014, 9:21 PM

(In reply to Andre Klapper from comment #8)

I don't consider this a "major loss of function in an important area".
-> lowering severity.

http://www.w3.org/Provider/Style/URI.html + [[m:Don't delete redirects]] (specifically, Brion threatening deflag of those breaking image redirects) make me disagree.

Bawolff added a comment.Via ConduitMay 17 2014, 7:43 PM

Just to clarify something, this is fixed for thumbnails (e.g. https://upload.wikimedia.org/wikipedia/commons/thumb/2/25/Rouge.svg/200px-Rouge.svg.png redirects properly to https://upload.wikimedia.org/wikipedia/commons/thumb/2/25/Rouge.svg/200px-Red.svg.png). Its only the original version of the file that breaks.


Perhaps this could be fixed by, modifying upload-backend.inc.vcl (https://git.wikimedia.org/blob/operations%2Fpuppet.git/production/templates%2Fvarnish%2Fupload-backend.inc.vcl.erb) so that in the case an original file asset is requested, and if swift returns 404, try instead going to Special:FilePath, and if that returns a redirect, return that.

So for example, going to https://upload.wikimedia.org/wikipedia/commons/2/25/Rouge.svg would be something like:
*Ask swift, swift returns 404
*Go to https://commons.wikimedia.org/wiki/Special:Redirect/file/Rouge.svg
If that returns a 302, and the 302 is not for the current url (to avoid loops) return that
Otherwise return the 404 from swift (Bonus points for a more user-friendly 404 page)

[I don't know much about the bowels of varnish, so there may be things I'm missing here]

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:32 PM
McZusatz added a subscriber: McZusatz.Via WebThu, May 7, 7:13 PM
McZusatz added a comment.Via WebSat, May 9, 8:00 AM

Just a workaround: People could use something like

<img src="https://commons.wikimedia.org/w/index.php?title=Special%3AFilePath&file=Button+clipboard+bold.gif&width=-1">
</img>

to hotlink non-thumbnail and thumbnail images with proper redirect.

Add Comment