This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
chrome-extension:// and android.resource:// are both relative schemes, but their 'host' component isn't a host as required by the URL spec. We should probably change the semantics of 'host' to not necessarily be a domain name or IP address, but make it depend on the scheme instead.
These schemes don't seem to be well documented. From what I have managed to find: chrome-extension://<extensionID>/<pageName>.html (Where <extensionID> is the ID given to the extension by "Chrome Web Store" and <pageName> is the location of an HTML page) android.resource://package_name/id_number (Where package_name is your package name as listed in your AndroidManifest.xml. For example com.example.myapp id_number is the int form of the ID) It is not clear to me that these schemes are relative schemes, nor it is clear to me that the scheme data is composed of a host and a path.
Per RFC 3986 something is a suitable base URL for parsing relative URLs if it starts with "scheme://". Per bug 27233 we can support this. If we can support that, we can probably also allow the bit that's parsed as host to be treated as it were something else semantically speaking, since we don't really define the semantics of the components to that level of detail (just their parsing).
Is it a problem that host is always IDNA-parsed and that IPv6 is always parsed out of it as well? That a scheme decides to treat it as something else doesn't really matter, but changing those aspects would no longer match implementations.
Thank you. I made the definition a little bit more open to interpretation. It's still either a domain, IPv4, or IPv6 address, as those have more than semantic implications. They're data types. https://github.com/whatwg/url/commit/4c0f0916e640a3b031302c0a11cfad50c3f8a2b6