我的公司正在考虑从 AWS 迁移到 GCP。我们希望 CloudCDN 支持的功能之一是 brotli 编码。我们有一个技术栈，它将我们的 javascript 捆绑到 3 个文件中：
chunk.js
chunk.js.gz
chunk.js.br
如果 CloudCDN 收到客户端请求标头Accept-Encoding: br, gzip ，CloudCDN 是否足够智能以提供 Brotli 文件？此外，它会被缓存吗？如果没有，是否有任何其他方法可以在 CloudCDN 中实现这一点。
AWS Cloudfront 仅使用 2 个 lamdbas 提供此功能。我认为这是一个坏主意。
是的，只要来自您的源服务器的响应包含 Vary: Accept-Encoding 标头，Cloud CDN 就可以缓存所有 3 种表示并根据客户端的 Accept-Encoding 标头提供正确的一种。在https://cloud.google.com/cdn/docs/caching#vary_headers上有更多信息。
更新：
我没有意识到您使用 Cloud Storage 存储桶作为来源。不幸的是，Cloud CDN 和 Cloud Storage 都没有根据客户端是否支持 Brotli 将客户端对 /chunk.js 的请求重写为 /chunk.js.br 的功能。我同意这很有用，所以我提交了内部功能请求。
当 nginx 等源站服务器配置为选择适当的文件时，Cloud CDN 仅在缓存未命中时才需要返回源站服务器。只要源服务器的响应包含 Vary: Accept-Encoding 标头，Cloud CDN 就可以通过将客户端的 Accept-Encoding 请求标头与缓存响应时指定的 Accept-Encoding 值进行比较，直接从边缘提供缓存命中。指定 Accept-Encoding: br, gzip 的客户端将从一个缓存条目提供服务，而指定 Accept-Encoding: gzip 的客户端将从另一个缓存条目提供服务。
CloudFront 现在原生支持 Brotli 压缩。如果您使用 S3 作为源（或任何返回未压缩内容的源），CloudFront 可以使用 Brotli 或 Gzip 在边缘自动压缩。您无需创建文件的三个版本或使用 Lambda@Edge。
https://aws.amazon.com/about-aws/whats-new/2020/09/cloudfront-brotli-compression/