should VARY be a cors-safelisted header?

[wanderview]

Currently VARY is not a cors-safelisted header:

https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name

This means that VARY header matching in cache_storage will not work by default for cors responses. Is this intended?

Servers can opt-in to exposing VARY by using access-control-expose-headers, but I wonder if we could/should add VARY to the cors safelist.

[annevk]

The main reason we safelist response headers is because they could contain confidential information and the variety of teams working on an application might overlook this.

If we always expose Vary this could lead to exposure of confidential request header names. This seems quite minor, but making changes to the same-origin policy is always tricky. Is Vary very important in practice for the Cache API?

[wanderview]

Well, I was trying to align chromium to the cache API spec where we are not supposed to look at the internal response for the vary header. Switching to ignore vary headers seemed low risk for opaque responses, but seems more risky for CORS responses. I'm unsure if I'll be able to align there or not. It would simplify some things (and match my original expectations) if vary was cors safelisted.