commit ae2cbb8c8e36ae7f899b115516787ebe96b823d9
author Matt Menke <mmenke@chromium.org> Thu Feb 21 20:20:13 2019
committer Commit Bot <commit-bot@chromium.org> Thu Feb 21 20:20:13 2019
tree e09204ca72428943fd9f1abc362ba879eb096b67
parent 5a5345343496264bd5d1faf6cc4422dcb56f7643

Socket Pools Refactor 26: Rework QUIC and HTTP2 proxy auth.

The way HTTP proxy auth works with tunnels is that we see an auth
challenge, we return the proxy socket to the consumer (bypassing the
SSL layer that would be layered on top of it), telling it of the auth
challenge.  It then provides credentials and calls restart with auth,
while holding onto the socket. We then drain the response body of the
original auth challenge, and if we can reuse the socket, we send the
request again, with the new credentials. If we see another auth
challege, we call back into the consumer (Which still owns the
ProxyClientSocketWrapper), and it can provide more credentials. We
repeat this until the user decides to proceed with no crentials, the
server accepts the credentials, or there's a network error. If
the server accepted the credentials, we have a useable socket, which
we then toss back into the HTTP proxy socket pool, and then we
request an SSL socket from the pool above that, so it can create an
SSL socket layered on top of the proxy socket we just made.

The way QUIC and HTTP2 cases work is different. As above, we pass
the ProxyClientSocketWrapper up to the consumer, which provides
credentials. However, when it tells the wrapper to restart with auth,
the ProxyClientSocket closes the socket, and then claims auth succeeded.
At that point, we return the socket to HTTP proxy socket pool, which
notices the socket was closed, and destroys it. This effectively closes
the stream layered on top of the H2/QUIC session, though the session
itself remains in the session pool. Then the consumer, unaware of these
shenanigans, requests a new SSL socket, which then results in requesting
a new ProxyClientSocketWrapper (Since the old one was destroyed). When
connecting, it will create a new stream on the same session as before
(taken from the session pool), and preemptively sends the auth
credentials provided earlier using a new stream. If another auth
challenge is seen, this process repeats, again creating a new
ProxyClientSocketWrapper.

As part of flattening the socket pools, we'll always end up reusing a
ProxyClientSocketWrapper for challenges. This CL modifies the QUIC and
HTTP2 paths to more closely match the HTTP path. They will still make
new streams for each new set of auth credentials, but all auth attempts
will use the same ProxyClientSocketWrapper.

Bug: 472729
Change-Id: I96791754480456908dda4595f9dc201fdbc41f13
Reviewed-on: https://chromium-review.googlesource.com/c/1481060
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: Asanka Herath <asanka@chromium.org>
Reviewed-by: Ryan Hamilton <rch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#634322}