[Webkit-unassigned] [Bug 201180] Cannot send in-scheme CORS requests with WKURLSchemeHandler

[bugzilla-daemon at webkit.org]

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

Alastair Coote <webkitbugzilla at alastair.is> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |webkitbugzilla at alastair.is

--- Comment #4 from Alastair Coote <webkitbugzilla at alastair.is> ---
Happy to!

Our app renders HTML/JS/CSS that’s shared with our web site (i.e. it is not created specifically for the WKWebView environment). It makes use of third party libraries at various points, a good example being a mapping library that downloads tile data via CORS. We also often make use of WebGL, loading cross-origin images for textures.

Right now it works fine, but since it’s loading directly over https:// we don’t have the ability to pre-cache anything before the WKWebView opens. Our hope is to be able to use WKURLSchemeHandler as a proxy of sorts, responding with locally cached content when it exists and going remote when not. Our current efforts in that direction use file:// URLs, which of course run into these exact same CORS issues. Ideally we’d use WKURLSchemeHandler instead, with scheme-relative URLs (e.g. <script src=‘//example.com/test.js'></script>) as a means to use the same code on both web and app, but that’s where we run into the CORS problems.

In short: we’re sharing code between WKWebView and “regular” web browsers, and don’t have enough control/flexibility to ensure that everything loads from a single origin.

-- 
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/20190827/d0662665/attachment.html>