Bug 294381
| Summary: | Add WebViewAssetLoader‐style API to WKWebView for virtual HTTPS asset hosting | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | dev.satoshi.1016 |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Enhancement | CC: | achristensen, annevk, beidson, cdumez, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
dev.satoshi.1016
**Background**
On Android’s Chromium‐based WebView, the WebViewAssetLoader API lets apps serve bundled assets (from `assets/` or `res/`) under a virtual HTTPS domain (e.g. `https://appassets.androidplatform.net/`) without needing real TLS certificates. JavaScript in the page sees a proper HTTPS origin, so `fetch()`/XHR and CORS behave as if loading from a remote server.
WKWebView today lacks an equivalent. Developers must either run a local HTTP server or use custom URL schemes, neither of which fully emulates an HTTPS origin.
**Feature Request**
Introduce a WebKit API—analogous to Android’s WebViewAssetLoader—that allows configuration of a virtual HTTPS hostname for serving app‐bundled resources.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/153812992>
dev.satoshi.1016
Hi WebKit team—could you share the current status or triage outcome for this request?
I can’t access the linked Radar (rdar://problem/153812992), so any public note here would help.
If it’s tracked elsewhere, please feel free to mark this as a duplicate or close with a public pointer. Thank you!
dev.satoshi.1016
It doesn't look like anyone is actively working on this issue at the moment, so I'd like to take a shot at it.
Brady Eidson
> It doesn't look like anyone is actively working on this issue at the moment, so I'd like to take a shot at it.
While you're quite free to work on a patch, please note that changes to the public API that a particular vendor ships are entirely up to that vendor.
And if that vendor does not want a particular API exposed, they are under no obligation to expose it.
i.e. If your goal is to add WKWebView API and have it end up in an actual macOS/iOS/visionOS SDK, that's not actually up to the WebKit open source project.