Uploading a file with a different type, makes it use the file native handler with the original filename extension.
Which in this case means that this jpeg file was thumbnailed to http://upload.wikimedia.org/wikipedia/commons/thumb/archive/6/68/20110109213355%21Anticommunist_Literature_1950s.tiff/79px-Anticommunist_Literature_1950s.tiff
(compare to tiff thumbs: http://upload.wikimedia.org/wikipedia/commons/thumb/archive/6/68/20110109213357%21Anticommunist_Literature_1950s.tiff/lossless-page1-79px-Anticommunist_Literature_1950s.tiff.png)

When convert was requested to thumbnail it to 79px-Anticommunist_Literature_1950s.tiff, it dutifully converted it to tiff.

So, we are sending out a .tiff with image/tiff mime that is indeed a TIFF. The problem is that we don't want to do that, since browsers are not able to display tiffs.

pmarquesmota wrote:

The discussion about that was held in franch at http://commons.wikimedia.org/wiki/Commons:Bistro#Affichage_d.27un_fichier_tiff
Nothing actually showed up on the wiki pages using that version of the file.

Bryan.TongMinh wrote:

The bug here is that a user is able to upload a JPEG over a TIFF image...

Uploading a jpeg on top of a tiff file (or any other type of file for that matter), was a bug that existed for several years, but that has since been fixed.

It 'worked' because the thumbnailing core is extension agnostic, and will happily convert anything you throw at it. These files will however be served by the mediawiki core with the incorrect mime-type. This is usually not that harmful, though for usability sake, administrators can consider to delete this files, in order to prevent user confusion.

It would be better if we fixed the mime-type serving to be correct of course. I'm not sure how difficult that is.

If the thumbnailing handler ensured that the thumb url has the appropiate extension, this instance should fix easily.

Alolita, I've given this to you b/c it has to do with UI. Let me know if i'm wrong.

Bryan.TongMinh wrote:

I'm pretty sure this is not an UI issue, but an issue with the thumbnailer.

pmarquesmota wrote:

(In reply to comment #7)

I'm pretty sure this is not an UI issue, but an issue with the thumbnailer.

Or with the PagedTiffHandler extension config.

$ identify --version
Version: ImageMagick 6.5.1-0 2010-12-02 Q16 OpenMP http://www.imagemagick.org
Copyright: Copyright (C) 1999-2009 ImageMagick Studio LLC
$ identify /etc/motd
identify: no decode delegate for this image format `/etc/motd' @ constitute.c/ReadImage/526.
$ identify Anticommunist_Literature_1950s.tiff
Anticommunist_Literature_1950s.tiff JPEG 325x495 325x495+0+0 8-bit DirectClass 157kb
$ identify Anticommunist_Literature_1950s.png
Anticommunist_Literature_1950s.png PNG 325x495 325x495+0+0 8-bit DirectClass 60.2kb

At the very least, I believe the example configuration for the $wgTiffIdentifyRejectMessages parameter should say something like:

'/^identify: no decode delegate/',
'/(JPEG|PNG|GIF)/',

instead of

'/^identify: Not a TIFF/',

Bryan.TongMinh wrote:

I dived into the thumbnailing code a bit, and to solve the thumbnailing problem MediaHandler::getThumbType() should be a bit more intelligent.

It has as params $extension and $mime. By default is simply returns array( $extension, $mime ). What is should do is check if $extension is a valid extension for $mime, and if it is not, it should replace $extension with the canonical extension.

Bryan.TongMinh wrote:

(In reply to comment #9)

I dived into the thumbnailing code a bit, and to solve the thumbnailing problem
MediaHandler::getThumbType() should be a bit more intelligent.

Done in r81601. PagedTiffHandler appears to construct the thumb path somewhere else than getThumbType and thus needs fixing.

PagedTiffHandler is fixed in r88078. It overrides getThumbType. Now, it calls parent::getThumbType and checks if the mimetype is really image/tiff before proceeding with its own logic. If the mimetype is wrong, it returns the value determined by the generic method.