Last Comment Bug 912550 - remove spdy/2 support
: remove spdy/2 support
Status: VERIFIED FIXED
: dev-doc-complete, site-compat
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: 20 Branch
: All All
: -- normal (vote)
: mozilla27
Assigned To: Patrick McManus [:mcmanus]
:
:
Mentors:
Depends on: 912549 922416
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-04 09:00 PDT by Patrick McManus [:mcmanus]
Modified: 2014-03-05 05:04 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
disabled
+
verified
28+


Attachments
remove spdy/2 (133.27 KB, patch)
2013-09-04 09:03 PDT, Patrick McManus [:mcmanus]
hurley: review+
Details | Diff | Splinter Review
remove spdy/2 (133.20 KB, patch)
2013-09-11 11:05 PDT, Patrick McManus [:mcmanus]
mcmanus: review+
Details | Diff | Splinter Review

Description Patrick McManus [:mcmanus] 2013-09-04 09:00:05 PDT
The spdy trains are moving forward. We should implement spdy/3.1 and remove spdy/2 (this patch does the latter). That will leave us with spdy/3 and spdy/3.1 support. It is important to do that so that these experimental protocols can be learned from, but do not become defacto non standard protocols entrenched on the Internet.

Servers without spdy/3 will just negotiate to http/1 without any penalty.
Comment 1 Patrick McManus [:mcmanus] 2013-09-04 09:03:00 PDT
Created attachment 799555 [details] [diff] [review]
remove spdy/2
Comment 2 Nicholas Hurley [:nwgh][:hurley] 2013-09-10 16:07:42 PDT
Comment on attachment 799555 [details] [diff] [review]
remove spdy/2

Review of attachment 799555 [details] [diff] [review]:
-----------------------------------------------------------------

I love the glorious sound of the spdy train leaving the station. r=me
Comment 3 Patrick McManus [:mcmanus] 2013-09-11 11:05:34 PDT
Created attachment 803159 [details] [diff] [review]
remove spdy/2

update bitrot. checkin blocked on external factors
Comment 4 Patrick McManus [:mcmanus] 2013-09-27 10:56:42 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/e39d4f589f10
Comment 5 Wes Kocher (:KWierso) 2013-09-27 19:18:34 PDT
https://hg.mozilla.org/mozilla-central/rev/e39d4f589f10
Comment 6 Patrick McManus [:mcmanus] 2013-11-11 06:03:23 PST
based on some vendor discussions with both servers and chrome, I want to delay this by a six week cycle to give folks a slightly longer chance to update server side support. Chrome intends to also slip it by 1 release to coordinate.

So I'll back it out of aurora and make it effective with FF 28.

That means FF 27 will support 3.1, 3, and 2.

remote:   https://hg.mozilla.org/releases/mozilla-aurora/rev/856ca571aa89
Comment 7 bhavana bajaj [:bajaj] 2013-12-05 10:24:59 PST
[comment to Relman] - I have recently removed this from our Relnote DB so it does not appear on release notes that will be generated.
Comment 8 Lukas Blakk [:lsblakk] use ?needinfo 2013-12-05 14:52:44 PST
Marking this fixed on 28 (and tracking) - if I'm reading this right we'll want to put this in our Aurora notes next week.
Comment 9 :Gavin Sharp [email: gavin@gavinsharp.com] 2013-12-05 14:55:35 PST
yep!
Comment 10 Kohei Yoshino [:kohei] 2013-12-10 21:34:54 PST
Added to the site compat doc:
https://developer.mozilla.org/en-US/Firefox/Releases/28/Site_Compatibility
Comment 11 scientes 2013-12-17 17:55:15 PST
If you are going to keep revving spdy, obsoleting server support (such as nginx) can you make standard TLS support NPN?
Comment 12 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-12-19 14:23:55 PST
This seems like something QA will want to keep an eye out for in Firefox 27 and 28. Patrick, can you please advise?
Comment 13 Patrick McManus [:mcmanus] 2013-12-19 14:30:26 PST
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12)

> and 28. Patrick, can you please advise?

one word: plastics.

but seriously, what info do you need? HTTP/1 should just be negotiated with the servers that are only speaking spdy/2.
Comment 14 scientes 2013-12-19 14:50:34 PST
I brushed up on what NPN is and I retract my comment.
Comment 15 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-12-19 15:34:36 PST
(In reply to Patrick McManus [:mcmanus] from comment #13)
> (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #12)
> 
> > and 28. Patrick, can you please advise?
> 
> one word: plastics.
> 
> but seriously, what info do you need?

Do we know of any sites that were/are using spdy/2? Is there something we can set up internally to test known good and bad server configurations? Is there any behaviour we should look for that is indicative of a regression from this bug?
Comment 16 Patrick McManus [:mcmanus] 2013-12-20 07:01:06 PST
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #15)

> Do we know of any sites that were/are using spdy/2? 

sure - nginx based sites with spdy are currently using spdy/2. They are working on updating their support now. https://wordpress.com is an example.

> Is there something we
> can set up internally to test known good and bad server configurations?

I'm not sure what you consider good and bad here. We're dropping support for a pre-standards protocol, and have added support for another one (spdy/3.1) using the defined negotiation mechanism. That's the normal march of progress.

> Is
> there any behaviour we should look for that is indicative of a regression
> from this bug?

Sites could theoretically:
 1] not offer http/1 as a backup. But realistically they aren't doing that because they wouldn't work with IE right now if they did so (there is no flavor of IE that speaks spdy/2). This would create site unreachable errors.

 2] be doing some kind of UA detection and assuming spdy/2 based on that. As with all sniffing problems, it could manifest itself in whatever crazy way their sniffing logic wanted. The motivations for this are fairly limited (perhaps to change their sharding rules), and the penalties fairly mild (it would operate less efficiently). These things probably become evangelism cases. We've seen one case of this in pre-release 922416.
Comment 17 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2013-12-20 11:20:19 PST
(In reply to Patrick McManus [:mcmanus] from comment #16)
> sure - nginx based sites with spdy are currently using spdy/2. They are
> working on updating their support now. https://wordpress.com is an example.

So in other words doing some top-site testing to ensure nothing is obviously broken. In addition to wordpress.com I managed to get a list from the Nginx Community page: Netflix, Hulu, Pinterest, CloudFlare, Airbnb, WordPress.com, GitHub, SoundCloud, Zynga, Eventbrite, Zappos, Media Temple, Heroku, RightScale, Engine Yard and NetDNA. This is probably a good place to start. 

Would you agree?

> I'm not sure what you consider good and bad here. We're dropping support for
> a pre-standards protocol, and have added support for another one (spdy/3.1)
> using the defined negotiation mechanism. That's the normal march of progress.

I'm trying to avoid a similar situation to what happened when we pushed out OCSP and didn't gracefully handle misconfigured CDNs.
Comment 18 Andrei Vaida, QA [:avaida] – please ni? me 2014-03-05 05:04:09 PST
This issue was verified fixed on the latest Beta (Build ID: 20140303165517), using nginx based websites (Comment 17) and alexa's top 25 sites, on each the following platforms:
- Windows 7 64-bit [1],
- Windows 8.1 64-bit [2],
- Ubuntu 13.10 32-bit [3],
- Mac OS X 10.9.1 [4].


[1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
[2] Mozilla/5.0 (Windows NT 6.3; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0
[3] Mozilla/5.0 (X11; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0
[4] Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0

Note You need to log in before you can comment on or make changes to this bug.