Make URLRequestContextBuilderV8 Mojo-only.

Make URLRequestContextBuilderV8 Mojo-only.

This will let us use an in-process Mojo resolver on Android, making
the transition to using a network service easier. Network service will
have the same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only difference is it will create
in-process ProxyResolvers, instead of ProxyResolvers in a utility
process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

BUG=715695
Review-Url: https://codereview.chromium.org/2919423002
Cr-Commit-Position: refs/heads/master@{#478071}
Committed: https://chromium.googlesource.com/chromium/src/+/e2ad99246ebaa3e6b0a037907a21ea6c692de4ab

[mmenke, 2017-06-05 19:32:26]

The CQ bit was checked by mmenke@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-05 19:32:55]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-05 19:54:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-05 19:54:18]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[mmenke, 2017-06-07 17:22:08]

The CQ bit was checked by mmenke@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-07 17:22:33]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-07 17:26:47]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-07 17:26:48]

Dry run: Try jobs failed on following builders:
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[mmenke, 2017-06-07 17:58:13]

The CQ bit was checked by mmenke@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-07 17:58:42]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-07 18:02:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-07 18:02:51]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)

[mmenke, 2017-06-07 19:05:05]

The CQ bit was checked by mmenke@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-07 19:05:41]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mmenke, 2017-06-07 19:14:55]

Description was changed from

==========
Use URLRequestContextBuilder to create system request context.

Use defaults where possible.

Also fix URLRequestContextBuilder so that some ProxyService
options are now applied regardless of the tyoe of ProxyService
created, and make DhcpProxyScriptFetcherFactory have virtual
methods, so we can create a ChromeOS subclass of it.

BUG=715695
==========

to

==========
Make URLRequestContextBuilderV8 Mojo-only.

This allows us to use an in-process Mojo resolver on Android, making
the transition to using a network service easier (NetworkService will
havet he same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only it will create in-process
ProxyResolvers, instead of ProxyResolvers in a utility process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

BUG=715695
==========

[mmenke, 2017-06-07 19:18:09]

Description was changed from

==========
Make URLRequestContextBuilderV8 Mojo-only.

This allows us to use an in-process Mojo resolver on Android, making
the transition to using a network service easier (NetworkService will
havet he same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only it will create in-process
ProxyResolvers, instead of ProxyResolvers in a utility process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

BUG=715695
==========

to

==========
Make URLRequestContextBuilderV8 Mojo-only.

This will let us use an in-process Mojo resolver on Android, making
the transition to using a network service easier. Network service will
have he same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only difference is it will create
in-process ProxyResolvers, instead of ProxyResolvers in a utility
process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

BUG=715695
==========

[mmenke, 2017-06-07 19:18:37]

mmenke@chromium.org changed reviewers:
+ eroman@chromium.org

[mmenke, 2017-06-07 19:18:39]

https://codereview.chromium.org/2919423002/diff/60001/chrome/utility/BUILD.gn
File chrome/utility/BUILD.gn (right):

https://codereview.chromium.org/2919423002/diff/60001/chrome/utility/BUILD.gn...
chrome/utility/BUILD.gn:53: "//net:net_utility_services",
This isn't a real dependency, but gn --check doesn't handle platform #ifdefs
properly, and now that we have a "net:net_utility_services" on Android, gn
--check doesn't like including files from it (even protected by #ifdefs) without
depending on the target.

See https://crbug.com/730719

[eroman, 2017-06-07 19:46:15]

What is your end-goal with the network servicification in terms of process
organization? Will the v8-based PAC runner be its own process? Its own service?
What interface will it use.

[mmenke, 2017-06-07 19:57:39]

On 2017/06/07 19:46:15, eroman wrote:
> What is your end-goal with the network servicification in terms of process
> organization? Will the v8-based PAC runner be its own process? Its own
service?
> What interface will it use.

My current thinking is that during NetworkService setup, we'll pass in a
V8-based MojoProxyResolver Mojo proxy runner.  This lets the NetworkService
itself not depend on v8, which is potentially quite large, and also means it
won't need to be able to create its own processes, from a sandboxing
perspective.  On Android, we'll just pass in a pointer that can run PACs
in-process, and elsewhere, we'll grab what we need from utility_services.  This
will need to be done before first use.  I'm not sure where the code to do this
will live (it could be in chrome/utility, or in a more IOThread-y type location
/ wherever we tell the NetworkService to create the URLRequestContexts).  We
could also do it on a per-URLRequestContext creation basis, but I don't think we
get anything from that, unless we want to isolate the PAC processes on a
per-profile basis, which I don't think we care about.

[mmenke, 2017-06-07 19:58:36]

On 2017/06/07 19:57:39, mmenke wrote:
> On 2017/06/07 19:46:15, eroman wrote:
> > What is your end-goal with the network servicification in terms of process
> > organization? Will the v8-based PAC runner be its own process? Its own
> service?
> > What interface will it use.
> 
> My current thinking is that during NetworkService setup, we'll pass in a
> V8-based MojoProxyResolver Mojo proxy runner.  This lets the NetworkService
> itself not depend on v8, which is potentially quite large, and also means it
> won't need to be able to create its own processes, from a sandboxing
> perspective.  On Android, we'll just pass in a pointer that can run PACs
> in-process, and elsewhere, we'll grab what we need from utility_services. 
This
> will need to be done before first use.  I'm not sure where the code to do this
> will live (it could be in chrome/utility, or in a more IOThread-y type
location
> / wherever we tell the NetworkService to create the URLRequestContexts).  We
> could also do it on a per-URLRequestContext creation basis, but I don't think
we
> get anything from that, unless we want to isolate the PAC processes on a
> per-profile basis, which I don't think we care about.

And if we pass in no mojo PAC resolver, it will try and use the system one
(Hence the remove of use_v8)

[mmenke, 2017-06-07 20:00:13]

On 2017/06/07 19:58:36, mmenke wrote:
> On 2017/06/07 19:57:39, mmenke wrote:
> > On 2017/06/07 19:46:15, eroman wrote:
> > > What is your end-goal with the network servicification in terms of process
> > > organization? Will the v8-based PAC runner be its own process? Its own
> > service?
> > > What interface will it use.
> > 
> > My current thinking is that during NetworkService setup, we'll pass in a
> > V8-based MojoProxyResolver Mojo proxy runner.  This lets the NetworkService
> > itself not depend on v8, which is potentially quite large, and also means it
> > won't need to be able to create its own processes, from a sandboxing
> > perspective.  On Android, we'll just pass in a pointer that can run PACs
> > in-process, and elsewhere, we'll grab what we need from utility_services. 
> This
> > will need to be done before first use.  I'm not sure where the code to do
this
> > will live (it could be in chrome/utility, or in a more IOThread-y type
> location
> > / wherever we tell the NetworkService to create the URLRequestContexts).  We
> > could also do it on a per-URLRequestContext creation basis, but I don't
think
> we
> > get anything from that, unless we want to isolate the PAC processes on a
> > per-profile basis, which I don't think we care about.
> 
> And if we pass in no mojo PAC resolver, it will try and use the system one
> (Hence the remove of use_v8)

Also note that doing all that may be a month or two off - I'm working on getting
IOThread / ProfileIOData onto using URLRequestContextBuilder, first.  Ideally
all using the same setup code, which can then be shared with the network
process.

[mmenke, 2017-06-07 20:07:04]

On 2017/06/07 20:00:13, mmenke wrote:
> On 2017/06/07 19:58:36, mmenke wrote:
> > On 2017/06/07 19:57:39, mmenke wrote:
> > > On 2017/06/07 19:46:15, eroman wrote:
> > > > What is your end-goal with the network servicification in terms of
process
> > > > organization? Will the v8-based PAC runner be its own process? Its own
> > > service?
> > > > What interface will it use.
> > > 
> > > My current thinking is that during NetworkService setup, we'll pass in a
> > > V8-based MojoProxyResolver Mojo proxy runner.  This lets the
NetworkService
> > > itself not depend on v8, which is potentially quite large, and also means
it
> > > won't need to be able to create its own processes, from a sandboxing
> > > perspective.  On Android, we'll just pass in a pointer that can run PACs
> > > in-process, and elsewhere, we'll grab what we need from utility_services. 
> > This
> > > will need to be done before first use.  I'm not sure where the code to do
> this
> > > will live (it could be in chrome/utility, or in a more IOThread-y type
> > location
> > > / wherever we tell the NetworkService to create the URLRequestContexts). 
We
> > > could also do it on a per-URLRequestContext creation basis, but I don't
> think
> > we
> > > get anything from that, unless we want to isolate the PAC processes on a
> > > per-profile basis, which I don't think we care about.
> > 
> > And if we pass in no mojo PAC resolver, it will try and use the system one
> > (Hence the remove of use_v8)
> 
> Also note that doing all that may be a month or two off - I'm working on
getting
> IOThread / ProfileIOData onto using URLRequestContextBuilder, first.  Ideally
> all using the same setup code, which can then be shared with the network
> process.

And final comment:  Decided to take this approach instead of the old one because
the old one would have required the NetworkService to depend on v8 on all
platforms, despite only needing the dependency on Android.  And the
NetworkService should provide the same API on all platforms (Not even sure if
mojom supports ifdefs), and the old code approach provide the same mojom files
on Android.

[mmenke, 2017-06-07 20:09:16]

On 2017/06/07 20:07:04, mmenke wrote:
> On 2017/06/07 20:00:13, mmenke wrote:
> > On 2017/06/07 19:58:36, mmenke wrote:
> > > On 2017/06/07 19:57:39, mmenke wrote:
> > > > On 2017/06/07 19:46:15, eroman wrote:
> > > > > What is your end-goal with the network servicification in terms of
> process
> > > > > organization? Will the v8-based PAC runner be its own process? Its own
> > > > service?
> > > > > What interface will it use.
> > > > 
> > > > My current thinking is that during NetworkService setup, we'll pass in a
> > > > V8-based MojoProxyResolver Mojo proxy runner.  This lets the
> NetworkService
> > > > itself not depend on v8, which is potentially quite large, and also
means
> it
> > > > won't need to be able to create its own processes, from a sandboxing
> > > > perspective.  On Android, we'll just pass in a pointer that can run PACs
> > > > in-process, and elsewhere, we'll grab what we need from
utility_services. 
> > > This
> > > > will need to be done before first use.  I'm not sure where the code to
do
> > this
> > > > will live (it could be in chrome/utility, or in a more IOThread-y type
> > > location
> > > > / wherever we tell the NetworkService to create the URLRequestContexts).

> We
> > > > could also do it on a per-URLRequestContext creation basis, but I don't
> > think
> > > we
> > > > get anything from that, unless we want to isolate the PAC processes on a
> > > > per-profile basis, which I don't think we care about.
> > > 
> > > And if we pass in no mojo PAC resolver, it will try and use the system one
> > > (Hence the remove of use_v8)
> > 
> > Also note that doing all that may be a month or two off - I'm working on
> getting
> > IOThread / ProfileIOData onto using URLRequestContextBuilder, first. 
Ideally
> > all using the same setup code, which can then be shared with the network
> > process.
> 
> And final comment:  Decided to take this approach instead of the old one
because
> the old one would have required the NetworkService to depend on v8 on all
> platforms, despite only needing the dependency on Android.  And the
> NetworkService should provide the same API on all platforms (Not even sure if
> mojom supports ifdefs), and the old code approach provide the same mojom files
> on Android.

Erm...the approach of the old code did *not* provide.  (Yes, I like talking to
myself)

[commit-bot: I haz the power, 2017-06-07 21:12:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-07 21:12:57]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[eroman, 2017-06-08 00:45:56]

So just to be clear on some details:

Android Chrome browser uses V8-based PAC evaluator. However neither WebView nor
cronet do.

We don't have a system proxy resolver implementation for Android, so they are
basically broken when it comes to PAC. At the proxy config service level, we do
get the PAC URL (assuming Android isn't so old that it doesn't have that
concept), however can't actually do anything with it.

There is a kludge on Android, where the system can provide an 
 HTTP proxy that then applies the PAC results, so this sometimes works (however
only if you are using the system proxy settings -- if you wanted to override
wouldn't work)

The fallback system ProxyResolver for mac and windows can interpret PAC, however
have problems.

So effectively from a layering perspective, if you expect to have control over
setting PAC based proxy settings, can only guarantee it will work if you are
running with the v8 proxy resolver.

https://codereview.chromium.org/2919423002/diff/60001/net/url_request/url_req...
File net/url_request/url_request_context_builder.cc (right):

https://codereview.chromium.org/2919423002/diff/60001/net/url_request/url_req...
net/url_request/url_request_context_builder.cc:333: if (!ssl_config_service_) {
These changes seem unrelated.

https://codereview.chromium.org/2919423002/diff/60001/net/url_request/url_req...
File net/url_request/url_request_context_builder.h (right):

https://codereview.chromium.org/2919423002/diff/60001/net/url_request/url_req...
net/url_request/url_request_context_builder.h:125: // Sets policy for sanitizing
URLs before passing them a PAC. Defaults to
them a PAC --> them to a PAC

[eroman, 2017-06-08 00:47:16]

note - test failures on android

[mmenke, 2017-06-08 16:35:45]

The CQ bit was checked by mmenke@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-06-08 16:36:00]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[mmenke, 2017-06-08 16:36:29]

Thanks!  Everything should be working, now.  *grumble*...Weird globals needing
to be initialized...*grumble*.

https://codereview.chromium.org/2919423002/diff/60001/net/url_request/url_req...
File net/url_request/url_request_context_builder.cc (right):

https://codereview.chromium.org/2919423002/diff/60001/net/url_request/url_req...
net/url_request/url_request_context_builder.cc:333: if (!ssl_config_service_) {
On 2017/06/08 00:45:56, eroman wrote:
> These changes seem unrelated.

Thanks!  Reverted this change (Kept the quick_check_enabled/sanitize_url_policy
changes).  Initially did a lot more in one CL, realized it was way too big, and
split it up, but forgot to remove this part of it.

https://codereview.chromium.org/2919423002/diff/60001/net/url_request/url_req...
File net/url_request/url_request_context_builder.h (right):

https://codereview.chromium.org/2919423002/diff/60001/net/url_request/url_req...
net/url_request/url_request_context_builder.h:125: // Sets policy for sanitizing
URLs before passing them a PAC. Defaults to
On 2017/06/08 00:45:56, eroman wrote:
> them a PAC --> them to a PAC

Done.

[commit-bot: I haz the power, 2017-06-08 18:02:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-06-08 18:02:29]

Dry run: This issue passed the CQ dry run.

[mmenke, 2017-06-08 18:05:07]

On 2017/06/08 00:45:56, eroman wrote:
> So just to be clear on some details:
> 
> Android Chrome browser uses V8-based PAC evaluator. However neither WebView
nor
> cronet do.
> 
> We don't have a system proxy resolver implementation for Android, so they are
> basically broken when it comes to PAC. At the proxy config service level, we
do
> get the PAC URL (assuming Android isn't so old that it doesn't have that
> concept), however can't actually do anything with it.
> 
> There is a kludge on Android, where the system can provide an 
>  HTTP proxy that then applies the PAC results, so this sometimes works
(however
> only if you are using the system proxy settings -- if you wanted to override
> wouldn't work)
> 
> The fallback system ProxyResolver for mac and windows can interpret PAC,
however
> have problems.
> 
> So effectively from a layering perspective, if you expect to have control over
> setting PAC based proxy settings, can only guarantee it will work if you are
> running with the v8 proxy resolver.

Also, thanks for this information - I hadn't realized we didn't run PACs on
Android WebView, so will probably need to keep at least some of the
NetworkService setup logic in chrome/.  :(

[eroman, 2017-06-08 19:48:46]

lgtm

[mmenke, 2017-06-08 19:55:24]

mmenke@chromium.org changed reviewers:
+ thestig@chromium.org

[mmenke, 2017-06-08 19:55:24]

[+thestig]:  TBRing you for a change to
chrome/utility/chrome_content_utility_client.cc (Adding "nogncheck" to a line,
since we now have a target on Android containing
net/proxy/mojo_proxy_resolver_factory_impl.h, but chrome/utility/ does and and
will not use it, since we'll be using it in-process).  This seems TBRable to me,
since this is working around a gn bug and not modifying any code or even
reworking dependencies.

[mmenke, 2017-06-08 20:17:22]

Description was changed from

==========
Make URLRequestContextBuilderV8 Mojo-only.

This will let us use an in-process Mojo resolver on Android, making
the transition to using a network service easier. Network service will
have he same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only difference is it will create
in-process ProxyResolvers, instead of ProxyResolvers in a utility
process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

BUG=715695
==========

to

==========
Make URLRequestContextBuilderV8 Mojo-only.

This will let us use an in-process Mojo resolver on Android, making
the transition to using a network service easier. Network service will
have he same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only difference is it will create
in-process ProxyResolvers, instead of ProxyResolvers in a utility
process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

TBR=thestig@chromium.org
BUG=715695
==========

[Lei Zhang, 2017-06-08 20:18:33]

lgtm

BTW s/ he/ the/ in the commit msg.

[mmenke, 2017-06-08 20:20:54]

Description was changed from

==========
Make URLRequestContextBuilderV8 Mojo-only.

This will let us use an in-process Mojo resolver on Android, making
the transition to using a network service easier. Network service will
have he same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only difference is it will create
in-process ProxyResolvers, instead of ProxyResolvers in a utility
process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

TBR=thestig@chromium.org
BUG=715695
==========

to

==========
Make URLRequestContextBuilderV8 Mojo-only.

This will let us use an in-process Mojo resolver on Android, making
the transition to using a network service easier. Network service will
have the same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only difference is it will create
in-process ProxyResolvers, instead of ProxyResolvers in a utility
process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

BUG=715695
==========

[mmenke, 2017-06-08 20:21:20]

On 2017/06/08 20:18:33, Lei Zhang wrote:
> lgtm
> 
> BTW s/ he/ the/ in the commit msg.

Fixed, thanks!

[mmenke, 2017-06-08 20:21:31]

The CQ bit was checked by mmenke@chromium.org

[commit-bot: I haz the power, 2017-06-08 20:22:12]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-06-08 20:27:40]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1496953291665930,
"parent_rev": "d7887d9cb29d090b72fbecc5b260ae68b09ce27e", "commit_rev":
"e2ad99246ebaa3e6b0a037907a21ea6c692de4ab"}

[commit-bot: I haz the power, 2017-06-08 20:27:59]

Description was changed from

==========
Make URLRequestContextBuilderV8 Mojo-only.

This will let us use an in-process Mojo resolver on Android, making
the transition to using a network service easier. Network service will
have the same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only difference is it will create
in-process ProxyResolvers, instead of ProxyResolvers in a utility
process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

BUG=715695
==========

to

==========
Make URLRequestContextBuilderV8 Mojo-only.

This will let us use an in-process Mojo resolver on Android, making
the transition to using a network service easier. Network service will
have the same Mojo interface on Android, even if it's running in
process, and will be passed a Mojo ProxyResolverFactory there as well,
just as on other platforms. Only difference is it will create
in-process ProxyResolvers, instead of ProxyResolvers in a utility
process.

Also move some proxy settings from URLRequestContextBuilderV8 to
URLRequestContextBuilder.

BUG=715695

Review-Url: https://codereview.chromium.org/2919423002
Cr-Commit-Position: refs/heads/master@{#478071}
Committed:
https://chromium.googlesource.com/chromium/src/+/e2ad99246ebaa3e6b0a037907a21...
==========

[commit-bot: I haz the power, 2017-06-08 20:27:59]

Committed patchset #5 (id:80001) as
https://chromium.googlesource.com/chromium/src/+/e2ad99246ebaa3e6b0a037907a21...