Azure 中 Verizon CDN 的压缩行为
Compression behavior in Verizon CDN in Azure
我们在 Azure 中使用 Verizon CDN 的标准产品。从文档中可以清楚地看出，如果客户端支持多个 (https://docs.microsoft.com/en-us/azure/cdn/cdn-improve-performance#azure-cdn-from-verizon-profiles):
，Verizon 会优先考虑其他压缩方案而不是 Brotli
If the request supports more than one compression type, those compression types take precedence over brotli compression.
问题是我们的起源优先考虑Brotli。因此，对于直接向源发出 Accept-Encoding: gzip, deflate, br header 的请求，响应会返回 Content-Encoding: br header。但是，通过 CDN 的相同请求返回 Content-Encoding: gzip。
Azure 的文档并不清楚这里发生了什么。 POP 节点是否使用 gzip 和缓存解压缩资源和 re-compress？它会解压缩和缓存，然后根据请求的 header 动态压缩吗？我向 Azure 支持人员提出了这个问题，遗憾的是没有得到明确的答案。
我终于从Verizon 得到了确定的答复。从 CDN 的 POP 节点到源的 Via header 有效地禁用了压缩（这个页面会更好地解释它：https://community.akamai.com/customers/s/article/Beware-the-Via-header-and-its-bandwidth-impact-on-your-origin?language=en_US）。在我们的网络服务器中处理这个问题（剥离 header 或配置网络服务器进行压缩）解决了这个问题。也就是说，如果client支持Brotli，origin偏爱Brotli，Verizon的CDN会缓存并使用Brotli压缩后的内容。
换句话说，Microsoft 的文档具有误导性且不完整。
我们在 Azure 中使用 Verizon CDN 的标准产品。从文档中可以清楚地看出，如果客户端支持多个 (https://docs.microsoft.com/en-us/azure/cdn/cdn-improve-performance#azure-cdn-from-verizon-profiles):
，Verizon 会优先考虑其他压缩方案而不是 BrotliIf the request supports more than one compression type, those compression types take precedence over brotli compression.
问题是我们的起源优先考虑Brotli。因此，对于直接向源发出 Accept-Encoding: gzip, deflate, br header 的请求，响应会返回 Content-Encoding: br header。但是，通过 CDN 的相同请求返回 Content-Encoding: gzip。
Azure 的文档并不清楚这里发生了什么。 POP 节点是否使用 gzip 和缓存解压缩资源和 re-compress？它会解压缩和缓存，然后根据请求的 header 动态压缩吗？我向 Azure 支持人员提出了这个问题，遗憾的是没有得到明确的答案。
我终于从Verizon 得到了确定的答复。从 CDN 的 POP 节点到源的 Via header 有效地禁用了压缩（这个页面会更好地解释它：https://community.akamai.com/customers/s/article/Beware-the-Via-header-and-its-bandwidth-impact-on-your-origin?language=en_US）。在我们的网络服务器中处理这个问题（剥离 header 或配置网络服务器进行压缩）解决了这个问题。也就是说，如果client支持Brotli，origin偏爱Brotli，Verizon的CDN会缓存并使用Brotli压缩后的内容。
换句话说，Microsoft 的文档具有误导性且不完整。