I tried to upload a 2MB file on a mobile connection and it worked; more detailed description / reproduction steps would help.

As far as I can see with some grepping, the only thing that can produce this exact message is an API error with the error code unknown, and while there are many similar error codes (such as unknownerror or unknown-error), I don't see any place where that exact code would be used in core. (The stash and chunked upload handlers do use error code unknown but they manually set a more verbose message. And they wouldn't effect Special:Upload anyway.) Also, such errors should be logged but I did not find anything useful:

tgr@fluorine:/a/mw-log$ zcat archive/exception.log-20150315.gz | ack-grep -i unknown

only turns up a bunch of Unknown or bad timezone errors.

So, more details about the exact steps resulting in these errors would definitely be helpful.

In T92790#1121578, @Rillke wrote:

I was unable to reproduce it. Is it possible that there is a mis-configured proxy or the like?

When it comes to proxies, anything is possible :) They could try some upload test (e.g. this or this or this to see if it's Wikimedia-specific. It would be also good to know what the HTTP status is and if there is any response body.

To make sure that the problem isn't on my side (router, virus software etc) I uploaded the same file to a Coppermine Gallery on one of my servers and it was saved there without a problem.

What should I suggest them to retrieve the HTTP status code from Special:Upload? I would proxy the requests through Fiddler but ... this is ways too advanced. They also said, it's simply "stopping to load".

I didn't see any error message, just the green moving circle in the Firefox tab that indicates traffic transfer stops and on the traffic monitor I can see that the upload stopped.

Perhaps it's also a Firefox issue. Obviously some users from Germany or with German language settings are affected primarily (or they just report errors more diligently).

In T92790#1122532, @Rillke wrote:

What should I suggest them to retrieve the HTTP status code from Special:Upload?

Plain web console should work, just make sure to open the network tab before pressing upload. When it stops, click on the last line with POST in the second ("Method") column and make a screenshot.

Perhaps it's also a Firefox issue. Obviously some users from Germany or with German language settings are affected primarily (or they just report errors more diligently).

Collecting affected browsers would certainly be nice.

I uploaded a 2MB file, throttling the speed with Charles for the first 10 min, and did not have any kind of problem.

Could be some sort of network issue, as in this case, then testing from the US would not prove much.

At any rate, these are probably two different errors - I doubt the unknown API error is caused by the same issue as the timeouts.

The API error happens both, with IE and Firefox.

Is there event logging for API errors?

In T92790#1123915, @Rillke wrote:

Is there event logging for API errors?

Not EventLogging as such, although UploadWizard does log its own API errors to EL (UploadWizardFlowError). As far as I can see though, ApiMain::executeActionWithErrorHandling() should log them in the exception log.

XHRs fail (the fail() handlers of jqXHR is invoked) with a xhr.status of 0. Users of Mozilla Firefox (presumably under Windows) are affected. From the log my upload script produced in one of the affected users browsers, it looks like they either have lightning fast internet connections or something is also broken with the upload progress reporting.

Looks like an issue on the browser or operating system level.

A zero status code and no error message typically means a CORS violation on Firefox. Is there a CORS request involved here? (Maybe something not honoring http:/https:?)

We really need someone to look at their error console, Firefox usually logs error codes there when requests fail for obscure reasons (they tend to be fairly useless but still better than error code 0).

In T92790#1158943, @Tgr wrote:

A zero status code and no error message typically means a CORS violation on Firefox. Is there a CORS request involved here? (Maybe something not honoring http:/https:?)

There should be absolutely no cross domain request nor an HTTP/S issue involved here. But when it comes to cryptography a lot is possible (that possibly only reveals itself when a large enough data payload is sent with it). Going to ask for console messages.

The people who reported this issue on COM:UH now say it's gone but there is a new report on COM:FORUM (1 April 2015). Actually there are two new reports another one (30 March 2015) saying they have trouble uploading a > 5 MiB file over a slow connection.

clueless as before:

POST https://bits.wikimedia.org/event.gif [HTTP/1.1 204 No Content 103ms]
POST https://commons.wikimedia.org/w/api.php [5ms]

The POST request that is supposed to send the file data is terminated after 5ms for no reason.

beim Hochladeversuch mit dem Assistenten habe ich keinen Response-Header gefunden

"Using UploadWizard I didn't find any response-headers."

All they can provide is

(4) POST https://commons.wikimedia.org/w/api.php [15ms]

with the following request headers:

Request-Header 18:09:51.000
User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Referer: https://commons.wikimedia.org/w/index.php?title=Special:UploadWizard&uselang=de
Pragma: no-cache
Host: commons.wikimedia.org
Content-Type: multipart/form-data; boundary=---------------------------1366923937327
Content-Length: 11625499
Connection: keep-alive
Cache-Control: no-cache
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

They also provided some response headers from special:upload but I suspect it's the Ajax call made for the file name after selecting a file.

15ms is way too fast for an API call. Even the EventLogging calls (which are terminated immediately by Varnish) take 60+ms from the same machine. Could be some sort of browser issue - try safe mode etc.

As for Special:Upload issue (which might be completely unrelated), note the X-Firefox-Spdy header in the API response - SPDY got enabled recently (T35890) and could be the source of anomalies. Not much chance debugging that via proxy, though. Maybe they could send a HAR file? (Note that it contains session data and they should log out and back in after saving the file.)

Anyone having an idea how to get this task out of "stalled" status? Is this still high priority?

By providing reproduction steps or a detailed description of what happens on the network level (such as a HAR file).
Since this error occurs rarely, is hard to reproduce (ie. it probably requires special circumstances) and causes no data loss or corruption, I would say it is low priority.

Aklapper lowered the priority of this task from "High" to "Low".

I don't think this is low. Error reports on commons everywhere.... Users are unhappy and stopping uploading :-(

I can appreciate your frustration, but... as far as priorities go, sometimes serious bugs that affect only a few people are less important than less serious bugs that affect lots of people. Especially when we don't have enough information to effectively do anything about the bug.

I'm not sure what we can do about this bug (Speaking specifically about the initial report, I have not reviewed the part in comment #1170946). Upload appears not to work for some reason that isn't reproducible by other people, and from what we do know, doesn't have any sort of obvious explanation. For a start, it would be helpful to know

• The exact version of firefox involved (So that we can test the exact version of firefox)
• Is there any unusual network configuration involved (proxies, tor, vpn, etc)
• Does the user have any sort of antivirus-esque/personal firewall type thing that maybe scans all outbound network connections. To that end, if visiting over https, could user verify the TLS certificate fingerprint, to make sure no local software (e.g. malware) is performing some sort of MITM attack on the connection.
• If the issue is still present after disabling all firefox extensions (E.g. starting in safe mode), and disabling all on wiki gadgets/ all things in special:mypage/common.js
• Can the user upload at test.wikipedia.org or other mediawiki sites
• If that all fails, a record of all the packets exchanged (e.g. What tgr was mentioning about a .har file, or like something generated with tcpdump) could be helpful, maybe.