问Azure CDN -以某种方式截断“大文件”？

EN

编辑:这一切现在都神秘地起作用了，尽管我无法弄清楚到底是什么导致了这个问题。可能根本就不是CDN？把这个留给后人，如果我再看到这种事发生的话会更新的.

我一直在尝试使用Azure CDN (微软托管，而不是Akamai或Verizon)来处理几个Azure Web应用程序的文件下载，直到今天它才开始正常工作，直到今天它开始返回截断版本的“大文件”，导致一个PDF文件无法打开(我特别指的是Azure CDN的大文件优化功能)。

该文件从原始URL运行良好，为8.59mb，但从CDN端点检索的相同文件正好为8mb。这是一个可疑的巧合，恰好与上面提到的大型文件优化功能所使用的块大小相同。文件的有关部分：

Microsoft的Azure标准使用了一种称为对象块的技术。当请求一个大文件时，CDN从原点检索文件的较小部分。在CDN服务器接收到完整或字节范围的文件请求后，CDN边缘服务器以8 MB的块从原点请求文件。..。这种优化依赖于源服务器支持字节范围请求的能力。

有问题的文件URL：

• 原点
• CDN

我还将相同的文件直接上传到网站的文件系统中，以排除CMS (Umbraco)及其blob-存储-文件系统的干扰，但结果是完全相同的。这是参考的链接。

• 原点
• CDN

在这两种情况下，这两个文件都是二进制的，只不过CDN的文件突然停止在8mb，尽管源文件支持字节范围请求(用Postman验证)，上面链接的Azure CDN文档声称

如果不是CDN上缓存的所有块，则使用预取从原点请求块。

那就是

最大文件大小没有限制。

同样的问题也发生在超过8mb的其他文件中，尽管这些文件在上周已经开始工作了。自那时以来，CDN配置没有发生任何变化。

我想发生的事情是：

1. 从CDN下载客户端请求文件
2. CDN指出它是一个“大文件”，并从原点请求第一个8mb块
3. 根据请求使用8mb块进行答复。
4. CDN开始将8mb块返回给客户端。
5. CDN要么不请求下一个块，要么源不提供它
6. 客户端只接收文件的前8mb。

也可能是我撞错了树。已经尝试关闭压缩，不太确定从这里还能去哪里。这可能是我的错，所以我是不是错配置了CDN或什么的？我已经考虑过清除CDN的缓存，但我并不认为这是一种解决方案，我宁愿避免手工解决方案。