Re: [fetch] RFC: a mechanism to bypass CORS preflight (#210)

@sicking - WRT additional requests, I was assuming that the first CORS preflight to an origin would be a normal one, containing an extra header, e.g., `Access-Control-Site: 1`. That would trigger an async (and fully optional) request to e.g,. `/.well-known/cors-site`. It is one additional request, but it's not on the critical path, and it saves potentially many more.

Presumably, you'd have a file at that location that contains a list of paths in some format. Let's say JSON for now. E.g.,

```
GET /.well-known/cors-site HTTP/1.1
Host: www.example.com
Origin: place.example
Access-Control-Request-Method: PUT

HTTP/1.1 200 OK
Content-Type: application/cors-map+json
Cache-Control: max-age=3600
Vary: Origin, Access-Control-Request-Method

{
    "/widgets": { 
        "Access-Control-Allow-Origin": "https://place.example http://foo.example.com:8888",
        "Access-Control-Allow-Credentials": "true",
        "Access-Control-Expose-Headers": "Foo, Bar"
    },
    "/public-data": { "Access-Control-Allow-Origin": "*" }
}
```

... with the longest/most specific matching path prefix winning (although one could imagine other approaches if the root object were an array).

The client could act as if any preflight that has a match here, the response would have the corresponding CORS headers (with the exception of `Access-Control-Max-Age`, since the cache ability of the well-known response itself would determine its freshness lifetime).

Note that CORS request headers are sent on the .well-known request; if the server wants this response to change based upon them, all it needs to do is send the appropriate `Vary` (and, eventually, `Key`).

Importantly, the administrator has to set the `Access-Control-Allow-Credentials` explicitly for a path, just as they'd do for "normal" CORS. Considering that they can already fire that footgun with .htaccess, is that a reasonable tradeoff?

I think the biggest risk here is that the file would get out of sync with the headers that the server sends. That could be mitigated somewhat if good tooling emerged (either driving headers from the central file, or vice versa). If that's not good enough, we probably should go back to a single, site-wide policy (so that it's only used on sites that are really homogenous). 

BTW, a header like `Access-Control-Site: 1` on normal CORS requests could also be taken as a hint to the server that it should HTTP/2 server push `/.well-known/cors-site`, removing some latency.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/210#issuecomment-186501663