[Feature]: Support WebResourceRequested event on the same domain used as virtual hostname (SetVirtualHostNameToFolderMapping

[fmongeau]

Describe the feature/enhancement you need

When a web resource requested filter added with the AddWebResourceRequestedFilter method uses the same hostname as the one specified as a virtual hostname with the SetVirtualHostNameToFolderMapping method, the WebResourceRequested event is not fired.

If a requested web resource does not exist in the folder that is virtually hosted, it should fallback on the WebResourceRequested event to handle the request if a filter was added for that url.

The scenario/use case where you would use this feature

Our web application will be hosted either with nginx or in a webview2 in a windows application. When hosted with nginx, we forward data requests to our backend. So our web pages use relative paths to access data. When hosted in a windows application, the web application is virtually hosted and the data requests will be handled locally in process with the WebResourceRequested event.

Since the same web pages are hosted in 2 environments, we'd prefer not to have to adapt all the pages to specify a different domain and leave the data requests relative to the web application.

webView.CoreWebView2.SetVirtualHostNameToFolderMapping("test.fred", @"c:\dev\website1", Microsoft.Web.WebView2.Core.CoreWebView2HostResourceAccessKind.Allow); webView.CoreWebView2.AddWebResourceRequestedFilter("http://test.fred/api/*", CoreWebView2WebResourceContext.All); webView.CoreWebView2.WebResourceRequested += CoreWebView2_WebResourceRequested;

How important is this request to you?

Nice to have. There are other ways to tackle this, but having official API support would be beneficial.

Suggested implementation

When a requested resource does not exist in the folder that is virtually hosted and there's a web resource requested filter added on the same hostname, the WebResourceRequested is fired to allow to handle the request.

Alternatively, it could be argued that the WebResourceRequested might have priority and allow to cancelled the handling of the resource by the virtual hostname mapping.

What does your app do? Is there a pending deadline for this request?

The application hosted in a webview2 control (and with nginx) is the production build of a React web application. Nginx acts as a reverse proxy to our backend server therefore, all data requests are sent to the same hostname as the web application

Eg : http://somedomain.net/reactapp/index.html

JavaScript data requests : fetch("/api/data/stops", ...); // Full url is http://somedomain.net/reactapp/api/data/stops

[camvm93]

@yildirimcagri-msft @vickiez @fmongeau Do you know when feature complete?

Currently, we cannot migrated from webview1 to webview2 for UWP app. Our app to view data locally and all resource is zip files to keep saving data in local.

1. If we use SetVirtualHostNameToFolderMapping, then webview2 won't fire WebResourceRequested event.
2. If we use Navigate to html file on local file, it will through error due to security and we cannot disable security. disable Cross-Origin Resource Sharing (CORS). On UWP, we don't find any solution or any api to ignore CORS issue for UWP.

Now, we re facing with some issue related to PDFJS. New version PDFJS don't work well in webview1 and other performance issue. webview slow....

That reason why we really need this future. It is very helpful. If you can provide me, estimate time when the feature completed. For now, we cannot do anything with our data.

[luchongk]

I'm facing the same issue, +1 to the proposed changes

[tomysaw]

+1 I'm playing around with PSPDFKit on WinUI3 1) If I use SetVirtualHostNameToFolderMapping, I can't specify content-type for js files (those require utf-8 charset) 2) If I use file:/// wasm doesn't work 3) If I request the libs via fake URL and intercept it with WebResourceRequested I get blocked by CORS when executing wasm. And yeah, you can't disable cors on WinUI3

So basically the solution could be a combination of SetVirtualHostNameToFolderMapping and WebResourceRequested for js files

[victorhuangwq]

Hi @camvm93 , @luchongk and @tomysaw in the original feature request, it is mentioned that this is a "Nice to Have". But from what you are stating, it seems like quite a blocking issue?

@fmongeau do you have a current workaround that you are using?

[luchongk]

At least in my case, it isn't strictly a blocker, but the workaround is way more cumbersome than it would be if we had the feature.

Basically it involves ditching the virtual host mapping entirely and doing its job manually inside WebResourceRequested, except for the specific URLs that we want to handle in a special way.

For example. Let's say I set a virtual host mapping from a folder to https://domain.test. Currently that disables me from handling requests to the root url because the root url is not a file so the virtual host mapping won't catch it, but it also won't trigger WebResourceRequested because there's a mapping set. So, in order to handle that one URL I would need to do what I said in the previous paragraph.

[tomysaw]

For me the workaround would be to convert the WinUI project to Maui targeting a single platform and employing BlazorWebView I suppose. However, I have to admit that supporting Blazor webview by WinUI3 would be a way better feature

[fmongeau]

Hi @camvm93 , @luchongk and @tomysaw in the original feature request, it is mentioned that this is a "Nice to Have". But from what you are stating, it seems like quite a blocking issue?

@fmongeau do you have a current workaround that you are using?

@victorhuangwq

I initially marked the issue as "nice to have" because it wasn't completely blocking in our case but it might be a blocking issue for others.

For now, we modified the React front-end to send the API requests (the ones we want intercepted by the WebView control) to a different domain than the one registered for virtual hosting.

So instead of fetching data from a relative path to the virtual path "./api/data/routes", we're fetching from a fake path "http://fakebackend/api/routes", "http://fakebackend" being the path that is intercepted with WebResourceRequested.

It's not ideal since the React front-end we virtually host with the webview2 control, is also used in the browser with content and data pulled from a web server. So we had to add some config to switch between using the relative path when hosted on a web server and using the fake path when hosted with the webview2 control.

If we could have intercepted request for the same domain as the one virtually hosted, we could have left the front-end untouched and completely oblivious to how it is hosted, which would have been a big architectural win.

The other option that was available, as other as mentioned, was not using the virtual hosting at all and delivering content manually with the WebResourceRequested event while also intercepting the data requests. We decided not to go that path because we would have been essentially manually duplicating a feature that was already implemented in the control and that code, to my understanding, seems to be in the COM component, not the .NET control.

[drearyrainDeng]

I'm facing the same issue, +1 to the proposed changes