允许任何 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 协议不允许同时指定通配符(任何)来源和凭据”错误