SPDY - disable SPDY based on command line and policy

chrome/browser/net/net_pref_observer.cc

Index: chrome/browser/net/net_pref_observer.cc
===================================================================
--- chrome/browser/net/net_pref_observer.cc	(revision 156023)
+++ chrome/browser/net/net_pref_observer.cc	(working copy)
@@ -47,7 +47,8 @@
   predictor_->EnablePredictor(*network_prediction_enabled_);
   if (prerender_manager_)
     prerender_manager_->set_enabled(*network_prediction_enabled_);
-  net::HttpStreamFactory::set_spdy_enabled(!*spdy_disabled_);
+  if (net::HttpStreamFactory::spdy_enabled())
+    net::HttpStreamFactory::set_spdy_enabled(!*spdy_disabled_);

[mmenke, 2012/09/12 01:31:17]

This removes the ability of modifying the policy value to re-enable SPDY, when
it's disabled by a means other than the command line.

Am I correct that this is already broken, anyways, since we never re-populate
HttpStreamFactory::next_protos_, after deleting it when spdy is disabled?

[ramant (doing other things), 2012/09/12 01:51:52]

Correct. My proposal is for the user to run without the command line option
(--use-spdy=off) for policy to take effect.

As you had mentioned "So disabling takes precedence over enabling, in all
cases".
In http_stream_facttory_impl_job.cc, we don't set _using_spdy to true unless
spdy is enabled (unless a SPDY connection was created before property from prefs
is read. That is cached spdy connections).

Tested the code, if spdy is disabled in policy file, then we don't use SPDY
sessions. 

[mmenke, 2012/09/12 02:02:45]

I was just concerned about the preference being disabled and then enabled. 
Doesn't look like that can happen, unless we reload the policy file if it
changes, and looks like it wouldn't actually enable spdy again anyways (Since
spdy_enabled_ would be true, but next_protos_ would be still be NULL).

 }
 
 // static