为什么在Azure CDN中以https方式提供服务时会跳过mp3文件，而在Chrome中从http处提供服务时为何不跳过呢？

Question

我最近使用Microsoft Azure为mp3文件（口语播客内容）建立了内容传送网络。最初，一切正常，但最近文件开始“跳过”，即重置自身。例如，当播放器到达文件的3:30标记时，它将回到文件的0:15标记。由于某些原因，这仅在通过https（而非http

）提供文件时发生

具体：

1. 这只是在Chrome上发生的-我也在Edge和Firefox上进行了测试-它们运行完美
2. 它在多台计算机上发生
3. 只有文件的https版本有问题，http版本很好
4. 它可以使用普通的香草音频标签运行-无需花哨的播放器
5. 发生这种情况时，开发工具的控制台中没有任何条目，媒体窗口中也没有新的下载内容
6. 我将相同的文件上传到Amazon S3-放在相同的普通播放器中，并且在https下可以正常播放。

这怎么可能？

Azure的NOT正常工作请求中的标题

• 请求方法：GET
• 状态码：206部分内容（来自磁盘缓存）
• 推荐人政策：降级时不推荐人
• 接受范围：字节
• 访问控制允许来源：*；
• 访问控制公开标题：x-ms-request-id;
• Content-Disposition：附件； filename = XXXXXXXXXXX.mp3;
• 内容长度：76434500;
• 内容范围：字节0-76434499 / 76434500;
• 内容类型：音频/ mpeg;音频/ mpeg3 ;;
• 日期：星期一；
• ETag：“ 0x8D5EC5B899726B0”;
• 最后修改时间：星期三；
• 服务器：Windows-Azure-Blob / 1.0 Microsoft-HTTPAPI / 2.0;
• 状态：206；
• x-ms-blob-type：BlockBlob;
• x-ms-lease-state：可用；
• x-ms-lease-status：已解锁；
• X-MS-Ref：0DGxVWwAAAA2BOMWL9GzRqSzc9yi5SF4QkwyRURHRTA1MTIAMzc1ZmRlZDMtMjA3My00Y2YxLTljZGMtNzc4NGMxYmI3ZmZi;
• x-ms-request-id：998f9297-301e-00bc-2945-22fa9f000000;
• x-ms-version：2014-02-14;

来自Azure工作请求的标题

• 请求方法：GET;
• 状态码：206部分内容（来自磁盘缓存）；
• 远程地址：52.239.152.234:80;
• 推荐人政策：降级时不推荐人；
• 接受范围：字节；
• 访问控制允许来源：*；
• 访问控制公开标题：x-ms-request-id;
• Content-Disposition：附件； filename = XXXXXXXXXXX.mp3;
• 内容长度：76434500;
• 内容范围：字节0-76434499 / 76434500;
• 内容类型：音频/ mpeg;音频/ mpeg3 ;;
• 日期：星期一；
• ETag：“ 0x8D5EC5B899726B0”;
• 最后修改时间：星期三；
• 服务器：Windows-Azure-Blob / 1.0 Microsoft-HTTPAPI / 2.0;
• x-ms-blob-type：BlockBlob;
• x-ms-lease-state：可用；
• x-ms-lease-status：已解锁；
• x-ms-request-id：6246c264-401e-017b-1b47-22c00b000000;
• x-ms-version：2014-02-14;

S3的工作请求中的标题

• 接受范围：字节；
• 内容长度：76303428；
• 内容范围：字节131072-76434499 / 76434500;
• 内容类型：音频/ mp3；
• 日期：星期一；
• ETag：“ 09fac410597469e6db237376a0e2505d-5”;
• 最后修改时间：Sun；
• 服务器：AmazonS3；
• x-amz-id-2：ictUYlZjFNJwa2g8q09TowZuc3quHiHmZsYmq7b / hjIgEsoIKpZIYrlqBCea1NYScr9QukHPqZY =;
• x-amz-request-id：6FE8390CF92213AF;