Incompatibility with Windows Legacy Update

[atauenis]

What's happen?

When using WebOne together with Legacy Update on Windows 2000/XP (at least), updates are finding, but does not installing. Direct connection still working perfectly.

Looking into %windir%\WindowsUpdate.log:

2022-11-29  11:30:33:527     660    328 DnldMgr ***********  DnldMgr: New download job [UpdateId = {358C9385-719C-4911-939E-C472292F2C2F}.103]  ***********
2022-11-29  11:30:33:527     660    328 DnldMgr   * Queueing update for download handler request generation.
2022-11-29  11:30:33:527     660    328 DnldMgr Generating download request for update {358C9385-719C-4911-939E-C472292F2C2F}.103
2022-11-29  11:30:33:527     660    328 DnldMgr Asking handler to generate non-range requests.
2022-11-29  11:30:33:527     660    328 Handler Windows Patch download for UpdateId = {358C9385-719C-4911-939E-C472292F2C2F}: selected action is download full-file.
2022-11-29  11:30:33:527     660    328 DnldMgr ***********  DnldMgr: New download job [UpdateId = {358C9385-719C-4911-939E-C472292F2C2F}.103]  ***********
2022-11-29  11:30:33:536     660    328 DnldMgr   * BITS job initialized, JobId = {9F91AEE5-014B-4ED3-AD49-FE8DF5F63F41}
2022-11-29  11:30:33:536     660    328 DnldMgr BITS job {9F91AEE5-014B-4ED3-AD49-FE8DF5F63F41} using proxy = ivybridge:8080, bypass = <NULL>
2022-11-29  11:30:33:536     660    328 DnldMgr   * Downloading from http://download.windowsupdate.com/msdownload/update/software/secu/2008/12/windows2000-windowsmedia-kb952069-x86-rus_bc19f55e800b1b27b59bbd780c09e4a60cef736c.exe to C:\WINNT\SoftwareDistribution\Download\b039b8e48b5883b47e56a13825d47e9a\Windows2000-WindowsMedia-KB952069-x86-RUS.exe (full file).
2022-11-29  11:30:33:620     660    500 DnldMgr WARNING: BITS job {9F91AEE5-014B-4ED3-AD49-FE8DF5F63F41} failed, updateId = {358C9385-719C-4911-939E-C472292F2C2F}.103, hr = 0x80200011, BG_ERROR_CONTEXT = 5
2022-11-29  11:30:33:620     660    500 DnldMgr   Progress failure bytes total = 0, bytes transferred = 0
2022-11-29  11:30:33:620     660    500 DnldMgr   Failed job file: URL = http://download.windowsupdate.com/msdownload/update/software/secu/2008/12/windows2000-windowsmedia-kb952069-x86-rus_bc19f55e800b1b27b59bbd780c09e4a60cef736c.exe, local path = C:\WINNT\SoftwareDistribution\Download\b039b8e48b5883b47e56a13825d47e9a\Windows2000-WindowsMedia-KB952069-x86-RUS.exe
2022-11-29  11:30:33:628     660    500 DnldMgr WARNING: Download job failed because of insufficient range support.
2022-11-29  11:30:33:628     660    500 DnldMgr Error 0x80200011 occurred while downloading update; notifying dependent calls.

In WebOne log the files are starting to download, but download stops quickly after beginning, because client aborted the transfer.

The problem is 0x80200011 (The server did not return the file size. BITS only transfers static content and requires the HTTP server to return the Content-Length header. The transfer request fails if the URL points to dynamic content. :link: ).

Somewhy BITS service don't see Content-Legth HTTP header. By manual opening even in old MSIE, the files are downloading correctly.

I don't know if this a bug, because Microsoft saying that this is correct when using proxies: https://answers.microsoft.com/ru-ru/windows/forum/all/%D0%BD%D0%B5-%D0%BC%D0%BE%D0%B3%D1%83/15cfee6a-a978-423b-bfb2-b6be7c155e69 . :smiley:

In most of I've googled, guys saying that "don't use proxies for WU/WSUS", and only. But in one site there is a hint about reason of the problem: https://web.archive.org/web/20120506031042/http://forums.techarena.in/server-update-service/658623.htm :

12-01-2007 Lawrence Garvin (MVP) Re: BITS update is failing "Bill" Bill@discussions.microsoft.com wrote in message news:FE24072E-4594-441A-ABB6-C27BF1395B56@microsoft.com...

The BITS update started failing around the first of the year. NO system changes have ocurred recently that would have affected this. There have been no WSUS server changes and no proxy server changes. I get errors in the Windows Update log that indicate an error code of 0x80200011 "Insufficient Range Support". Below is a sampling of the log. Any ideas???

2007-01-11 16:08:03 1392 b9c DnldMgr WARNING: Download job failed because of insufficient range support.

This is most likely an issue with an intervening proxy server and/or firewall that's not properly implementing HTTP v1.1 protocol support. And, even though you've said there have been no proxy server changes, that /is/ the place to start looking.

-- Lawrence Garvin, M.S., MCTS, MVP-Software Distribution

12-01-2007 Bill RE: BITS update is failing That was it. I checked the HTTP 1.1 setting for the proxy server in IE Advanced settings and it works now.

And, yeah, WebOne is currently a HTTP 1.0 proxy. May be this is the reason of current incompatibility.

Workaround: Disable WebOne when using Legacy Update (Windows Update).

What's next? Try to modify WebOne to return HTTP/1.1 responses. If not successful, made proxy bypass for download.windowsupdate.com.

[atauenis]

Looked into traffic.

GET http://au.download.windowsupdate.com/c/msdownload/update/software/secu/2013/10/windowsserver2003.windowsxp-kb2893294-x64-enu_25ad5a20170b2ca965771c01a8c1e4dc55f3309b.exe HTTP/1.1
Accept: */*
Accept-Encoding: identity
Range: bytes=0-6361
User-Agent: Microsoft BITS/6.7
Host: au.download.windowsupdate.com
Proxy-Connection: Keep-Alive

HTTP/1.1 206 Partial Content
Cache-Control: public, max-age=172800
Via: HTTP/1.0 WebOne/0.15.1.0
Content-Length: 6362
Content-Type: application/octet-stream
Last-Modified: Tue, 22 Oct 2013 19:47:45 GMT
Accept-Ranges: bytes
Age: 0
ETag: "8086de935fcfce1:0"
Server: ECAcc,(ska/F761) Microsoft-HTTPAPI/2.0
X-CCC: SE
X-CID: 11
X-Powered-By: ASP.NET
Date: Sun, 12 Feb 2023 16:28:47 GMT

(the file goes below)

In a 206 response to request with Range header, the server must return Content-Range header. But WebOne cuts it somewere...

[atauenis]

Problem number 2. After few restarts of test machine, it tried to refresh WU cookies. And seems that it is not possible to access them via WebOne.

12.02.2023 19:47:58.810+571     Got a request.
12.02.2023 19:47:58.810+120576  >POST http://legacyupdate.net/v6/ClientWebService/client.asmx (192.168.56.102)
12.02.2023 19:47:58.810+936697  >Uploading 1K of text/xml (connecting)...
12.02.2023 19:47:58.810+4945077  ============GURU MEDITATION:
System.IO.InvalidDataException: The archive entry was compressed using an unsupported compression method.
   at WebOne.HttpOperation.SendRequest() in WebOne\HttpOperation.cs:line 144
On URL 'http://legacyupdate.net/v6/ClientWebService/client.asmx', Method 'POST'.
 Returning 500.============
12.02.2023 19:47:58.810+4952544 <Return code 500.
12.02.2023 19:47:58.810+5042006 <Done.

POST http://legacyupdate.net/v6/ClientWebService/client.asmx HTTP/1.1
Accept: text/xml
Content-Type: text/xml
Accept-Encoding: xpress
SOAPAction: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetCookie"
User-Agent: Windows-Update-Agent
Host: legacyupdate.net
Content-Length: 1444
Proxy-Connection: Keep-Alive

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"><soap:Body><GetCookie xmlns="http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService"><authCookies xmlns:q1="http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService" soapenc:arrayType="q1:AuthorizationCookie[2]"><AuthorizationCookie><PlugInId>PidValidator</PlugInId><CookieData>......

Even if change Accept-Encoding: xpress to any other, the WSUS server still tries to return content, compressed with xpress encoding.

This error is caused by standard violation by LegacyUpdate servers, which are returning the WU cookes only via HTTP, compressed with xpress algorithm. And it is not supported by System.Net.Http.HttpClient/SocketsHttpHandler/System.IO.Compression libraries, used by WebOne to connect to HTTP(S) servers. Opened a issue in Microsoft repo, waiting for response...

[atauenis]

Haha, problem nr.3. Disabled proxy, tried to download some updates directly from LegacyUpdate, then enabled the proxy again and rebooted the virtual machine.

The cookie is still alive, but wuident.cab became too old. And on attempt to get it, we're get an new error:

2023-02-13  13:42:36:553     712    a24 Misc    WARNING: GetServerFileSize failed. error 0x80072f76
2023-02-13  13:42:36:553     712    a24 Misc    WARNING: WinHttp: IsFileToBeDownloaded failed with 0x80072f76
2023-02-13  13:42:36:553     712    a24 Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f76
2023-02-13  13:42:36:553     712    a24 Misc    WARNING: DownloadFileInternal failed for http://legacyupdate.net/v6/selfupdate/wuident.cab: error 0x80072f76

Looking to HTTP traffic...

HEAD http://legacyupdate.net/v6/selfupdate/wuident.cab?2302131042 HTTP/1.1
Accept: */*
User-Agent: Windows-Update-Agent
Host: legacyupdate.net
Proxy-Connection: Keep-Alive

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Via: HTTP/1.0 WebOne/0.15.1.0
Content-Type: application/octet-stream
Last-Modified: Sat, 08 May 2021 08:15:41 GMT
Accept-Ranges: bytes
Age: 779769
ETag: "609648ad-6b98"
Vary: Accept-Encoding
Server: cloudflare Microsoft-HTTPAPI/2.0
CF-Cache-Status: HIT
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=lyYoANAW3ZufubI2H9LibdjbukqHdK%2BBJ8vH3%2FDuhHcUIEswW8qlHGcQwXfOGq9Bn7MGhxfDL2olcl6%2F9c9JQXuqlAJpWnL33STifkrqnbJvAOWI%2FLB5T8kVj%2B2hM9Edp226aoL2JNMmWa%2Bf7XlS"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
CF-RAY: 798cf5c30b5d37dd-FRA
Alt-Svc: h3=":443"
Date: Mon, 13 Feb 2023 10:42:38 GMT

(and NO body at all)

Tried to do same via telnet. And found that real server also returns Content-Length: 27544, but it is missing in WebOne HTTP response. Continuing to investigate.

[atauenis]

Latest news. Fixed Range header support, fixed Content-Length loss, and made strange workaround for xpress compression.

The last is experimental webone.conf [Server] option AllowHttpCompression. If set it to no, it disables automatic decompression of HTTP traffic, and somewhy reanimates work of WSUS/LU. But also it disables any gzip/deflate/br compression on other sites, so currently it's have default value yes (= all sites are fast, WSUS don't work).

Now at least LegacyUpdate is working correctly. Other WSUS servers also should.