Fix for issue 439560: connect to TURN servers through proxies with auth.

Fix for issue 439560: connect to TURN servers through proxies with auth.

Use the network session from the request context rather than creating a
new one. This means jingle connections get the auth cache etc. and can
therefore use proxies that require authentication to connect to TURN
servers.

Also add myself to the AUTHORS file as requsted in the guidelines
for contributing code.

I can't see any obvious reason why jingle would not use the same network session here and there were no comments entered to explain why this was the case, but I have little experience of the chromium codebase.

BUG=439560

[dbkr, 2014-12-05 20:46:52]

davidbaker992@gmail.com changed reviewers:
+ jiayl@chromium.org

[dbkr, 2014-12-08 14:20:20]

The CQ bit was checked by davidbaker992@gmail.com

[dbkr, 2014-12-08 14:20:21]

The CQ bit was unchecked by davidbaker992@gmail.com

[dbkr, 2014-12-08 14:21:58]

Patchset #1 (id:1) has been deleted

[jiayl, 2014-12-08 19:11:47]

jiayl@chromium.org changed reviewers:
+ rsleevi@chromium.org

[jiayl, 2014-12-08 19:11:47]

This is similar to the early patches in
https://codereview.chromium.org/414523005/, which were turned down by the
network people.

Ryan is looking into a way to solve this from the net/ layer.

[Ryan Sleevi, 2014-12-09 15:39:29]

Yeah, gonna Not LGTM this, unfortunately.

The issue here is that sharing the network session shares the socket pools, and
sharing the socket pools creates the potential for jingle-initiated sockets to
be used with Chrome-initiated sockets.

The Chrome-initiated sockets (Blink-initiated sockets?) have interactive user
contexts, extensions, and a variety of other things that can affect how a socket
is established. Jingle lacks all of these.

The short story is that any time you're establishing a socket outside the scope
of the full UI context and ResourceLoader layer, then you shouldn't be using the
HttpNetworkSession or its members.

This is why Jingle (and all other subcomponents that aren't part of the Resource
Loader flow) initialize their own network sessions.

So I think we'll have to continue on the bug, and more work is needed (e.g. to
either wire up Jingle connections through the appropriate layers, simultaneously
solving the pool connection limits) or to work on better support for proxies in
the Jingle layers (wiring up UI?)

[dbkr, 2014-12-09 16:06:43]

On 2014/12/09 15:39:29, Ryan Sleevi wrote:
> Yeah, gonna Not LGTM this, unfortunately.
> 
> The issue here is that sharing the network session shares the socket pools,
and
> sharing the socket pools creates the potential for jingle-initiated sockets to
> be used with Chrome-initiated sockets.
> 
> The Chrome-initiated sockets (Blink-initiated sockets?) have interactive user
> contexts, extensions, and a variety of other things that can affect how a
socket
> is established. Jingle lacks all of these.
> 
> The short story is that any time you're establishing a socket outside the
scope
> of the full UI context and ResourceLoader layer, then you shouldn't be using
the
> HttpNetworkSession or its members.
> 
> This is why Jingle (and all other subcomponents that aren't part of the
Resource
> Loader flow) initialize their own network sessions.
> 
> So I think we'll have to continue on the bug, and more work is needed (e.g. to
> either wire up Jingle connections through the appropriate layers,
simultaneously
> solving the pool connection limits) or to work on better support for proxies
in
> the Jingle layers (wiring up UI?)

Sure, understood. I did wonder if there was a reason why the jingle glue made
its
own socket objects here, and this sounds like a good reason.