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

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.