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

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

当然，浏览器阻止了这个请求，因为 allowed-origin 不匹配
我最初以为我的 Origin Request Policy 是错误的，但不，我使用的是 Managed-CORS-S3Origin，它有正确的名称，我检查了它，它说它正在将 Origin header 传递给 S3 源 - 问题内容分发业务中的“起源”的含义与 HTTP 业务中的含义大不相同，这一事实并没有使事情变得更容易。
但很明显，由于某种原因，Access-Control-Allow-Origin 响应 header 的值正在被缓存。

Answer 1

因为 AWS 的人想杀死我，所以有两个不同的策略附加到 CloudFront 缓存。
一个是源请求策略，它管理从 CloudFront 传递到 S3 的 header 。这是自动正确设置以传递 Origin header 。
另一个是缓存策略，它选择使用哪些 header 来形成缓存键，在这种情况下不包括 Origin。
这只是疯子。缓存键是像 CloudFront 这样的 CDN 决定两个请求足够相似的方式，它可以将第一个请求的响应重播为第二个请求的响应。
好吧，也许某个系统需要 header 但不关心该值，因此 CloudFront 应该将 header 与第一个请求一起传递，然后缓存响应以完成每个后续请求，而不管 header 如何。
但在大多数情况下，99.9% 的情况下，服务器需要 header ，因为它将使用 header 的值来创建响应，而不同的 header 值会引发不同的响应。当然，S3 和 Origin header 就是这种情况，因为 S3 将 Origin 请求 header 的值复制到响应的 Access-Control-Allow-Origin header 中。
因此，如果您选择 Managed-CORS-S3Origin 源请求策略来管理具有 S3 源的 CORS，那么在您编写匹配的缓存策略之前，CORS 将无法工作。没有人告诉你这些。啊啊啊啊!