CloudFront 未正确从 S3 传回 Access-Control-Allow-Origin 标头

Question

我正在从两个不同的域访问 CloudFront。我将 S3 配置为允许来自两个域的跨域。来自 mydomain1 的页面会正确获取数据，然后来自 mydomain2 的页面会正确发送请求：

> origin: https://mydomain2

CloudFront 回复：

< content-type: application/json
< content-length: 65
< date: Fri, 04 Dec 2020 22:45:50 GMT
< access-control-allow-origin: https://mydomain1
< access-control-allow-methods: GET, PUT
< access-control-allow-credentials: true
< accept-ranges: bytes
< server: AmazonS3
< x-cache: Hit from cloudfront

当然，浏览器阻止了这个请求，因为允许的来源不匹配

我最初认为我的 Origin Request Policy 错误，但不，我使用的是 Managed-CORS-S3Origin，它具有正确的 name，我检查了它，它说它通过了沿着 Origin 标头到 S3 源——问题并没有因为内容分发业务中的“源”与 HTTP 业务中的含义大不相同这一事实而变得更容易。

但很明显，Access-Control-Allow-Origin 响应标头的值 出于某种原因被缓存。

Answer 1

因为 AWS 的人想杀了我，所以 CloudFront 缓存附加了两种不同的策略。

一个是源请求策略，它控制从 CloudFront 传递到 S3 的标头。这是自动且正确地设置以传递 Origin 标头。

另一个是缓存策略，它选择使用哪些标头来形成缓存键，在这种情况下不包括 Origin。

这简直是疯了。缓存键是像 CloudFront 这样的 CDN 决定两个请求足够相似的方式，它可以将对第一个请求的响应重放为对第二个请求的响应。

好的，也许有 some 系统需要标头但不关心值，因此 CloudFront 应在第一个请求中传递标头，然后缓存响应以实现每个后续请求，无论标头如何。

但大多数时间，99.9% 的时间，服务器需要标头，因为它将使用标头的值来创建响应，而不同的标头值会引发不同的反应。当然，S3 和 Origin 标头就是这种情况，因为 S3 将 Origin 请求标头的值复制到响应的 Access-Control-Allow-Origin 标头中。

因此，如果您选择 Managed-CORS-S3Origin 来源请求策略来管理具有 S3 来源的 CORS，那么在您编写匹配的缓存策略之前，CORS 将无法正常工作。没有人告诉你这个。啊啊啊啊！