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

Maybe I am misunderstanding the problem and/or oversimplifying, but AIUI, the browser's CORS preflight cache is keyed on the following

- origin
- url
- credentials
- method OR header

So currently, the first preflight OPTIONS request to a site could return `Access-Control-Allow-Headers: <list-of-EVERY-allowed-header>` and `Access-Control-Allow-Methods: <list-of-EVERY-allowed-method>`, and this would result in many entries being added to the preflight cache, correct? And they would all have the same Origin, correct?

So is the concern that every time a different URL on that site is accessed using CORS, then a new preflight request must be made (because there is no entry in the preflight cache for that URL)?

If so, why not specify a new response header which could be returned for a preflight request:

`Access-Control-Allow-Path: <comma-delimited-list-of-generic-paths>`

e.g.

`Access-Control-Allow-Path: /api/*, /other/*`

If returned, the client browser adds these _generic_ entries to the preflight cache (prefixed with the actual target domain). When subsequently checking for an entry in the preflight cache, it can check first for an exact URL match and if not found, check for a generic match.

As na example, if a page on www.foo.com wants to access a resource (/api/coolapi) on www.bar.com, it sends this as its preflight request:

`GET /api/coolapi HTTP/1.1`
`Host: www.bar.com`
`Origin: http://www.foo.com`
`Access-Control-Request-Method: GET`
`Access-Control-Request-Headers: X-header1, X-header2`

and it gets this as its preflight response:

`HTTP/1.1 200 OK`
`Access-Control-Allow-Origin: http://www.foo.com`
`Access-Control-Allow-Methods: GET, PUT, OPTIONS, DELETE`
`Access-Control-Allow-Headers: X-header1, X-header2, X-header3, X-header4`
`Access-Control-Allow-Paths: /api/*, /other/*`
`Access-Control-Max-Age: 86400`

It then adds the following _generic url_ entries to its preflight cache in addition to the specific request URL (max-age and credentials omitted for clarity):

`http://www.foo.com      www.bar.com/api/*      GET`
`http://www.foo.com      www.bar.com/api/*      PUT`
`http://www.foo.com      www.bar.com/api/*      OPTIONS`
`http://www.foo.com      www.bar.com/api/*      DELETE`
`http://www.foo.com      www.bar.com/other/*    GET`
`http://www.foo.com      www.bar.com/other/*    PUT`
`http://www.foo.com      www.bar.com/other/*    OPTIONS`
`http://www.foo.com      www.bar.com/other/*    DELETE`
`http://www.foo.com      www.bar.com/api/*               X-header1`
`http://www.foo.com      www.bar.com/api/*               X-header2`
`http://www.foo.com      www.bar.com/api/*               X-header3`
`http://www.foo.com      www.bar.com/api/*               X-header4`
`http://www.foo.com      www.bar.com/other/*             X-header1`
`http://www.foo.com      www.bar.com/other/*             X-header2`
`http://www.foo.com      www.bar.com/other/*             X-header3`
`http://www.foo.com      www.bar.com/other/*             X-header4`

It should be easy enough to add restrictions to this, e.g. only allow `Access-Control-Allow-Paths` where `Access-Control-Allow-Origin` is **not** `*` and perhaps only allow generic paths which match the request path. And, of course, maybe only allow for non-credentialed requests.

Obviously this _could_ be misconfigured, but only insofar as it would mean that subsequent preflight requests might be bypassed accidentally. However, the actual CORS requests would still be executed as normal.

On the plus side, it would mean that a single initial OPTIONS preflight request to a site could return site-wide information using pretty much the current CORS system.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/210#issuecomment-201062930