Windows 更新伺服器返回 Content-Length: 0 對於某些網路

有誰知道為什麼 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 重寫的，所以它可能沒有同樣的問題。不過，這很有趣！

這似乎是針對 Windows 10 之前版本的 Windows 更新的有效 DOS 類型錯誤。已向 MSRC 報告，但報告已關閉，因此我不明白為什麼我不能披露。對於那些感興趣的人，報告複製在：https ://github.com/conoror/wudos

我可以通過將 mitmproxy 配置為透明代理和一個與 HEAD 響應混淆的 Python 外掛輕鬆重現這一點（Win7 ESU 2021 年 6 月）：

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()
]

在這種情況下，將自己定位為透明代理可能並非易事，因此它可能並不重要。我換了提供商來解決這個問題。

引用自：https://serverfault.com/questions/1063567