为什么 CloudFront 有时会在启用 gzip 而不是 br 时提供 gzip 服务？答案

【问题标题】：Why does CloudFront sometimes serve gzip instead of br, when both are enabled?为什么 CloudFront 有时会在启用 gzip 而不是 br 时提供 gzip 服务？
【发布时间】：2021-09-04 07:29:23
【问题描述】：

我正在阅读有关 CloudFront 压缩的 CloudFront 文档（https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html，检索时间为 2021 年 6 月 20 日）：

查看器在请求中包含 Accept-Encoding HTTP 标头，标头值包括 gzip、br 或两者。这表明查看器支持压缩内容。当查看器支持这两种格式时，CloudFront 使用 Brotli。

我对此的简单解读是，如果使用以下标头发出请求：

接受编码：gzip、deflate、br

那么 CloudFront 应该使用 Brotli。

但是，通过 CloudFront 观察我们的生产 Web 应用程序（它使用启用了 gzip 和 br 的 Managed-CachingOptimized 缓存策略），我可以简单地看到情况并非如此 - 大约 70% 的文件被提供使用 Brotli，其余使用 gzip。

更令人困惑的是，所有这些文件都是同一编译的一部分，通过同一来源提供服务，具有相同的元数据。除了内容和大小，我看不出它们有什么不同。

我唯一的直觉是 CloudFront 在某些情况下确定 gzip 生成的文件大小比 br 更好，因此决定改用它，但我找不到这种行为的记录。

为什么会这样？

【问题讨论】：

尝试一件事。使 CloudFront 中的所有缓存失效，然后通过从开发工具中禁用缓存在浏览器中重新加载您的 Web 应用程序。之后分享标题信息。
这可能是@LovekeshKumar 所说的缓存问题，或者并非所有请求都正确设置了标头accept-encoding。
我也遇到过一次，但我使云端缓存无效并删除了我的浏览器缓存。之后一切顺利。
@StefanN 我已经确认所有请求都正确设置了 accept-encoding 标头 - 特别是那些使用 gzip 响应的请求。它始终是gzip, deflate, br，因为这是 Chrome 所传递的。我们不会篡改客户端的任何请求标头。
@LovekeshKumar 谢谢，我最初尝试过（在 CloudFront 和客户端），但不幸的是没有解决它。我仍然得到 brotli 和 gzip 的混合响应。

标签： amazon-web-services amazon-s3 amazon-cloudfront

【解决方案1】：

因此，在与 AWS 支持人员讨论此事后，我发现了问题。

简而言之 - 如果对 CloudFront 资源的第一个请求（即在缓存之前）仅支持 gzip，那么所有未来对该资源（现在已缓存）的请求都将使用 gzip 提供服务，即使客户端指定它支持布罗特里。

发生这种情况的原因是我们使用 Cypress 对我们的 web 应用程序运行自动化测试。赛普拉斯目前仅在向目标站点 (https://github.com/cypress-io/cypress/issues/6197#issuecomment-684847493) 发出请求时支持 gzip，并且偶尔会在我们上传新文件时首先访问它们 - 导致它们被永久缓存为 gzip。

我现在找到的唯一解决方案是，正如@LovekeshKumar 在评论中建议的那样，手动清除 CloudFront 缓存，然后立即通过 Chrome 或其他支持 Brotli 的工具获取所有文件。奇怪而乏味，但希望这最终会在 AWS 和 Cypress 方面得到解决。

【讨论】：