Azure中Verizon CDN中的压缩行为

Question

我们在Azure使用Verizon的标准服务。从文档中可以清楚地看到，如果客户端支持多个压缩方案(https://learn.microsoft.com/en-us/azure/cdn/cdn-improve-performance#azure-cdn-from-verizon-profiles)，Verizon将优先于Brotli的其他压缩方案：

如果请求支持多个压缩类型，则这些压缩类型优先于brotli压缩。

问题是我们的起源优先于Brotli。因此，对于直接向原点发出Accept-Encoding: gzip, deflate, br头的请求，响应将返回Content-Encoding: br标头。但是，通过CDN的相同请求将返回到Content-Encoding: gzip。

Azure的文档不清楚这里发生了什么。POP节点是否解压缩资源并使用gzip和缓存重新压缩？它是否解压缩和缓存，然后根据请求的头动态压缩？我向Azure的支持者提出了这个问题，但遗憾的是没有得到一个明确的答案。

Answer 1

我终于从Verizon那里得到了一个结论性的答案。从CDN的POP节点到原点的Via头有效地禁用了压缩(这个页面将更好地解释它：https://community.akamai.com/customers/s/article/Beware-the-Via-header-and-its-bandwidth-impact-on-your-origin?language=en_US)。在我们的web服务器中处理这个问题(要么去掉头，要么配置web服务器来压缩)解决了这个问题。换句话说，如果客户端支持Brotli并使用Brotli，Verizon的CDN缓存并使用使用Brotli压缩的内容。

换句话说，微软的文档是误导和不完整的。