Page MenuHomePhabricator

Commons in rare cases offers WebP images when downloading PNG previews of SVG files
Closed, InvalidPublicBUG REPORT

Description

Wikimedia Commons labels previews of SVG files as PNG but sometimes actually delivers WebP files when I try to download them.

Propably related to task T27611

The orignal steps to reproduce cannot be reproduced by me anymore, please refer to this comment instead.

List of steps to reproduce (step by step, including full links if applicable):
* Got to https://commons.wikimedia.org/wiki/File:Gay_Pride_Flag.svg
* Download one of the PNG previews, e.g. https://upload.wikimedia.org/wikipedia/commons/thumb/4/48/Gay_Pride_Flag.svg/640px-Gay_Pride_Flag.svg.png
* Open the png file in a graphic editing software

What happens?:
* IrfanView error message: "640px-Gay_Pride_Flag.svg.png is a webp file with wrong extension!".
* Photoshop error message: "Not a PNG file"

What should have happened instead?:
* Either: correctly label the preview files as webp files on the file description page and then also provide the files with .webp file extension
* Or: deliver PNG files

Event Timeline

Suddenly, I can't reproduce this anymore like written above. It does still have the wrong URL (...png) but when I download the file, it is actually downloaded as a webp file. Maybe some caching issue?

But either way, the file description page and the image URL shouldn't lie, if I go to https://upload.wikimedia.org/wikipedia/commons/thumb/4/48/Gay_Pride_Flag.svg/640px-Gay_Pride_Flag.svg.png, it should be a png file, not a webp file.

Aklapper changed the task status from Open to Stalled.Jul 28 2021, 9:17 PM

Cannot reproduce on Linux:

$:acko\> wget -q https://upload.wikimedia.org/wikipedia/commons/thumb/4/48/Gay_Pride_Flag.svg/640px-Gay_Pride_Flag.svg.png
$:acko\> file 640px-Gay_Pride_Flag.svg.png 
640px-Gay_Pride_Flag.svg.png: PNG image data, 640 x 395, 4-bit colormap, non-interlaced

Cannot reproduce either when right-clicking in Firefox 90 or Chromium 91 and saving the 640px file locally: file says it is a PNG file.
What are exact steps to reproduce (how to download? which browser? which operating system? etc)

OK. So, the behaviour of the original issue doesn't happen at all anymore. The behaviour described in my first comment does really seem to happen only in very specific cases:

  1. Open Firefox 90.0.2 (64-Bit) or Chrome 92 on Windows 10 (I did not test on Linux). Caution: This does not happen in incognito mode (so a cookie issue?)!
  2. Open URL https://commons.wikimedia.org/wiki/File:Gay_Pride_Flag.svg
  3. Left click on the "640 × 395 pixels" link (this does not happen on any of the other preview sizes. It also does not happen when using Right click --> Save target as)
    grafik.png (365×533 px, 6 KB)
  4. The image opens in browser.
    grafik.png (805×1 px, 81 KB)
  5. Now right click and save as. A webp file is offered for download instead of a PNG file .
    grafik.png (100×261 px, 2 KB)
Discostu renamed this task from Commons serves WebP previews but labels them as PNG to Commons in rare cases offers WebP images when downloading PNG previews of SVG files.Jul 29 2021, 9:05 PM
Discostu updated the task description. (Show Details)

I'm also unable to reproduce being served a webp for https://upload.wikimedia.org/wikipedia/commons/thumb/4/48/Gay_Pride_Flag.svg/640px-Gay_Pride_Flag.svg.png on Firefox 90.0 on Linux. However, it sounds to me like everything is working as expected.

Requests for PNG and JPEG thumbnails may be served a webp when the client supports it and the thumbnail has been requested frequently. This is why only one thumbnail for that file was handled with a webp. Using "Save link as" may not send the header indicating webp support (I haven't checked, as it doesn't show up in devtools).

MediaWiki does not know if a particular thumbnail of a particular file may be handled with a webp, as that decision is made by the caching layer and the thumbnailer, independent of MediaWiki. As different thumbnails for the same original won't all be served in webp, changing the "PNG preview of this SVG file" message wouldn't really be practical.

Redirecting from .png to .webp instead of just serving the webp is not really necessary, and would likely cause caching issues. This behavior is fairly common among other websites with user-generated images, with some removing extensions from the URL entirely.

I'm not sure why using Private Browsing had any effect, but I think it is a red herring.

The orignally-reported problem was fixed in T254557: Thumbor doesn't save Content-Disposition: inline headers to Swift for webp thumbnails, however, some older thumbnails may be cached without the necessary header.

I'm closing this task per the last comment.