[fetch] Update Access-Control-Expose-Headers CORS response header to allow * (allow-all) (#252)

This has almost certainly been discussed before, but would it be possible to allow * (allow-all) as a separate value for the **Access-Control-Expose-Headers** CORS response header?

This would allow all non-simple headers passed in the request to be 'exposable' to client-side code.

When the original CORS spec was written, there was an assumption (I assume!) that the preflight OPTIONS response would be served by the same application that would serve the subsequent CORS GET/POST/whatever request. Therefore, that application would have full knowledge of what headers the API might eventually respond with, and which of them should be exposed or suppressed.

However, with the advent of CDN's and load balancers, it may be that the code that responds to the preflight OPTIONS request is **not** the actual application that will process the subsequent GET/POST/whatever request. Indeed, website owners might want the OPTIONS response to be served from non-application code, because that code may be quicker to respond to the client.

(Full disclosure: I work for Akamai, a large CDN. Whilst my views don't represent any official Akamai position, we would obviously like this, since it would make our (and out customer's) lives easier. I have also implemented CORS solutions using an F5 LTM load balancer, and run into this problem).

So the spec would become the following:

Access-Control-Expose-Headers = "Access-Control-Expose-Headers" ":" #field-name | "*"

If Access-Control-Expose-Headers: * is returned, browser would allow all headers to be returned using e.g. XMLHttpRequest getResponseHeader().

---
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/252