915841 - Twitter users getting connection is reset error on 23

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Matt Grimes [:Matt_G]]

We've seen a dramatic spike in users report connection is reset errors on Twittter today. Seems to be mostly Windows and limited to Firefox 23.

Can we get some QA love?

Comment 1

[Matt Grimes [:Matt_G]]

You can see a fair amount of the chatter by viewing the Army of Awesome queue: https://support.mozilla.org/en-US/army-of-awesome

Comment 2

[Verdi [:verdi] Best to slack me]

Seems to be down for Mac Fx 23 also. I can get Twitter to load in Beta, Aurora and Nightly though.

Comment 3

[Carmen]

Seems to be working again - according to my Windows-using husband. :) Can we confirm so I can send out a message to our @Firefox fans?

Comment 4

[Verdi [:verdi] Best to slack me]

(In reply to Carmen from comment #3)
> Seems to be working again - according to my Windows-using husband. :) Can we
> confirm so I can send out a message to our @Firefox fans?

Yes it does seem to be working again.

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Carmen from comment #3)
> Seems to be working again - according to my Windows-using husband. :) Can we
> confirm so I can send out a message to our @Firefox fans?

A release-driver says a thread on Facebook pointed out that a Twitter deploy was backed out and tweets coming in confirm this.

Comment 6

[Jeff Pinner]

After negotiating a SPDY/3 connection, Firefox now sends a settings frame with a SETTINGS_MAX_CONCURRENT_STREAMS value of 0. This behavior was introduced sometime after Firefox 19. While there has been discussion in the HTTP/2 working group of making this setting apply to remote-initiated streams, that language is not in the SPDY/3 specification:

"SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote endpoint the maximum number of concurrent streams which it will allow. By default there is no limit. For implementors it is recommended that this value be no smaller than 100."

Comment 7

[Patrick McManus [:mcmanus]]

I'm going to close this bug because twitter patched their service and its not an issue. We can continue the protocol discussion though.

(In reply to Jeff Pinner from comment #6)
> "SETTINGS_MAX_CONCURRENT_STREAMS allows the sender to inform the remote
> endpoint the maximum number of concurrent streams which it will allow. By
> default there is no limit. For implementors it is recommended that this
> value be no smaller than 100."

So that's always been clear enough to me what it means - "sender" and "remote" are relative terms. Its true that this was clarified explicitly after spdy/3 was stabilized. The most confusing part is probably "concurrent streams it will allow" - which has been clarified to mean "concurrent streams it will allow to be initiated by the remote endpoint".

We use it to disable spdy push in some versions of firefox (i.e. firefox is the sender and it is informing the remote endpoint (the server) that it will allow 0 streams to be pushed)- and jetty and mod_spdy respect that. If we didn't have that logic those servers would push us resources we need to reset - wasting bandwidth.

if firefox >=24 we have implemented push so we don't send that setting anymore (we want push).. at least with the default config.

AFAIU the twitter implementation interpreted it to mean something along the lines of "concurrent streams allowed in either direction", which would mean firefox was asking for a session without any client initiated streams either.

If it helps - we don't ever set it to anything other than 0 (or omitted) in any release.