Skip to content

GitLab

T
tangled
Switch branch/tag
  1. 22 Jul, 2020 39 commits
  3. 21 Jul, 2020 1 commit
    • Bruce Dawson's avatar
      Revert "Implement the WindowsSystemProxyResolutionService/Request" · 5889b656
      Bruce Dawson authored 
      This reverts commit 33f234e7.

Reason for revert: Windows 7 test bots are failing

This is because WinHttpCreateProxyResolver requires Windows 8+.
https://docs.microsoft.com/en-us/windows/win32/api/winhttp/nf-winhttp-winhttpcreateproxyresolver

Original change's description:
> Implement the WindowsSystemProxyResolutionService/Request
> 
> This change creates a functional proxy resolver for Windows that relies
> on WinHttp APIs. This is not in its final state, though. This CL
> represents the simplest, least-work way to implement this proxy
> resolution service. Work still to come includes:
> - Complete NetLogs
> - Better error reporting from WinHttp APIs
> - Proxy Delegate
> - Proxy retry info
> - Assurance that the proxy configs we're receiving are from the system
> 
> The WindowsSystemProxyResolutionService is the object that external
> callers use to resolve a proxy. These callers can keep track of the
> status of this proxy resolution via a ProxyResolutionRequest,
> implemented here as a WindowsSystemProxyResolutionRequest. The request
> object is mainly intended to kick off a specific proxy resolution and
> report a result via a caller-provided callback. Both of these objects
> deal with a WindowsSystemProxyResolver.
> 
> The WindowsSystemProxyResolver is a new class that does all the required
> interfacing with WinHttp APIs. It is a reference counted object created
> by the WindowsSystemProxyResolutionService. Once created, it is used for
> the lifetime of the WindowsSystemProxyResolutionService. Throughout that
> time, the Resolver indirectly keeps a WinHttp session handle open. Each
> WindowsSystemProxyResolutionRequest is given a reference to the new
> resolver. When the Request object attempts to resolve a proxy for a
> given URL, it'll call into the Resolver object. Under the hood, the
> Resolver object creates a handle for the proxy resolution and runs the
> async call to WinHttp. At any time, the Request object can choose to
> ignore a pending result from the Resolver (ex: shutdown). The Resolver
> object must be reference counted because async WinHttp calls call back
> directly into the Resolver object, so it needs to stay alive as long as
> we're waiting for an async response from WinHttp.
> 
> The only other new object is the WinHttpAPIWrapper, which is just a thin
> wrapper over WinHttp APIs which we use to enable easier testing and
> to simplify some interactions with WinHttp. A WinHttpAPIWrapper is owned
> by a WindowsSystemProxyResolver. The Resolver object is the only object
> that should interact with the Wrapper object in any meaningful way.
> Internally, the WinHttpAPIWrapper keeps track of the opened WinHttp
> session handle that we're using for the lifetime of the Resolver object.
> 
> This change includes tests for the WindowsSystemProxyResolver layer (by
> mocking out the WinHttpAPIWrapper) and the
> WindowsSystemProxyResolutionService (by mocking out the
> WindowsSystemProxyResolver).
> 
> Bug: 1032820
> Change-Id: Ic1c60033ff148e6e8f3708e37a2af366613fefac
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2159128
> Commit-Queue: Nicolas Arciniega <niarci@microsoft.com>
> Reviewed-by: Ramin Halavati <rhalavati@chromium.org>
> Reviewed-by: Eric Roman <eroman@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#790493}

TBR=eroman@chromium.org,rhalavati@chromium.org,niarci@microsoft.com

Change-Id: I54d4659d5165261af912c427fdeb8f372a7bb2bf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 1032820
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2311063Reviewed-by: default avatarBruce Dawson <brucedawson@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#790602}
      5889b656