当两者都启用时，为什么 CloudFront 有时会提供 gzip 而不是 br？

Question

我正在阅读有关 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 更好，因此决定使用它，但我找不到此行为的记录。

为什么会出现这种情况？

Answer 1

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

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

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

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

Answer 2

原因是您的源可能仅支持 gzip 压缩并将 gzip 返回到 CloudFront。然后 CloudFront 无法压缩内容并按原样缓存 gzip 响应。

请参阅此处：https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html

Origin 已配置为压缩对象

如果您将 CloudFront 配置为压缩对象并且源端也压缩对象， 源应包含 Content-Encoding 标头，该标头指示 向 CloudFront 告知该对象已被压缩。当有回应时 来自源的内容包含 Content-Encoding 标头，CloudFront 确实如此 无论标头的值如何，都不压缩对象。云锋 将响应发送给查看器并将对象缓存在边缘中 位置。