Allow cancelling/overriding web resources in NativeWebView WebResourceRequested event #53

Activity

1. duncanlang

   added the

   Feature

   issue type on Jun 7, 2026
2. Cheatoid commented on Sep 2, 2026

   

   Cheatoid

   on Sep 2, 2026

   More actions

   Yes, I would also like to expand on this... Add full WebResourceRequested interception and response override support.

   Since NativeWebView currently exposes WebResourceRequested but applications can't cancel a request or override response.

   Please consider extending the API to support full request interception, including:

   • Canceling/blocking requests before they reach the network.
   • Redirecting requests.
   • Modifying request headers.
   • Providing a custom response without contacting the network.
   • Modifying response headers.
   • Replacing response content/body.
   • Returning custom status codes.
   • Optionally streaming response content.

   This would enable advanced integrations such as adblock-rust (i could release my c# bindings), custom caching layers, offline resource handling, request rewriting, proxying, content transformation, security filtering, and application-specific virtual resources.

   Example: blocking a request

   webView.WebResourceRequested += (_, e) =>
   {
       if (adblockEngine.ShouldBlock(e.Request.Url))
       {
           e.Response = WebResourceResponse.Block();
       }
   };

   Example: replacing the response

   For example, an application could intercept a JavaScript resource and provide its own content:

   webView.WebResourceRequested += (_, e) =>
   {
       if (e.Request.Url == "https://example.com/script.js")
       {
           e.Response = new WebResourceResponse
           {
               StatusCode = 200,
               Headers =
               {
                   ["Content-Type"] = "application/javascript"
               },
               Content = Encoding.UTF8.GetBytes(
                   "console.log('Replacement script');"
               )
           };
       }
   };

   The browser would receive this response as if it came from the requested URL, without necessarily performing the original network request.

   Example: adblock-rust integration

   A filtering engine could inspect each request:

   webView.WebResourceRequested += (_, e) =>
   {
       var result = adblockEngine.Check(
           e.Request.Url,
           e.Request.Method,
           e.Request.Headers
       );
   
       if (result.ShouldBlock)
       {
           e.Response = WebResourceResponse.Block();
           return;
       }
   
       if (result.ReplacementContent is not null)
       {
           e.Response = new WebResourceResponse
           {
               StatusCode = 200,
               Headers =
               {
                   ["Content-Type"] = result.ContentType
               },
               Content = result.ReplacementContent
           };
       }
   };

   Example: request/response transformation

   More advanced users could implement transformations such as:

   Browser request
         |
         v
   WebResourceRequested
         |
         +--> inspect URL / headers / method
         |
         +--> adblock-rust
         |      |
         |      +--> BLOCK
         |      +--> ALLOW
         |      +--> REDIRECT
         |      +--> REPLACE
         |
         v
   Custom response
         |
         v
   WebView
   

   For larger resources, the API could ideally support a stream-based response rather than requiring the entire body to be held in memory:

   e.Response = new WebResourceResponse
   {
       StatusCode = 200,
       Headers =
       {
           ["Content-Type"] = "application/javascript"
       },
       ContentStream = myStream
   };

   Suggested API characteristics

   Ideally, this should be a platform-independent abstraction over the underlying engines (WebView2, WKWebView, WebKitGTK/WPE, etc.), while exposing only capabilities that can be implemented consistently.

   At minimum, applications should be able to make an explicit decision for each intercepted request:

   Allow normally
   Block
   Redirect
   Replace response
   

   This would make NativeWebView significantly more useful for applications requiring embedded-browser filtering, offline resources, custom protocols, response rewriting, caching, and other advanced networking scenarios.

   👍React with 👍1Reacted by Duncan Lang