有谁知道为什么 Windows 更新服务器（即：download.windowsupdate.com）会在某些网络上给出看似虚假的回复？以 MSE 补丁为例，我使用 4G 移动网络 (Vodafone) 获得以下标头。为简洁起见，我将响应缩减了一点。
curl -I "http://download.windowsupdate.com/d/msdownload/update/software/defu/2021/05/am_delta_6a3649beb57cee48081bd31631c8774de6505d2f.exe"
HTTP/1.1 200 OK
Accept-Ranges: bytes
Age: 8995
Content-Type: application/octet-stream
Date: Fri, 14 May 2021 13:59:10 GMT
Server: ECAcc (lha/8DA7)
Content-Length: 0
Connection: keep-alive
请注意无效的 Content-Length，尤其是与 keep-alive 一起使用。这不会发生在我们由 UPC/Virgin Media 提供的主网络上。Content-Length 是该网络上的有效数字。
有内容（一个几兆字节的 .exe 文件），curl 可以很好地处理它——我猜它会检查 read() 是否返回更多字节，如果有，则忽略 Content-Length。适合卷曲。
然而，旧版本的 BITS 似乎不能很好地处理这个问题。在 VM 中使用 Windows 7 Pro，BITS 开始循环运行 - 它一遍又一遍地写入 C:\ProgramData\Microsoft\Network\Downloader\qmgr0.dat，直到我执行“网络停止位”。这使用 100% 磁盘，并且实际上是针对 Windows 7 的 DOS。
我知道 Windows 7 不支持，但我最初在 Windows Server 2016 中看到了这个问题。我现在承认这可能已经是一个已知的错误并且可能已经被修补，但我不知道如何找出（除了在合适的机器上进行测试，当我获得访问权限时。这是与 Covid 19 相关的困难！）
据我所知，BITS 是为 Windows 10 重写的，所以它可能没有同样的问题。不过，这很有趣！