Page MenuHomePhabricator

Secure connection failed when attempting to send POST request using HTTP/2 (if connection has been idle for a certain time)
Closed, ResolvedPublic

Description

Reporting from this :EN village pump thread, myself and a couple of other users have been experiencing periodic "Secure connection failed" errors when attempting to preview or save pages.

Seems to be mainly Firefox related, on a number of operating systems.

Personally, I have experienced this on Firefox 46.0.1 on Windows 8.1 Pro

Event Timeline

Samtar created this task.May 10 2016, 12:21 PM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptMay 10 2016, 12:21 PM
Restricted Application added a project: Traffic. · View Herald TranscriptMay 10 2016, 3:18 PM

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...

BBlack added a comment.EditedMay 10 2016, 4:12 PM

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

Samtar added a comment.EditedMay 10 2016, 5:18 PM

@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!

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.

chasemp renamed this task from Secure connection failed to Secure connection failed when attempting to preview or save pages.May 11 2016, 7:34 PM
chasemp triaged this task as High priority.

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.

Elitre added a subscriber: Elitre.May 15 2016, 4:24 PM
Danny_B renamed this task from Secure connection failed when attempting to preview or save pages to Secure connection failed when attempting to send POST request.May 16 2016, 9:18 AM

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

Thibaut120094 awarded a token.EditedMay 20 2016, 3:02 AM
Thibaut120094 added a subscriber: Thibaut120094.

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

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.

Thibaut120094 added a comment.EditedMay 20 2016, 12:22 PM

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)

Elvey added a subscriber: Elvey.May 24 2016, 12:48 AM

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.

Elvey added a comment.May 27 2016, 3:56 PM

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.)

Aklapper renamed this task from Secure connection failed when attempting to send POST request to Secure connection failed when attempting to send POST request (if connection has been idle for a while; disabling HTTP/2 helps).May 31 2016, 10:06 AM
Danny_B renamed this task from Secure connection failed when attempting to send POST request (if connection has been idle for a while; disabling HTTP/2 helps) to Secure connection failed when attempting to send POST request using HTTP/2 (if connection has been idle for a certain time).May 31 2016, 10:11 AM

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.

BBlack closed this task as Resolved.Jul 27 2016, 7:40 PM
BBlack claimed this task.

I think either this has been fixed by FF 47 upgrades, fixed by our nginx upgrades, or both. Closing for now, re-open if it recurs.