[Webkit-unassigned] [Bug 138169] WKWebView does not support NSURLProtocol-style interception of http or https

[bugzilla-daemon at webkit.org]

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

--- Comment #46 from Ian Ragsdale <ian.ragsdale at gmail.com> ---
Seems like #1 and #4 ought to be doable (if imperfectly) with a proxy, right? Seems like if you have a local proxy accepting requests you can do whatever networking you want over the actual network.

- Ian


(In reply to Eugene But from comment #45)
> Having *per-WKWebView* proxy setting is useful for Chrome to support some
> Enterprise features that Chrome for iOS lost after moving from UIWebView to
> WKWebView.
> 
> 
> There are some other use cases that proxy setting do not address:
> 
> 1.) Innovate in networking space, like Google did with Speedy and doing with
> QUIC (this requires full support of custom network protocols)
> 2.) Better privacy control over cookies, see
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
> (can be done without full network protocols support, but may need new API)
> 3.) Support WebP (can be done without full network protocols support)
> 4.) Change request headers to send the list of chrome experiments to google
> servers (can be done without full custom network protocols support, but
> requires new WKWebView API)
> 
> All these use cases were possible with UIWebView, which supported custom
> network protocols.

-- 
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/20200114/adde59aa/attachment.htm>