If I set up a WKURLSchemeHandler and have it load, e.g. test://host-one/index.html, and on that page I make a fetch() request to test://host-two/test.json the request fails before it is able to send, telling me: > Cross origin requests are only supported for HTTP. When I dug around the source code a little I found the following comment: > Cross-origin requests are only allowed for HTTP and registered schemes. We would catch this when checking response headers later, but there is no reason to send a request that's guaranteed to be denied. https://github.com/WebKit/webkit/blob/fc41ae69af5bce93e59ffdc1c828515199d12c44/Source/WebCore/loader/DocumentThreadableLoader.cpp#L175 A WKURLSchemeHandler is, I presume, a "registered scheme", so it seems as though the intention is for this to work? It would be great to get a confirm that either this is indeed a bug or whether it is intended behaviour, so that we can look for alternative solutions. I've set up a very simple test XCode project here: https://github.com/alastaircoote/wkwebview-cors-test
From a quick look at the code, it appears that "registered scheme" refers to explicit registration that is only available as API on Gtk, not on Mac or iOS. So this is a feature request, not a bug.
<rdar://problem/54749893>
Alastair, your app looks like it definitely reproduces the error, but could you describe a little bit more about your use case? What kind of content are you using that needs to make a cross-origin request? Alexey, since you reviewed https://bugs.webkit.org/show_bug.cgi?id=77041 could you describe a little bit about why CORS just fails immediately for non-HTTP(s) schemes? Whatever we do or do not do about this, we should not expose SchemeRegistry behavior to our API as it is currently implemented because it is process-global, and I would recommend it be deprecated in the GTK API and replaced by something that is not process-global.
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.
> Alexey, since you reviewed https://bugs.webkit.org/show_bug.cgi?id=77041 could you describe a little bit about why CORS just fails immediately for non-HTTP(s) schemes? Not really, as that was the case before this patch. Did custom schemes even support HTTP headers at the time? Also, custom schemes tend to have superpowers, so extending communication ability is generally scary.
Would it be any more acceptable (and easier to implement) to simply remove CORS checks on any WKURLSchemeHandler request that stays within its own scheme? CORS doesn't really make all that much sense in the context of custom scheme handlers anyway, given that the requests are all handled within your app.
Is apps use custom schemes to proxy actual HTTP requests, removing CORS checks for same scheme requests would be quite dangerous.
For Apache Cordova and Ionic Capacitor apps this is a major issue. Since Apple has pushed Cordova and Capacitor apps into using WKWebView instead of UIWebView, and using file:// protocol for serving the local assets in WKWebView have a lot of problems (that weren't present on UIWebView), the solution was to use custom schemes as it has a few less issues than file://. (But still have issues). Not being able to use fetch to urls using the own app scheme is a major issue (XHR works fine).
I do understand the security concerns around allowing CORS proxying, but would it not be fair to say the WKWebView's loadHTMLString method poses a similar security risk? You can inject arbitrary HTML and attach it to a URL with no validation. Perhaps a safer way to accomplish what I'm aiming for here would be an equivalent for the UIWebView/NSURLCache pairing that we could use in previous versions of iOS? I can see WKWebsiteDataStore/WKWebsiteDataRecord but unless I'm missing something we can't do anything custom with it. Is it worth me making a separate bug report for that, since it's a separate issue?
*** This bug has been marked as a duplicate of bug 205198 ***