允许任何 CORS 来源 (*) 时是不是应该设置“Vary: Origin”?

Posted

技术标签:

【中文标题】允许任何 CORS 来源 (*) 时是不是应该设置“Vary: Origin”?【英文标题】:Should you set 'Vary: Origin' when allowing any CORS origin (*)?允许任何 CORS 来源 (*) 时是否应该设置“Vary: Origin”? 【发布时间】:2020-05-10 06:40:56 【问题描述】:

对于支持 CORS 并希望尽可能高效地处理缓存的服务器,如果您知道 CORS 响应永远不会根据通过 Access-Control-Allow-Origin: * 的请求来源而有所不同,是否有必要设置 Vary: Origin

我已经阅读了有关该主题的几本指南,大多数人建议使用Vary: Origin,但在明确允许任何来源的常见 CORS 情况下,这似乎效率低下且不必要。

谢谢!

【问题讨论】:

我建议阅读 fetch.spec.whatwg.org/#cors-protocol-and-http-caches 的整个规范部分 “如果 CORS 协议要求比将 Access-Control-Allow-Origin 设置为 * 或静态来源更复杂,Vary 将是使用过……但是,如果 Access-Control-Allow-Origin 设置为 * 或特定资源的静态来源,则将服务器配置为始终发送 Access-Control-Allow-Origin 以响应资源 - 对于非 CORS 请求以及 CORS 请求 -并且不要使用Vary。” 【参考方案1】:

如果您的响应根据Origin 标头而改变,那么您需要将其从Vary 中删除。

Vary 专门用于改变响应的标头。

例如,如果您的客户端可以使用Accept 请求标头,并且根据值服务器可能返回不同的数据,那么您需要Vary: Accept

【讨论】:

是的,我完全理解 Vary 的含义——这个问题是关于特定的 CORS 用例,我发现的每个 CDN 文档都建议无论如何设置,无论您的服务器逻辑是否随尊重Origin 虽然我真的很感谢你的回答? @fisch2 无论您描述的情况如何,我的回答仍然 100% 适用。这不是特例。

以上是关于允许任何 CORS 来源 (*) 时是不是应该设置“Vary: Origin”?的主要内容,如果未能解决你的问题,请参考以下文章

将所有域添加到 CORS 的安全隐患(访问控制允许来源:*)

Python Flask CORS - API 始终允许任何来源

如何修复“CORS 协议不允许同时指定通配符(任何)来源和凭据”错误

React Cors 政策问题没有“访问控制允许来源”

Amazon S3 CORS 仍然无法正常工作:没有“访问控制允许来源”

尽管设置了标头,但不允许 CORS 请求