为什么CORS未命中时没有设置“Vary: Origin”响应？

Question

进行CORS请求时，如果请求的来源在允许的来源列表中，响应将包含Access-Control-Allow-Origin头和Vary: Origin头。

Vary: Origin告知CDN等后续服务，响应是基于请求者提供的Origin头值协商得出的。

问题在于（我已经测试了主流CDN提供商），如果请求者在请求中未提供Origin头或提供的Origin值不在允许的值列表中，则响应中不包括Vary: Origin。

执行CORS的CDN是否应始终在响应头中包含Vary: Origin？如果没有，CDN会认为可以向任何Origin值提供相同的响应。另一方面，可以通过使用随机Origin值发起多个请求来填充CDN的缓存。

- simbolo

Answer 1

是的。如果一个请求可能包含不同值的 Access-Control-Allow-Origin，那么 CDN 应该始终响应 Vary: Origin，即使对于没有 Access-Control-Allow-Origin 头的响应也需要如此。你的分析是正确的：如果头部并不总是存在，那么可能会用错误的值填充缓存。

- monsur

---

正如我所想的那样。我一直在怀疑自己，因为当Origin存在且匹配时，Amazon CloudFront和Azure CDN只返回Vary：Origin，并忽略其他情况。只有Google会为每个请求输出Vary：Origin。我想知道为什么网上很少关于这个问题的讨论？ - simbolo

它并不经常出现（因为有较少的CORS实现会列出白名单，大多数只使用*），而且当它出现时，很难进行调试。我在《CORS实战》中有一节关于这个问题的内容。 - monsur

该问题也已在AWS S3论坛上报告。 - Kristian Hanekamp

当使用Amazon CloudFront与Web源（而不是S3）时，从CloudFront转发Origin标头到您的源将避免此问题。这样理解是否正确？http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/header-caching.html#header-caching-web-cors - Eric Eijkelenboom

实际上，这会导致Chrome出现一些问题：https://bugs.chromium.org/p/chromium/issues/detail?id=260239。难怪Google会为每个请求输出Vary: Origin。 - Gyum Fox