I think we want to Vary: Access-Control-Request-Private-Network, just like we currently do for Origin. Conditionally added whenever allow_private_network is set.

But then, are you saying we should also add for the access-control-request-header and access-control-request-method as well?

The Django and Flask CORS do not add it to the Vary - this doesn't mean they are right, just a data point. But can you find a reference or justify it?

My logic is that Vary makes it explicit to the caches that the same request will have a different response based on the headers sent. And this is the case here. When the request header is sent, it will have different response headers, so the response varies on that.

Including a Vary header ensures that responses are separately cached based on the headers listed in the Vary field.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Vary

Also found this:
https://stackoverflow.com/questions/65675056/why-add-vary-on-access-control-request-method-acrh-and-origin-when-options-meth

To my limited knowledge on this topic, Vary seems like it will make the implementation more correct (doesn't mean it's necessary). We already Vary on Origin so the intention is that we want to support caching OPTIONS responses. May as well expand Vary to cover all varying headers.

But then, should the other access headers be also included?

I'm having an inclination to not do it, unless someone did it in any other CORS implementation (in any framework from any language).

From the stackoverflow it explicitly mentions https://github.com/rs/cors as having this behavior. I haven't searched more.

If this decision was up to me, I would ensure Vary contains all varying headers correctly. The cost is little, and when someone decides to cache OPTIONS responses the setup will be simpler and less bug-prone. It would make the app more explicit about cache handling which is a good thing.

AI research on this: https://claude.ai/public/artifacts/860f4896-69c0-4416-8066-ff9bd73c1a37

The official specifications provide minimal guidance on Vary headers for CORS, creating a gap between spec and practice. Vary: Origin is recommended but not strictly required by specifications, yet is absolutely critical in production environments with CDNs or caching layers. Vary: Access-Control-Request-Headers appears in no specification but prevents real cache poisoning issues.

@Zaczero I'll merge this as is, because the "Vary" is actually an issue with the other request headers as well. Would you like to contribute with that?

This https://github.com/rs/cors has a beautiful code. Super easy to understand. 👍