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

Question

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

The viewer includes the Accept-Encoding HTTP header in the request, and the header values include gzip, br, or both. This indicates that the viewer supports compressed content. When the viewer supports both formats, CloudFront uses Brotli.

我对此的简单理解是，如果使用以下 header 发出请求:

accept-encoding: gzip, deflate, br

那么 CloudFront 应该使用 Brotli。

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

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

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

为什么会这样？

Answer 1

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

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

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

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