Can we get some more debugging details from the browser? Is there some way you can ask it for more detail about the nature of the failure when it happens? There was a similar report from @Danny_B last night on IRC too, and I think he's also a Firefox user.

I can confirm that most of the cases I remember happened when POSTing (save/preview page, save preferences, filtering on special pages...), can't guarantee it was only POST though...

Spotted in various browsers, not Firefox only. (Unfortunately Firefox doesn't give useful message for this case :-/)

I'm connected from Europe, should the server farm location be involved...

Just to tag on, also Europe (UK) and also on POST events - it's very periodic (twice today through a couple of hours editing)

Without a more-detailed error message or some kind of trace of the connection attempt, it's difficult to get to the bottom of this. There are a thousand reasons a secure connection can fail, including very mundane ones...

As a random experiment, perhaps some of those reporting could try this in FF 46.0.1?

1. Type 'about:config' in the URL bar (it will probably pop up a warning about voiding your warranty - if so click I'll be careful, I promise!)
2. In the search box at the top, narrow down the choices by typing http2
3. In the few entries below, look for the one with the name network.http.spdy.enabled.http2. It should be at it's default value of true
4. Double-click to toggle it to false
5. Restart browser just to be sure it's taken full effect.

If the intermittent problems vanish because of this, then we know it's something HTTP/2 related (which just rolled out last week. There could be some minor FF<->nginx HTTP/2 compatibility issue here).

Note the above would test the hypothesis that we're hitting this: https://www.ruby-forum.com/topic/6878264

@BBlack completely understand, I'll try the above (Win 8.1 Pro + FF 46.0.1) and report back - saying that, I've spent the last couple of minutes trying to force it to happen (both before and after the above change) and couldn't get it to occur.

EDIT: Okay my mistake - having come home from work I'm now using FF 47.0b3 (on the beta release branch) and have had no problems for the last ~hour

I should've noted above: if you apply the manual HTTP/2 disable, please don't forget to turn it back on later after sufficient testing!

For cross reference:

• T96848: Support HTTP/2
• T134817: HTTP/2 Issue with OkHttp/nginx

While there's a possibility this is an HTTP/2 issue, it's also possible that's a number of other things, including some generic bug in Firefox that's not protocol specific.

Hi @BBlack thanks again for the above - I did remember to turn this off, not keen to be surfing around without it! At work (Win 8.1 Pro + FF 46.0.1) the issue reappeared until changing to the beta update channel (Win 8.1 Pro + FF 47.0b4) and not had an issue so far - I'll update if I do, though seeing as 47.0b3 was okay for the entire of yesterday evening I am expecting this to have solved the issue. I can't see anything in the FF change log which would suggest a fix though

We may have been seeing the same bug here as https://bugzilla.mozilla.org/show_bug.cgi?id=1271301 - you might want to see if the test in that bug work from FF 47 but not 46 as well. There's no bugfix link there, but it's similar and recent.

I would just like to add that I've having the same issue, but it occurs when saving almost any edit, as well as trying to XfD in Twinkle, and I'm on FF 46.0.1 on Win10.

Submitting Special:Emailuser hit the same issue as well -> title change.

Users from the French Wikipedia have the same issue: https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/19_mai_2016#Votre_connexion_n.27est_pas_s.C3.A9curis.C3.A9e

I also have this issue on fr.wikisource

In T134869#2281369, @BBlack wrote:

As a random experiment, perhaps some of those reporting could try this in FF 46.0.1?

1. Type 'about:config' in the URL bar (it will probably pop up a warning about voiding your warranty - if so click I'll be careful, I promise!)
2. In the search box at the top, narrow down the choices by typing http2
3. In the few entries below, look for the one with the name network.http.spdy.enabled.http2. It should be at it's default value of true
4. Double-click to toggle it to false
5. Restart browser just to be sure it's taken full effect.

If the intermittent problems vanish because of this, then we know it's something HTTP/2 related (which just rolled out last week. There could be some minor FF<->nginx HTTP/2 compatibility issue here).

Just tested, no more error messages.

OTRS members have the same issue with Firefox 46.0.1 on https://ticket.wikimedia.org/ when sending a ticket.

https://lists.wikimedia.org/mailman/private/otrs-fr/2016-May/000981.html

Adding Browser-Support-Firefox as it seems to be its issue only ATM (no other browser verified yet - in such case, remove this tag again, please)

Seeing this error too. For me too, "it occurs when saving almost any edit", (or at least most edits) since a couple days ago.

Retrying has always worked to save the edit. I'm nowhere near Europe. On MacOS X.

@Danny_B: I doubt it's a firefox-caused probem; I bet firefox is just better at warning/notifying users of security risks than other browsers. (I recall this being true with other security issues.)

Also, just want to mention the second line of the error I am seeing, since I don't see it mentioned so far. Full error is:

Secure Connection Failed
The connection to the server was reset while the page was loading.

Annoying!

@Thibaut120094 : will try that.

Tried it. Disabling http2 as @BBlack /@Thibaut120094 suggested eliminates the error for me too.
It seems to occur only if the browser's connection to the site has been idle for a few minutes. So it's probably timeout related. (Tested at User:Elvey/sandbox on en but didn't nail it down.)

We've just upgraded our nginx package to 1.11.1, which includes a new HTTP/2 perf enhancement for POST requests (having a 64K pre-read buffer available initially to the client right away, instead of later in the exchange).

It's not a protocol bugfix or FF workaround on the nginx side, but if this is an FF bug of the nature "it assumes there's body buffer space immediately for a POST body when it's the first transaction of a new HTTP/2 connection, even though there isn't any space advertised by the protocol", then the new nginx pre-read buffer may incidentally work around that bug.

So, please re-test with FF 46.0.1, with HTTP/2 re-enabled if you've already disabled it manually as a workaround.

Also note, whether or not the nginx update helps the situation, this is an acknowledged FF bug, and the best link on their tracker is: https://bugzilla.mozilla.org/show_bug.cgi?id=1269055 . I think this is fixed for 47+, but may not have made the cut for a 46 point release, but people may still be arguing about that.