WebResourceRequested only fires for http/https URLs

[wravery]

I'd like to implement an MHTML renderer using "content ID" (cid:xxxx) URLs. I need to hook the requests for those URLs and return the contents of the other MIME parts from the HTML portion. I'd also like to hook the request for the HTML using an IStream since NavigateToString requires loading the entire HTML document into memory and there doesn't seem to be a way to change the source URL for the top-level frame.

AB#27258414

[david-risney]

That makes sense. We have a backlog feature for something like custom protocol handlers although perhaps it makes just as much sense to reuse WebResourceRequested for that.

[simonbuchan]

+1 on this too: I'm trying to implement an oauth (e.g. log in with google) dialog, which needs a predefined URL to navigate back to complete the flow, and I was hoping this could be app:/oauth/redirect or something, rather than having to manage and much more carefully protect a public address.

[champnic]

We've made some changes in this area to allow WebResourceRequested for more types. Can you give it a try with the latest SDK/Edge Dev and see if it solves your scenario? If it doesn't, please reopen this issue with what's missing. Thanks!

[champnic]

We're also planning on adding better custom url support, tracked in #172.

[maurawinstanley]

Thanks everyone for the feedback, we are starting to look into custom URI schemes again.
One of the places we draw inspiration from is the equivalent feature EdgeHTML WebView, where WebView essentially fires an event when we see a scheme we do not recognize, and the host can do whatever logic they want in the event handler - Reference doc.

Would this provide the support you are looking for, for custom URI schemes? If this event/handler was provided would you still need WebResourceRequested to fire for custom URI schemes?

Thanks.

[simonbuchan]

I don't see how I would serve a response to that event, for one?

[wravery]

I don't see how I would serve a response to that event, for one?

Yeah, I'd have the same problem. It's OK for triggering an action by navigating the WebView to a custom URL scheme, but I'd also like to be able to serve responses with headers and streams to custom URL schemes. The example of an MHTML cid: style URL would depend on that (or URL rewriting in script) to do things like load attached images inline.

[Beanow]

Also would like to generate responses.

And at that point, strange issues with CSP and CORS can occur as well. For the no mixed content rule, should the custom protocol be treated as secure or insecure? For CORS, does the custom protocol get correctly supported in Origin and Access-Control-Allow-Origin headers and does it apply the rules as you'd expect?

(The later is a bug we're seeing with Webkit2, which effectively breaks all external asset loading unless they respond with Access-Control-Allow-Origin: *.)

[simonbuchan]

@Beanow for our uses, we would expect app: to be considered secure, and its own origin (e.g. same origin within app:, unlike file: where each file is effectively a separate origin) - but I can see other usages. That implies that you should register for protocols with is_secure etc.?

[Beanow]

For our lower level library, being configurable would be great.
But I think the most common usage would be same as yours @simonbuchan.
Either the whole custom protocol app: or URI at a domain-like level app://domain I think would be great to have as same origin.
And most often, having it be secure. Such that HTTPS resources with a correct Access-Control-Allow-Origin: app://domain response header can be loaded, for say CSS/images or XHR.

[maurawinstanley]

Thanks everyone for the feedback, we are planning support for adding an event and handler for unsupported URI schemes as well as having WebResourceRequested fire for unsupported URI schemes. Does having WebResourceRequested fulfill the remaining needs? We are currently investigating the CORS scenario but are hoping to get feedback about this first.

[liminzhu]

Hi folks! As @maurawinstanley mentioned we're currently working on custom protocol and it will looks similar to EdgeHTML's equivalent feature where you get an event when webview2 encounters an unrecognized protocol, and you can handle the event as appropriate. There area few things that planned to be exposed in the event handler -

• Uri
• IsUserInitiated
• IsRedirected
• NavigationId
• Handled (if true, then we assume the host handled the event and wv2 will cancel the original navigation; otherwise the original passes through)
• HandleDialog (if true, webview2 suppress the browser app protocol prompt if the protocol is a registered app protocol, e.g. msteams://)

Would love some feedback on whether approach solves your scenario and whether these info is enough or developers would want access to additional information/parameter as well in the event handler.

[simonbuchan]

I'm confused on the intended use case - it sounds like most people here want to be able to serve responses, which presumably would be handled by WebResourceRequested (hence the title), and other url-only custom protocol work makes sense for browser -> app redirections, but that's handled by the OS.

Why would you want someone to implement this protocol event rather than WebResourceRequested? What's the difference?