proxy_resolving_client_socket.cc currently passes a null ProxyDelegate to ProxyService.
We need to investigate how ProxyDelegate interface looks like in NetworkService and converts proxy_resolving_client_socket.cc to using it.
+reillyg@:
Reilly: Do you have a pointer to the new ProxyDelegate interface?
I am moving jingle/glue/proxy_resolving_client_socket.h to services/network/network/cpp, with the goal of converting it to a mojo interface eventually (so we have a socket interface that does proxy resolution on top of connect).
The current implementation uses a null ProxyDelegate when doing ProxyService::ResolveProxy. mmenke@ told me that passing a null ProxyDelegate is potentially bad, and we should not passing a null ProxyDelegate.
How should I interact with the ProxyDelegate interface that you are currently working on?
ProxyResolvingClientSocket shouldn't implicitly assume that the consumer wants different behavior for it than from any other tunneled socket (Possibly with the exception of marking proxies as bad).
In my current effort there is currently no new ProxyDelegate interface. I am looking at the implementation of the Data Reduction Proxy at a content::ResourceRequest level and so have not been considering any other users of the ProxyService such as ProxyResolvingClientSocket.
Ideally we can get rid of the per-request ProxyDelegate parameter, and instead associate it with the ProxyResolutionService. Not sure if there is a reason it is currently per request.
There is some overlap here with Issue 721403 .
I think it may be per-request because the ProxyResolutionService used to be shared between URLRequestContexts. Of course, that's no longer the case, now.
Comment 1 by xunji...@chromium.org
, Dec 7 2017