[Webkit-unassigned] [Bug 231146] New: HTTPS interception API for WKWebView

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=231146

            Bug ID: 231146
           Summary: HTTPS interception API for WKWebView
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: dsaunders45459 at gmail.com
                CC: kkinnunen at apple.com

We are trying to improve performance of some of our web content loaded in WKWebView. One of the performance gaps between WKWebView and other webviews is that WKWebView does not provide an HTTPS interception API. For some scenarios, we have large CSS/Image/JavaScript/HTML content that can be downloaded to disk before the web content loads, but because there is no interception API WKWebView spends significant time and bandwidth making network requests.

We looked at setURLSchemeHandler API, but it was not usable in our scenario. The web content in our application is not entirely offline, needs to make some CORS network requests, potentially use cookies, or include some JavaScript resources that are online. If the domain of the web content is HTTPS, custom scheme only works for image, and mixed content blocks scripts/CSS. Additionally, servers do not trust non-HTTPS protocol for CORS. Some applications may have had success by proxying all resources through a custom protocol, but this results in web content that is specifically written for WKWebView (not sharable with other browsers), and potentially mishandles some web security features such as SOP, CORS, cookies, and CSP. These security features are built-in to WKWebView, but if you proxy all network requests you would need to implement them yourself.

Service worker was also not reliable for this scenario since the service worker cache is cleared in WebKit without notification, or capability to reinstall, after x amount of days without interaction.

https://bugs.webkit.org/show_bug.cgi?id=138169 has already been opened for the same issue, but we wanted to open a bug specifically for the performance cost of not having HTTPS interception capabilities in WKWebView. For our usage, we have the list of URL that we would be able to intercept before loading the web content. If the hesitation on this bug is purely performance (there would need to be an additional IPC call on every request to see if the UI process wants to intercept that request), we could provide a list upfront to only make an IPC call when necessary.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211003/037412a5/attachment-0001.htm>