[fetch] Add new Access-Control-Suppress-Headers CORS response header (#253)

As an alternative/supplement to the existing **Access-Control-Expose-Headers** CORS response header, could we have a new header, as defined below:

**Access-Control-Suppress-Headers = "Access-Control-Suppress-Headers" ":" #field-name**

**Access-Control-Suppress-Headers** and **Access-Control-Expose-Headers** are mutually exclusive. If both headers are returned in response to a CORS preflight OPTIONS request, all non-simple headers are suppressed (not exposed).

Otherwise, if **Access-Control-Suppress-Headers** is returned (in response to a CORS preflight OPTIONS request), the list of exposed headers must be updated to include all simple response headers and any headers other than those of which the field name is an ASCII case-insensitive match for one of the values of the **Access-Control-Suppress-Headers** headers (if any), before exposing response headers to APIs defined in CORS API specifications.

Therefore, even if the **Access-Control-Suppress-Headers** includes a simple header, that header will still be exposed - the **Access-Control-Suppress-Headers** value applies only to non-simple headers.

Essentially, where **Access-Control-Expose-Headers** _whitelists_ response headers (disallow all except those specified), **Access-Control-Suppress-Headers** _blacklists_ response headers (allow all except those specified).

Why do I want this?

As often as not, when developers use the **Access-Control-Expose-Headers**, what they really want is to ensure that certain headers are **not** available to client-side code - effectively, they have to list all the allowed headers. If the backend code changes and new headers are added, the code which sets the **Access-Control-Expose-Headers** value must also be updated. By allowing those developers to explicitly define which headers should be hidden from client-side code, it gives them the ability to not worry about having to explicitly add new headers to the **Access-Control-Expose-Headers** 'list'.

Where CDN's and load balancers are brought into the mix, this also makes it easier for them, since this is another place where the CORS preflight OPTIONS request (including the **Access-Control-Expose-Headers** response header) may be handled, so simplifying here would be useful.

(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).

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