☰

对于某些网络，Windows 更新服务器返回 Content-Length：0

tag-icon • tag-icon windows-server-2016 windows-update bits
对于某些网络，Windows 更新服务器返回 Content-Length：0

有人知道为什么 Windows 更新服务器（即 download.windowsupdate.com）会在某些网络上给出看似虚假的回复吗？以 MSE 补丁为例，我使用 4G 移动网络（沃达丰）收到以下标头。为了简洁起见，我稍微缩短了响应。

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。这对 curl 来说很好。

但是旧版本的 BITS 似乎无法很好地处理这个问题。在虚拟机中使用 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 进行了重写，因此可能不会出现同样的问题。不过，这是一个有趣的问题！

答案1

这似乎是 Windows 10 之前版本的 Windows 上针对 Windows 更新的有效 DOS 类型错误。已向 MSRC 报告，但报告已关闭，因此我不明白为什么不能披露。对于那些感兴趣的人，报告的副本位于：https://github.com/conoror/wudos

我可以轻松地重现这种情况（Win7 ESU June 2021），将 mitmproxy 配置为透明代理，并使用一个干扰 HEAD 响应的 Python 插件：

from mitmproxy import ctx

class ZeroContentLength:
    def response(self, flow):
        if "msdownload" in flow.request.pretty_url and \
                flow.request.method == "HEAD" and\
                "Content-Length" in flow.response.headers:
            ctx.log.info("Msdownload HEAD of len %s seen and set to 0" %
                            flow.response.headers["Content-Length"])
            flow.response.headers["Content-Length"] = '0'

addons = [
    ZeroContentLength()
]

在这种情况下，将自己定位为透明代理可能并不是一件容易的事，所以这可能并不重要。我更换了提供商来解决这个问题。

相关内容