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

Question

我正在从两个不同的域访问 CloudFront。我将 S3 配置为允许来自两个域的 cross-origin。来自 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

当然，浏览器阻止了这个请求，因为 allowed-origin 不匹配

我最初以为我的 Origin Request Policy 有误，但没有，我使用的是 Managed-CORS-S3Origin，它具有正确的 name 我检查了它并且它说它正在将 Origin header 传递到 S3 origin——这个问题并没有变得更容易，因为内容分发业务中的“origin”与它在 HTTP 业务中的含义非常不同。

但显然，Access-Control-Allow-Origin 响应 header 的值由于某种原因被缓存。

Answer 1

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

一个是源请求策略，它管理 header 从 CloudFront 传递到 S3 的内容。这是自动且正确设置为传递 Origin header.

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

简直是疯子。 cache-key 是像 CloudFront 这样的 CDN 如何确定两个请求足够相似以至于它可以重放对第一个请求的响应作为对第二个请求的响应。

好的，也许某个地方有一些系统需要 header 但不关心该值，因此 CloudFront 应该传递 header 与第一个请求然后缓存响应以满足每个后续请求，无论 header.

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

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

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

CloudFront is not correctly passing back the Access-Control-Allow-Origin header from S3

amazon-s3

cors

amazon-cloudfront