Cross-Origin Resource Sharing (CORS) is a well-established security feature to protect data from unexpected cross-origin accesses.
WebView provides some APIs that change the CORS behaviors, but details are not explained in the API documents. This document aims to clarify such detailed behaviors and implementation details to give WebView and chromium developers hints to keep consistent behaviors among making code changes.
intent:// URLs are used to send an Android Intent via a web link. A site can provide an intent:// link for users so that users can launch an Android application through the link. See Android Intents with Chrome for details.
This is allowed only for the top-level navigation. If the site has a link to an intent:// URL for an iframe, such frame navigation will be just blocked.
Also, the page can not use such intent:// URLs for sub-resources. For instance, image loading for intent:// URLs and making requests via XMLHttpRequest or Fetch API just fail. JavaScript APIs will fail with an error (ex. error callback, rejected promise, etc).
content:// URLs are used to access resources provided via Android Content Providers. The access should be permitted via setAllowContentAccess API beforehand. content:// pages can contain iframes that load content:// pages, but the parent frame can not access into the iframe contents. Also only content:// pages can specify content:// URLs for sub-resources. Pages loaded with any scheme other than content:// can't load content:// page in iframes and they can not specify content:// URLs for sub-resources.
TODO
TODO
TODO
Custom scheme should not be permitted for CORS-enabled requests usually. However, when shouldInterceptRequest is used, the API allows developers to handle CORS-enabled requests over custom schemes.
When a custom scheme is used, * or null should appear in the Access-Control-Allow-Origin response header as such custom scheme is processed as an opaque origin.
