CloudFront未正确从S3传回Access-Control-Allow-Origin标头
我从两个不同的域访问 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 标头传递给 S3 源 - 问题内容分发业务中的“起源”的含义与 HTTP 业务中的含义大不相同，这一事实并没有使事情变得更容易。
但很明显，由于某种原因，Access-Control-Allow-Origin 响应标头的值正在被缓存。
回答
因为 AWS 的人想杀死我，所以有两个不同的策略附加到 CloudFront 缓存。
一个是源请求策略，它管理从 CloudFront 传递到 S3 的标头。这是自动正确设置以传递 Origin 标头。
另一个是缓存策略，它选择使用哪些标头来形成缓存键，在这种情况下不包括 Origin。
这简直是疯子。缓存键是像 CloudFront 这样的 CDN 决定两个请求足够相似的方式，它可以重播对第一个请求的响应作为对第二个请求的响应。
好的，也许某个系统需要标头但不关心该值，因此 CloudFront 应将标头与第一个请求一起传递，然后缓存响应以完成每个后续请求，而不管标头如何。
但在大多数情况下，99.9% 的情况下，服务器需要标头，因为它将使用标头的值来创建响应，而不同的标头值会引起不同的响应。当然，S3 和 Origin 标头就是这种情况，因为 S3 将 Origin 请求标头的值复制到响应的 Access-Control-Allow-Origin 标头中。
因此，如果您选择 Managed-CORS-S3Origin 源请求策略来管理具有 S3 源的 CORS，那么在您编写匹配的缓存策略之前，CORS 将无法工作。没有人告诉你这些。啊啊啊啊！