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

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

我正在阅读有关 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 提供的生产网络应用程序（使用 Managed-CachingOptimized 缓存策略，同时启用 gzip 和 br），我可以简单地看到情况并非如此 - 大约 70% 的文件使用 brotli 提供服务，而其余使用 gzip。

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

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

为什么会这样？

解决方法

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

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

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

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