I'm developing a CORS middleware library, and my ambition is to validate the user-allowed origins as much as possible in order to spare my users dysfunctional CORS configurations.
Browsers byte-serialize the issuing Web origin of a cross-origin request and then use the result as the value of the Origin header that they automatically attach to the request.
What schemes can appear in the Origin header (sent by a Fetch-compliant browser)? What is the cardinality of the set of such schemes?
http and https are in that set; that much is clear. Also, I know that byte-serializing an opaque origin (e.g. an origin whose scheme is data) results in null. But can the Origin header contain schemes other than http and https? The Fetch standard (the de facto CORS specification, among other things) doesn't seem to place a restriction on that...
Perhaps you can see "ftp" from legacy clients, FTP was never much tested before it got removed. And in https://github.com/fedidcg/FedCM/issues/320#issuecomment-1274306658 I floated the idea of an about:browser value, which would give you "about". As noted by evilpie extensions might give you "moz-extension" or "chrome-extension". Apart from that just "http" and "https".