Disabled resource scheduling when using a SPDY proxy

content/browser/loader/resource_scheduler.cc

Index: content/browser/loader/resource_scheduler.cc
diff --git a/content/browser/loader/resource_scheduler.cc b/content/browser/loader/resource_scheduler.cc
index d458936ecf1e29110a8a935fbcbcca3ad155f5a6..776610b222f27a6f623f4e6e3a98db3d5fc2a05f 100644
--- a/content/browser/loader/resource_scheduler.cc
+++ b/content/browser/loader/resource_scheduler.cc
@@ -134,10 +134,11 @@ class ResourceScheduler::ScheduledResourceRequest
 
 // Each client represents a tab.
 struct ResourceScheduler::Client {
-  Client() : has_body(false) {}
+  Client() : has_body(false), using_spdy_proxy(false) {}
   ~Client() {}
 
   bool has_body;
+  bool using_spdy_proxy;
   RequestQueue pending_requests;
   RequestSet in_flight_requests;
 };
@@ -193,6 +194,15 @@ void ResourceScheduler::RemoveRequest(ScheduledResourceRequest* request) {
 
   Client* client = client_it->second;
 
+  if (!client->using_spdy_proxy) {
+    net::HttpResponseInfo response_info =
+        request->url_request()->response_info();
+    if (response_info.was_fetched_via_spdy &&
+        response_info.was_fetched_via_proxy) {

[James Simonsen, 2013/12/02 18:59:31]

Is this really the only way to determine it? It seems unfortunate we have to
wait so long. How does the network stack decide to use SPDY proxy? Can we
extract that code instead?

[Pat Meenan, 2013/12/02 19:35:51]

This is the lowest-impact way I could come up with (there's a thread on
chromium-dev with Will Chan and Ryan Sleevi:
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/ziP_vgEQ2AQ
).

The network stack needs to walk through the configured proxies, execute any PAC
scripts and then only after the TLS negotiation with the host is complete do we
know it's actually a SPDY proxy which is way more overhead than we want to do
here.

It isn't quite as bad as it seems.  We can only discover the resources after the
first request starts to come back so the lost opportunity is between the TTFB
and when the base page (or any script or other request) completes at which point
we'd open the flood-gates.  It's a bit conservative but should get most of the
benefit and we can improve it further for some cases if we think it's worthwhile
(like the data reduction proxy).

+      client->using_spdy_proxy = true;
+    }
+  }
+
   if (client->pending_requests.IsQueued(request)) {
     client->pending_requests.Erase(request);
     DCHECK(!ContainsKey(client->in_flight_requests, request));
@@ -245,6 +255,7 @@ void ResourceScheduler::OnNavigate(int child_id, int route_id) {
 
   Client* client = it->second;
   client->has_body = false;
+  client->using_spdy_proxy = false;
 }
 
 void ResourceScheduler::OnWillInsertBody(int child_id, int route_id) {
@@ -355,6 +366,10 @@ bool ResourceScheduler::ShouldStartRequest(ScheduledResourceRequest* request,
     return true;
   }
 
+  if (client->using_spdy_proxy) {
+    return true;
+  }
+
   const net::HttpServerProperties& http_server_properties =
       *url_request.context()->http_server_properties();