912550 - remove spdy/2 support

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Patrick McManus [:mcmanus]]

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

Attachment: remove spdy/2

Comment 2

[u408661]

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

Attachment: remove spdy/2

update bitrot. checkin blocked on external factors

Comment 4

[Patrick McManus [:mcmanus]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e39d4f589f10

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/e39d4f589f10

Comment 6

[Patrick McManus [:mcmanus]]

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

[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]

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: [e-mail]]]

yep!

Comment 10

[Kohei Yoshino]

Added to the site compat doc:
https://developer.mozilla.org/en-US/Firefox/Releases/28/Site_Compatibility

Comment 11

[scientes]

If you are going to keep revving spdy, obsoleting server support (such as nginx) can you make standard TLS support NPN?

Comment 12

[u279076]

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

(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]

I brushed up on what NPN is and I retract my comment.

Comment 15

[u279076]

(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]]

(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

[u279076]

(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 [:avaida]]

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

Comment 19

[halinh]

http://sonhavietnam.vn/

[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