Closed Bug 912550 Opened 11 years ago Closed 11 years ago

remove spdy/2 support

Categories

(Core :: Networking: HTTP, defect)

20 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla27
Tracking Status
firefox27 --- disabled
firefox28 + verified
relnote-firefox --- 28+

People

(Reporter: mcmanus, Assigned: mcmanus)

References

Details

(Keywords: dev-doc-complete, site-compat)

Attachments

(1 file, 1 obsolete file)

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.
Attached patch remove spdy/2 (obsolete) — Splinter Review
Attachment #799555 - Flags: review?(hurley)
Depends on: 912549
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
Attachment #799555 - Flags: review?(hurley) → review+
Attached patch remove spdy/2Splinter Review
update bitrot. checkin blocked on external factors
Attachment #799555 - Attachment is obsolete: true
Attachment #803159 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/e39d4f589f10
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
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
Target Milestone: mozilla27 → mozilla28
OS: Linux → All
Hardware: x86_64 → All
Target Milestone: mozilla28 → mozilla27
[comment to Relman] - I have recently removed this from our Relnote DB so it does not appear on release notes that will be generated.
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.
Flags: needinfo?(gavin.sharp)
yep!
Flags: needinfo?(gavin.sharp)
If you are going to keep revving spdy, obsoleting server support (such as nginx) can you make standard TLS support NPN?
This seems like something QA will want to keep an eye out for in Firefox 27 and 28. Patrick, can you please advise?
Flags: needinfo?(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.
Flags: needinfo?(mcmanus)
I brushed up on what NPN is and I retract my comment.
(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?
(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.
(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.
Keywords: verifyme
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
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: