"Could not proceed due to network connectivity issues. Make sure you have a working internet connection and try again."
with both Firefox and Chromium.

There should be a checkbox "[ ] I'm on a slow connection. Don't time out!"

Also one would think that pushing the retry button offered would start where it left off.
Instead it tries the whole failed escapade again.

We try the alternative form, and before long:

This site can’t be reached
The webpage at https://commons.wikimedia.org/wiki/Special:Upload might be temporarily down or it may have moved permanently to a new web address.
ERR_SPDY_PING_FAILED

Maybe provide Upload by Email.

Chromium Developer Tools has these warnings

load.php?debug=false…version=08t0azm:141 JQMIGRATE: Migrate is installed with logging active, version 3.0.1
VM266:400 This page is using the deprecated ResourceLoader module "jquery.ui.position".
VM266:360 This page is using the deprecated ResourceLoader module "jquery.ui.widget".
VM266:355 This page is using the deprecated ResourceLoader module "jquery.ui.core".
Please use OOUI instead.
load.php?debug=false…version=08t0azm:310 PopupWidget#toggle: Before calling this method, the popup must be attached to the DOM.
load.php?debug=false…version=08t0azm:141 JQMIGRATE: jQuery.fn.offset() requires an element connected to a document
load.php?debug=false…ripts&skin=vector:4 Use of "jpegmeta" is deprecated.

But I bet that is unrelated.

Anyway where can I email the picture to, to prove that email is no problem?
I wish I could email it to my "stash". and once it is there add the tags to it.

Indeed unrelated, because we need "Network" tab output and not "Console" tab output.

The HAR file from the network tab is confusing because it is many
transactions glued together. 'nft flush ruleset' didn't help either.
Is there some way to ftp or email large (800 KB) .jpgs?

Is there some way to ftp or email large (800 KB) .jpgs?

For general support questions related to uploading files, see https://commons.wikimedia.org/wiki/Commons:Help_desk
For some available options, see https://commons.wikimedia.org/wiki/Commons:Upload_tools

Today I found a 4G+ high speed cell tower and uploaded from there instead.

This is a valid report, thank you: it's very hard to collect such information.

The failure is unlikely to be a bandwidth or timeout problem: usually it's a matter of latency and/or packet loss, cf. T62283. Can you please run mtr (also for Windows) so that we get a sense of the connectivity from you to the WMF servers?

On a GNU/UNIX command line, for instance:

for dc in ulsfo eqiad esams codfw eqsin; do echo ${dc}:; mtr -wc 10 text-lb.${dc}.wikimedia.org; echo; done

Thanks for the correction and help, @Nemo_bis! Do you think mtr for Windows is worth a line on wikitech:Reporting_a_connectivity_issue?

@Nemo_bis

Now in the better connected city, 15 km. away, using
https://en.wikipedia.org/wiki/FarEasTone
I get

@Nemo_bis And here is the super fast HiNet connection in the city, which I am even more sure always succeeds uploading.

Yes. I have to take my cellphone to the top of the mountain for a clear connection to upload, as your form requires high speeds or else it will fail.

And then last month I used up my cellphone allowance so was slowed down to 128 kbps and of course it failed.

In T205619#6153801, @Jidanni wrote:

Yes. I have to take my cellphone to the top of the mountain for a clear connection to upload, as your form requires high speeds or else it will fail.

Thanks. That's bad. The traceroutes don't provide much obvious insight: latency is comparable, packet loss zero, closest DC is eqsin which is already used for Taiwan per https://gerrit.wikimedia.org/r/plugins/gitiles/operations/dns/+/master/geo-maps .

I'm not sure the SPDY error is still relevant, but just to confirm: have you tried using another browser, for instance Firefox?

Some SPDY ping info for the curious:
https://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1#TOC-2.6.5-PING
https://bugzilla.mozilla.org/show_bug.cgi?id=728113

I'm sure alternate browsers were the first thing I tried.
Anyway, you would have to fix it for the world's biggest browser anyway.

So how about providing an 1990's back to bare bones basics oldest fashioned HTML 3 or whatever
https://www.w3schools.com/howto/howto_html_file_upload_button.asp
for me to test.

In T205619#6165085, @Jidanni wrote:

So how about providing an 1990's back to bare bones basics oldest fashioned HTML 3 or whatever
https://www.w3schools.com/howto/howto_html_file_upload_button.asp
for me to test.

That has always and ever existed at https://commons.wikimedia.org/wiki/Special:Upload ...

In T205619#6168027, @Aklapper wrote:

That has always and ever existed at https://commons.wikimedia.org/wiki/Special:Upload ...

Yes but under the hood that just has the same problem.
The whole website is using some kind of enhanced upload mechanism.

Today even with

https://commons.wikimedia.org/w/index.php?title=Special:Upload&uploadformstyle=basic
just gets up to 68% and says

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.

Request from - via cp5008.eqsin.wmnet, ATS/8.0.7
Error: 502, Next Hop Connection Failed at 2020-06-08 00:12:07 GMT

Next attempt got to 80%, then

Request from - via cp5008.eqsin.wmnet, ATS/8.0.7
Error: 502, Next Hop Connection Failed at 2020-06-08 00:14:44 GMT

OK, now got to 92%, and

Request from - via cp5008.eqsin.wmnet, ATS/8.0.7
Error: 502, Next Hop Connection Failed at 2020-06-08 00:17:09 GMT

Nope, 92% is as far as one can get, before

Request from - via cp5008.eqsin.wmnet, ATS/8.0.7
Error: 502, Next Hop Connection Failed at 2020-06-08 00:18:51 GMT

For a 400kb image. Workaround: upload to phabricator, then copy to commons.

Upload warning
Copy uploads are not available from this domain.

Great.

It doesn't make any sense that you can upload to phabricator, but not to commons.
I would suspect some crazy with some intermediate box, but the whole connection is encrypted.

I would recommend running mtr against both commons.wikimedia.org and phabricator.wikimedia.org (however, they both seem to be served by the same balancer)

Is it possible that the error is related to the use of UDP? Perhaps you are behind a NAT box that forgets UDP mapping after X seconds despite the flowing traffic. I would try forcing using a good old TCP connection.

Also, I would try saving the Special:Upload failed transfer as curl and retrying it from command line. That should help making small tweaks while keeping it simple to reproduce.

Does it also fail at https://commons.wikimedia.beta.wmflabs.org/ ?

OK finally succeeded via https://tools.wmflabs.org/url2commons/index.html
copying from phabricator to https://commons.wikimedia.org/wiki/File:Phony_water_tank_real_cell_tower.jpg .

https://commons.wikimedia.beta.wmflabs.org/ : OK, created account... Uploading .... and of course at the very end... "None of the uploads were successful."

I bet the form isn't even being sent.

pppd default-asyncmap defaultroute lcp-echo-failure 7 lcp-echo-interval
50 mtu 1492 noaccomp noauth noipdefault noproxyarp persist plugin
rp-pppoe.so usepeerdns user ---@hinet.net pty pppoe -I enp7s0 -T 80
-m 1452 enp7s0 debug

is how I connect.

Anyway, today I was given IP address 36.234.68.20,
so when you check the server errors logs above, you will see me.

OK, uploading the file to Twitter (takes about 20 seconds, but always a success), lots of healthy yellow seen in the icewm network monitor

Unlike when uploading to Commons: hardly a speck of yellow. I suspect the form isn't even being sent.
I would use tcpflow, to capture it, but this is HTTPS, so too much of a hassle.

@Jidanni: Could you please not create 12 comments in 70 minutes, but instead first run tests and then at the end properly summarize things in one comment? Thanks.

I ran the mtr tests earlier in this bug report.

Running a curl gives

{"errors":[{"code":"empty-file","html":"The file you submitted was empty.","module":"upload"}],"docref":"See https://commons.wikimedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes.","servedby":"mw1392"}

Anyway, do have a look at the logs of

Request from - via cp5011.eqsin.wmnet, ATS/8.0.7
Error: 502, Next Hop Connection Failed at 2020-06-08 16:29:50 GMT

Thanks.

I guess I will have to upload indirectly via phabricator until this is fixed...

OK. Made. https://commons.wikimedia.org/wiki/File:Bugu.ogg

Idea: Perhaps make a page, that combines phabricator's upload form, and
https://tools.wmflabs.org/url2commons/index.html ,
allowing ADSL users to upload in one step.

Couldn't even upload this to this bug report:

Upload Failure
m.mp3

Server responded: <!DOCTYPE html> <html lang="en"> <meta charset="utf-8"> <title>Wikimedia Error</title> <style> * { margin: 0; padding: 0; } body { background: #fff; font: 15px/1.6 sans-serif; color: #333; } .content { margin: 7% auto 0; padding: 2em 1em 1em; max-width: 640px; } .footer { clear: both; margin-top: 14%; border-top: 1px solid #e5e5e5; background: #f9f9f9; padding: 2em 0; font-size: 0.8em; text-align: center; } img { float: left; margin: 0 2em 2em 0; } a img { border: 0; } h1 { margin-top: 1em; font-size: 1.2em; } .content-text { overflow: hidden; overflow-wrap: break-word; word-wrap: break-word; -webkit-hyphens: auto; -moz-hyphens: auto; -ms-hyphens: auto; hyphens: auto; } p { margin: 0.7em 0 1em 0; } a { color: #0645ad; text-decoration: none; } a:hover { text-decoration: underline; } code { font-family: sans-serif; } .text-muted { color: #777; } </style> <div class="content" role="main"> <a href="https://www.wikimedia.org"><img src="https://www.wikimedia.org/static/images/wmf-logo.png" srcset="https://www.wikimedia.org/static/images/wmf-logo-2x.png 2x" alt="Wikimedia" width="135" height="101"> </a> <h1>Error</h1> <div class="content-text"> <p>Our servers are currently under maintenance or experiencing a technical problem. Please <a href="" title="Reload this page" onclick="window.location.reload(false); return false">try again</a> in a few&nbsp;minutes.</p> <p>See the error message at the bottom of this page for more&nbsp;information.</p> </div> </div> <div class="footer"><p>If you report this error to the Wikimedia System Administrators, please include the details below.</p><p class="text-muted"><code>Request from 2001:b011:9820:1939:692:26ff:fed7:a6da via cp5007 cp5007, Varnish XID 679561420<br>Error: 503, Backend fetch failed at Sun, 31 Jan 2021 17:30:04 GMT</code></p> </div> </html>

Same issue. Can't upload 20 MB webm video file using 80 KB/s speed upload connection. Can upload 22 MB jpg file..

Eventually on Chromium (Brave Browser) it shows:

ERR_HTTP2_PROTOCOL_ERROR

On Firefox it shows:

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.

Hi, following up on this to check if this issue still persists?

Today, using First World-grade Internet connections, I could still very simply reproduce the bug.

This means anybody can reproduce the bug.

Step 1: turn on throttling,
https://developer.chrome.com/docs/devtools/settings/throttling/

I chose these settings (256k down , 25k up):

{F37096805}

Now pick an 800 KB .jpg, and try to upload it. After a few seconds you will see:

Which means people with slower connections will simply not be able to participate at all in picture contests, etc.

It would be fair to have them wait a long time for their uploads to complete, as those are the simple facts of their connection.

But to cut them off completely is, well, pure First World / Third World discrimination.