CloudFront未能正确传递S3返回的Access-Control-Allow-Origin头信息。

Question

CloudFront未能正确传递S3返回的Access-Control-Allow-Origin头信息。

10

我从两个不同的域名访问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 origin —— 事实上，“origin”在内容分发业务中意味着与HTTP业务中完全不同的东西，这使得问题变得更加复杂。

但显然，Access-Control-Allow-Origin响应头的值被缓存了，原因不明。

- Michael Lorton

2个回答

2

要获取有关Michael的答案的更多信息，您可以查看以下链接：

该政策可能如下所示：

- Jorge Palacio

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Michael Lorton · Accepted Answer

因为AWS的人试图让我崩溃，所以CloudFront缓存有两个不同的策略。

一个是源请求策略，它管理着从CloudFront传递到S3的头信息。这被自动设置为正确传递Origin头。

另一个是缓存策略，它选择用哪些头信息来形成缓存键，并且在这种情况下没有包括Origin。

这就是疯狂的地方。缓存键是CDN（如CloudFront）如何确定两个请求足够相似，以便将第一个请求的响应作为第二个请求的响应进行重放的方式。

也许有一些系统需要一个头信息但并不关心其值，因此CloudFront应该在第一个请求上传递头信息，然后缓存响应以满足每个后续请求，而不管头信息。

但是大部分时间，99.9%的时间，服务器都需要头信息，因为它将使用头信息的值来创建响应，并且不同的头信息值会导致不同的响应。对于S3和Origin头信息，情况肯定是这样的，因为S3会将Origin请求头的值复制到响应的Access-Control-Allow-Origin头信息中。

如果您选择了Managed-CORS-S3Origin源请求策略来管理S3来源的CORS，则在编写匹配的缓存策略之前，CORS将不起作用。但是没有人会告诉您这个问题。Auuuggghhh！