remove spdy/2 support

VERIFIED FIXED in Firefox 28

Status

()

Core
Networking: HTTP
VERIFIED FIXED
4 years ago
6 months ago

People

(Reporter: mcmanus, Assigned: mcmanus)

Tracking

({dev-doc-complete, site-compat})

20 Branch
mozilla27
dev-doc-complete, site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox27 disabled, firefox28+ verified, relnote-firefox 28+)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

4 years ago
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.
(Assignee)

Comment 1

4 years ago
Created attachment 799555 [details] [diff] [review]
remove spdy/2
Attachment #799555 - Flags: review?(hurley)
(Assignee)

Updated

4 years ago
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+
(Assignee)

Comment 3

4 years ago
Created attachment 803159 [details] [diff] [review]
remove spdy/2

update bitrot. checkin blocked on external factors
(Assignee)

Updated

4 years ago
Attachment #799555 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Attachment #803159 - Flags: review+
(Assignee)

Comment 4

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/e39d4f589f10
https://hg.mozilla.org/mozilla-central/rev/e39d4f589f10
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Depends on: 922416
relnote-firefox: --- → ?

Updated

4 years ago
relnote-firefox: ? → 27+
(Assignee)

Comment 6

4 years ago
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
relnote-firefox: 27+ → ?
Target Milestone: mozilla27 → mozilla28
status-firefox27: --- → disabled
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.
status-firefox28: --- → fixed
tracking-firefox28: --- → +
Flags: needinfo?(gavin.sharp)
yep!
Flags: needinfo?(gavin.sharp)
Added to the site compat doc:
https://developer.mozilla.org/en-US/Firefox/Releases/28/Site_Compatibility
Keywords: dev-doc-complete, site-compat

Comment 11

4 years ago
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)
(Assignee)

Comment 13

4 years ago
(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)

Comment 14

4 years ago
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?
(Assignee)

Comment 16

4 years ago
(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
relnote-firefox: ? → 28+
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
status-firefox28: fixed → verified
Keywords: verifyme
Comment hidden (spam)
You need to log in before you can comment on or make changes to this bug.