当请求标头具有 CloudFront + S3 网站的“接受编码”时，CORS 标头丢失

Posted 2023-03-04

【中文标题】当请求标头具有 CloudFront + S3 网站的“接受编码”时，CORS 标头丢失

【英文标题】：CORS headers missing when request header has 'Accept-Encoding' for website of CloudFront + S3

【发布时间】：2018-07-09 20:30:24

【问题描述】：

我们有一个为 CORS 访问配置的 s3 存储桶。它前面有一个 CloudFront 实例。这是我观察到的奇怪行为：

URL 和请求标头 |响应中的 CORS 标头

CF + "接受编码" |没有

S3 + 接受编码 |是的

CF - '接受编码' |是的

这是预期的吗？如何强制 CF 始终返回 CORS 标头作为响应？ 感谢您提供任何提示/线索

【问题讨论】：

顺便说一句，“Accept-Encoding”标头的值是浏览器添加的“gzip, deflate, br”

S3 direct，没有 Accept-Encoding 怎么办？ CloudFront 是否配置为“自动压缩对象”？您指的是哪些确切的 CORS 标头？ CloudFront 是否配置为将 Origin、Access-Control-Request-Headers 和 Access-Control-Request-Method 列入白名单？设置这些内容后，您是否进行了缓存失效？

S3 direct without 'Accept-Encoding' 在其响应中包含所有 CORS 标头（我们配置了 Access-Control-Allow-Origin: *, Access-Control-Allow-Methods: GET, PUT, POST,删除，头部，访问控制最大年龄：3600）。我使用 curl 和 GET 来获得上述所有结果。 Origin 标头是否在请求中并不重要，“Accept-Encoding”的存在会关闭 CORS 标头。实际上，在我使 CF 中的缓存失效之前，它一直在工作，在我在 S3 中更正 CORS 配置后等待了 4 到 5 天。然后我使CF中的缓存失效，发现CORS丢失了

我们没有将 CF 配置为自动压缩对象。但是好像没什么区别。我检查了，同样的事情

您是说直接发送到 S3 GET 的 curl 请求，既没有 Accept-Encoding 也没有 Origin 请求标头实际上在响应中返回 CORS 标头。我不能复制这个。请提供准确的 curl 命令选项。

【参考方案1】：

我发现当您在 CloudFront > 'your distribution' > Origins > 'your origin' > Edit > Origin Custom Headers 中设置 access-control-allow-origin: * 时会出现此问题。为了解决这个问题，我删除了那个 Origin Custom Header，看截图：

---

---

此外，您需要创建一个失效以使更改生效，CloudFront >“您的分配”> 失效 > 创建失效。 要使所有资源无效，您只需在字段中传递 /* 或任何其他适用于您的用例的有效正则表达式