Is the Vary header necessary for non-cacheable CORS requests?
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:
https://github.com/fruitcake/php-cors/issues/24 https://github.com/fruitcake/php-cors/pull/25
Are there downside to adding the Vary header?
It doesn't seem very elegant and returns not very useful/necessary information.
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.
Well you could just add a Middleware behind CORS to remove the VARY head on non-GET requests.
I think it's according to the specs now. Please let me know if there is a resource explaining otherwise.