Change Interceptors into URLRequestJobFactory::ProtocolHandlers.

chrome/browser/net/connect_interceptor.cc

Index: chrome/browser/net/connect_interceptor.cc
diff --git a/chrome/browser/net/connect_interceptor.cc b/chrome/browser/net/connect_interceptor.cc
index c1d6deac19b66137cd1179dc5153e8147e91c9de..16b3ed232422802d5a557b1f48372631f23489d3 100644
--- a/chrome/browser/net/connect_interceptor.cc
+++ b/chrome/browser/net/connect_interceptor.cc
@@ -6,6 +6,7 @@
 
 #include "chrome/browser/net/predictor.h"
 #include "net/base/load_flags.h"
+#include "net/url_request/protocol_intercept_job_factory.h"
 #include "net/url_request/url_request.h"
 
 namespace chrome_browser_net {
@@ -17,6 +18,17 @@ namespace chrome_browser_net {
 // TODO(jar): We should do a persistent field trial to validate/optimize this.
 static const int kMaxUnusedSocketLifetimeSecondsWithoutAGet = 10;
 
+// static
+scoped_ptr<net::URLRequestJobFactory>
+ConnectInterceptor::CreateURLRequestJobFactory(
+    scoped_ptr<net::URLRequestJobFactory> base_job_factory,
+    Predictor* predictor) {
+  scoped_ptr<net::URLRequestJobFactory> top_job_factory(
+      new net::ProtocolInterceptJobFactory(base_job_factory.Pass(),
+          new ConnectInterceptor(predictor)));
+  return top_job_factory.Pass();
+}
+
 ConnectInterceptor::ConnectInterceptor(Predictor* predictor)
     : timed_cache_(base::TimeDelta::FromSeconds(
           kMaxUnusedSocketLifetimeSecondsWithoutAGet)),
@@ -27,7 +39,7 @@ ConnectInterceptor::ConnectInterceptor(Predictor* predictor)
 ConnectInterceptor::~ConnectInterceptor() {
 }
 
-net::URLRequestJob* ConnectInterceptor::MaybeIntercept(
+net::URLRequestJob* ConnectInterceptor::MaybeCreateJob(

[willchan no longer on Chromium, 2012/12/11 19:14:38]

No, this ConnectInterceptor is all wrong :) When cleaning it up we should Do It
Right (TM) :P

If you look at this function, you'll see it *always* returns NULL. The purpose
of this interceptor is to *observe*, not to create jobs. In other words, it's
abusing the interceptor interface. Rather than reworking it into a
URLRequestJobFactory, we should use the ChromeNetworkDelegate instead.

[pauljensen, 2012/12/11 22:28:14]

Right now the ConnectionInterceptor is installed into the
URLRequestJobFactoryImpl for the extension_context (and most other contexts) but
the ChromeNetworkDelegate is not installed in the extension_context.
The ConnectionInterceptor is part of the whole predictor framework so I assume
it's most important that it watches URLs going through the main_context but I
don't know if this difference with the extension_context matters.  The comment
by GetRequestContextForExtensions() says "This is only used for a separate
cookie store currently." making me think this isn't a big deal.  Do you guys
think it should be okay to move ConnectionInterceptor into ChromeNetworkDelegate
and not worry about this difference?  There are other alternatives.

[mmenke, 2012/12/13 16:12:04]

I think that's fine for now, though should be done in another CL  (Which is what
I assume you were thinking anyways, as you removed the files from this one).

[pauljensen, 2012/12/13 17:53:30]

Sorry, I'm confused.
What is fine for now? Moving ConnectionInterceptor to the ChromeNetworkDelegate
in another CL and not worrying about the fact that it's not connected to the
extension_context?
What files did I remove from this one?

[willchan no longer on Chromium, 2012/12/13 17:59:53]

So, long-term we need to start refactoring ChromeNetworkDelegate. We've kinda
overloaded it now. It's shared by the "system" URLRequestContext, the profiles'
main & app URLRequestContexts, but not the extension one. What we want to do is
probably use composition here to share behavior across different NetworkDelegate
implementations.

But I didn't answer your question yet. AIUI, the extension context is purely for
the chrome-extension:// to override the CookieStore. So it's not a big deal not
to let ConnectionInterceptor hook it. Long-term, I imagine the CookieStore being
part of the dependencies passed directly into a ProtocolHandler, so there won't
be a need to create a whole new URLRequestContext just for extensions.

Make sense? If people agree, can y'all file bugs? Don't need to sign up to
tackle it yourselves unless you'd like to. I have some other folks who may be
interested, but you're doing such a great job here I'd rather you continue to
kick ass and take names :)

I defer to the main reviewers about whether or not such work would make sense to
be done in this CL or another.

[pauljensen, 2012/12/13 18:21:54]

If I move ConnectionInterceptor into the ChromeNetworkDelegate in this CL I can
yank out all my changes to pass around the URLRequestJobFactories through
SetupJobFactory() and SetupJobFactoryDefaults().  Just sayin' :)  I'll also
defer to the main reviewers to make the call.

     net::URLRequest* request, net::NetworkDelegate* network_delegate) const {
   GURL request_scheme_host(Predictor::CanonicalizeUrl(request->url()));
   if (request_scheme_host == GURL::EmptyGURL())
@@ -87,18 +99,6 @@ net::URLRequestJob* ConnectInterceptor::MaybeIntercept(
   return NULL;
 }
 
-net::URLRequestJob* ConnectInterceptor::MaybeInterceptResponse(
-    net::URLRequest* request, net::NetworkDelegate* network_delegate) const {
-  return NULL;
-}
-
-net::URLRequestJob* ConnectInterceptor::MaybeInterceptRedirect(
-    const GURL& location,
-    net::URLRequest* request,
-    net::NetworkDelegate* network_delegate) const {
-  return NULL;
-}
-
 ConnectInterceptor::TimedCache::TimedCache(const base::TimeDelta& max_duration)
     : mru_cache_(UrlMruTimedCache::NO_AUTO_EVICT),
       max_duration_(max_duration) {