Page MenuHomePhabricator

Special:Upload reports that some valid PNG files have MIME type unknown/unknown
Open, Needs TriagePublicBUG REPORT

Description

This issue was originally reported by @Rsteen at https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#False_warning_for_png_files.

Rsteen was attempting to upload File:Christian Andreas Schleisner - Børn, der søger ly ved en båd på stranden - 1854.png and other files using Special:Upload from Firefox 76.0.1 (64-bit) and Windows 10 Home Version 1903.

Steps to Reproduce:
  1. Download a zoomable image >10 MB using https://ophir.alwaysdata.net/dezoomify/dezoomify.html
  2. Upload the PNG file to Commons using Special:Upload
Actual Results:

Error from Special:Upload: File extension ".png" does not match the detected MIME type of the file (unknown/unknown).

Expected Results:

MIME type is image/png, no error is generated


Firefox's MIME type detector correctly reported that the image had a type of image/png. Rsteen then uploaded the file without issue using Special:UploadWizard. I was not immediately able to reproduce the issue using Firefox 76.0.1 (64-bit) on Arch Linux.


Please note that this was done on a slow internet connection. First there was an error message saying that the servers were busy, please try again. When the retry was done the error message about the faulty png-file appeared. So this error can probably only be replicated on a slow internet connection.

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

[[User:Krinkle]] Please read the comments. You need to do this on a s l o w internet connection. And you need to get the message that the servers were busy (time-out). Then you press the "try again"-button and then you will experience an erroneous message faulting your file (png in this case). This has happened to me with around 10 different png files of >10 MB and it is a surefire way to put off inexperienced users.

Can you show what the "servers were busy" error looked like? (or copy its text into a comment). This would help determine where it is timing out for you.

How slow is "slow"? How long did it take to upload the specific PNG from "File:Christian Andreas Schleisner" between submitting the form and getting the "server busy" timeout error?

Hi. This is the error message - from a similar download today:

Error

Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.

See the error message at the bottom of this page for more information.

If you report this error to the Wikimedia System Administrators, please include the details below.

Request from - via cp3064.esams.wmnet, ATS/8.0.7
Error: 502, Next Hop Connection Failed at 2020-06-06 05:33:19 GMT

<END>

The message appears about five minutes after pressing "Upload". As I wrote earlier, the same file can be uploaded with Upload Wizard (in about six minutes) - but then you have to redo all the template work.

The "Try again" part can be clicked, and that is when you get the message that you have a faulty png file - which you haven't.

This can be replicated with any large png-file on a slow connection. Life here in rural Italy has many charms, but fast internet connections is not one of them. Cheers Ebbe.

Error: 502, Next Hop Connection Failed at 2020-06-06 05:33:19 GMT

That might be T250103 instead.

Do not think so.
In T250103 the upload eventually (after pressing "try again" ?) went through, and the problem was seen as solved.
Here there is some sort of time-out that results in a faulty error message.

Cheers Ebbe

Could this be related to chunked uploads? The Upload Wizard does support them, the legacy upload form does not. I remember very dark that I had similar issues several years ago when my internet connection was quite slow, too. The issues went away from the moment I used chunked uploads (I use the script bigChunkedUpload.js, though).

I cannot tell anything about the issues in detail anymore.

Krinkle added a subscriber: Krinkle.

Unassigning, I don't see anything here that suggests this recently stopped working or that it is related to MIME analyser.

The default upload form presented to users is Special:UploadWizard. I consider Special:Upload a hidden feature that only users use if they specifically want or need that for some reason and is thus less well-tested or cared for at this time.

Re-triaging as Upload/Multimedia. It looks like there might be some sort of problem with the form values we send. Specifically, if a user's first attempt results in a timeout or server failure (in this case HTTP 502 from ATS/Varnish), then when the user re-tries that retry is responded to with a fast failure from MediaWiki about the file having unknown/unknown as MIME.

Perhaps part of the form field information isn't being resent or is ignored on the second try for some reason. This is making it difficult for users with slower connections to contribute their media files.

I consider Special:Upload a hidden feature that only users use if they specifically want or need that for some reason and is thus less well-tested or cared for at this time.

At least for users with German setting this is not fully true: While also on top of Wikimedia Commons, Hauptseite (Commons start page in German) the upload button links to the wizard the link behind “Datei hochladen” (“Upload file”) in the sidebar leads to Commons:Hochladen, and there Special:Upload is presented “für erfahrene Benutzer” (English “for experienced users”). Similar constructs may be existant for other languages, but I do not know at all.

This said @Rsteen confirmed in Special:Diff/424591506/424619173 that with script bigChunkedUploads the issues disappeared, too. So my guess it could be in some kind related to chunked uploads or not, seems not to be totally unsubstantial.

I'm also not sure that I agree with that assessment of Special:Upload. It's the only way (except for external tools or gadgets) to upload a file with a custom description template (very common for me), overwrite a file, or upload a file to a wiki other than Commons.

Chunked uploads probably doesn't fix the underlying problem, but it does mask it. Special:Upload is all-or-nothing, making uploading a large file across a slow network more likely to time out. Chunked uploads split the file into smaller chunks, sends each one separately, then re-combines them server-side. That means each request can be completed quicker and won't time out. This situation appears to be a bit more complex than a simple timeout, but the basic point still stands.

Consulted with @MarkTraceur and this specific issue doesn't seem like something the SD team has expertise in. Maybe @brion has thoughts?