Is the Vary header necessary for non-cacheable CORS requests?

[yinheli]

Is it necessary to include the Vary header in responses to non-CORS requests that wouldn't be cached anyway?
For example, if the request is a POST or PUT request, which are typically not cached,
do we still need to respond with "Vary: Origin"? Personally, I don't think it's particularly necessary.

Related information:

#24
#25

[barryvdh]

Are there downside to adding the Vary header?

[yinheli]

It doesn't seem very elegant and returns not very useful/necessary information.

[yinheli]

I have a project that previously used a custom CORS implementation, which was quite standardized. However, we are planning to migrate to Laravel's built-in CORS implementation, which is essentially based on php-cors. We decided to abandon our self-developed implementation mainly to reduce the maintenance cost of our codebase. Using the official standard implementation will be more intuitive and clear.

The Vary header handling in php-cors is quite simplistic, adding it to all paths that support cross-origin requests, regardless of whether it is truly needed. For example, it adds the Vary header to non-cached POST requests. This has caused thousands of our unit tests to fail, so I am considering proposing an enhancement to php-cors to avoid adding the Vary header for non-CORS requests that wouldn't be cached anyway.

Can I submit a PR to address this issue? Or if you have any other suggestions, please let me know. Thanks.

[barryvdh]

Well you could just add a Middleware behind CORS to remove the VARY head on non-GET requests.

[barryvdh]

I think it's according to the specs now. Please let me know if there is a resource explaining otherwise.