Support for per-request proxy configuration

[virgil-mocanu]

Is there a way to configure the proxy (e.g. Web, Socks) on a per-request basis?

With CEF, this seems to be possible globally (but per-request may also work). CEF has the notion of a CefRequestContext, which has a SetPreference method that allows you to specify (key,value) pairs. In this case, the key would be "proxy", and the value would be something like "proxyhost:8080".

This would be useful for implementing custom HTTP request routing logic (e.g. similar to PAC files).

Can this capability please be implemented if it does not yet exist? Thank you in advance.

AB#25508072

[david-risney]

Thanks for your feedback! I'll open a feature request item for this. Would you mind describing your application and how it would use this feature? Thanks!

[virgil-mocanu]

Hi David,

Thank you for the response. Per your request, here is description of how I envision this feature would be used by the application (multiple use cases):

Use Case 1: Description:
The WebView2 application needs to determine at run-time through which proxy it should send each HTTP request. The route may vary depending on the origin (i.e. scheme, host, port) and if possible, also depending on the URI path. This is essentially what PAC files do. But the application must not rely on the PAC specified via Internet Options.

Use Case 1: Proposed Sequence:
a) The WebView2 application adds a handler of the NavigationStarting event (or some other event that occurs before the HTTP request is actually sent to the transport layer i.e. before the TCP connection is even made).
b) WebView2 invokes the handler
c) The handler obtains the "request context" from the request and configures it with the proxy through which the request should be made
d) WebView2 makes the request through the configured proxy

Use Case 2: Description:
The WebView2 application needs to be configured after it starts (but before it makes any requests), with the proxy through which WebView2 should route all HTTP requests. The proxy is specified one time only, after startup. The application must not rely on the proxy address specified via Internet Options.

Use Case 2: Proposed Sequence:
a) Sometime after startup, the WebView2 application learns the proxy address
b) The WebView2 application obtains a global "request context" and configures it with the proxy through which all subsequent requests should be routed
c) WebView2 routes all subsequent requests through the configured proxy

NOTE that a significant difference between Use Case 1 and Use Case 2 is in the scope of the "request context" (i.e. per-request vs. global). Ideally, the "request context" should be per-request as suggested in Use Case 1. Otherwise, (i.e. if it is global instead), then I wonder if configuring it while handling the NavigationStarting event for a particular request would affect the route of that request only. I.e. I wonder if it would not also affect other requests that may have been started concurrently (if "concurrent" makes any sense in the context of a single browser host).

Thank you again for your kind attention to this feature.

[payamss]

hey guys
please add a possibility to use proxy i have 2 problems
1- my work internet reach my application through a socks or http proxy and i cant use webview2 because of that( go back to ie)
2- i cant load served angular project on for example localhost:4200 i think this feature must add it for develpers
thanks

[mungojam]

I just want to be able to disable pac lookup and proxies altogether. We have a pac script set up through group policy, but it isn't relevant for our WebView2 apps which are just pointing at localhost so the pac lookup is just delaying the startup of the app.

With Edge itself I can launch with --no-proxy-server, so I'd like the equivalent of that to be possible in WebView2.

[siewers]

I would just like to have the following arguments working:

• --proxy-auto-detect
• --proxy-pac-url

in addition to the following, that do work:

• --proxy-server
• --proxy-bypass-list

What I don't understand is why WebView2 supports --proxy-server and --proxy-bypass-list, but not the actual features that would make our lives a whole lot simpler, like --proxy-auto-detect.
It must already be supported, since I can see this in the release notes for version 1.0.790-prerelease:

• Turned off the Microsoft Edge Shopping feature in WebView2.

That sounds like that the proxy functionality must be on par with Edge Chromium (I mean, the "shopping feature" was not disabled in WebView2 by mistake, right?), so why it's deliberately disabled or black-listed is beyond my understanding.

But maybe I'm doing something wrong?

[lamposu]

any news?

[david-risney]

Sorry, no news yet. This is in our backlog but we haven't gotten to it.

We haven't intentionally disabled any proxy features or command line arguments. Generally features in the browser should work the same in WebView2. I don't know why some proxy command line arguments aren't working the same as they are in the browser. As a part of investigating this feature I expect we'll need to look into why.

[siewers]

Is there any way to escalate this issue?
We have customers relying on proxy support, but since we cannot configure WebView2 to work with PAC URLs or just simply use the system proxy settings, it's unfortunately close to unusable.

[LeanderVanEck]

After doing some investigating we concluded that the difference in proxy behavior between the Edge browser and WebView2 seems related to the browser argument --winhttp-proxy-resolver.
When I use any of the Windows 10 settings for Automatic proxy setup (see screenshot), the proxy is never correctly resolved.

Also when including the --browser-pac-url argument the proxy is no longer being resolved. Nor is the PAC file ever fetched.

We can observe the same behavior when including the same browser arguments for msedge.exe. Unfortunately I don't know a way to exclude --winhttp-proxy-resolver in WebView2.

[siewers]

@LeanderVanEck This is hopefully good news.
@david-risney Do you know what the reason is for including the --winhttp-proxy-resolver argument in the WebView2 process?

[champnic]

--winhttp-proxy-resolver was added to avoid a perf delay during startup with the default resolver. We are tracking completion of a new system proxy resolver option (tracked by this Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1032820) and will switch to it once available. I'm following up with the owner of that bug to see it's status (it's marked 'open' but hasn't had checkins for a while) and asking the team to see if there's a way to negate/remove the --winhttp-proxy-resolver browser arg.