Unfortunately the time-stamping saga continues ;-) In the time-stamping mode wget always issued first a HEAD request when there was a local file, and later a GET request when after inspecting the HEAD outpout it found out that it should do so.
The wget 1.11 now *always* does the HEAD request, so this problem may be a little related to the other just-repaired problem. The error, however, is that it now uses the time-data from the HEAD output as timestamp for the local file and not the time-data from the GET request. This could theoretically even be a problem with a direct site-transfer, when the remote file changes between the HEAD and the GET, but the pratical case where it occured is in connection with a proxy-cache. When the proxy-cache has a cached file-copy which is older than the file on the orginal site, the HEAD delivers the data from the cached file, but when upon the GET the proxy itself decides to retrieve the newer version (or is forced to do that with the wget --no-cache option) we get the discrepancy: we get the *newer* file downloaded but with the *older* time-stamp. And a real-life example to illustrate the issue: HEAD -p http://wwwcache.uni-koeln.de:8080 http://www.extractnow.com/extractnow.exe 200 OK Date: Wed, 23 Aug 2006 12:15:42 GMT Accept-Ranges: bytes Age: 165431 ETag: "98caa15d43c4c61:4da" Server: Microsoft-IIS/6.0 Content-Length: 981504 Content-Type: application/octet-stream Last-Modified: Sun, 20 Aug 2006 10:28:23 GMT Client-Date: Sun, 27 Aug 2006 10:03:17 GMT Client-Response-Num: 1 Proxy-Connection: close X-Cache: HIT from wwwcache.uni-koeln.de X-Powered-By: ASP.NET HEAD http://www.extractnow.com/extractnow.exe 200 OK Date: Sun, 27 Aug 2006 10:05:10 GMT Accept-Ranges: bytes ETag: "4e9432fc57c9c61:4da" Server: Microsoft-IIS/6.0 Content-Length: 983005 Content-Type: application/octet-stream Last-Modified: Sat, 26 Aug 2006 21:38:35 GMT Client-Date: Sun, 27 Aug 2006 10:05:09 GMT Client-Response-Num: 1 X-Powered-By: ASP.NET The two HEAD (HEAD utility from the lwp-package) requests show that the cache has a file version from 20 Aug 2006 and the site has a file version from 26 Aug 2006 wget.111b1 -d http://www.extractnow.com/extractnow.exe DEBUG output created by Wget 1.11-beta-1 on linux-gnu. --12:06:18-- http://www.extractnow.com/extractnow.exe Resolving wwwcache.uni-koeln.de... 134.95.19.61 Caching wwwcache.uni-koeln.de => 134.95.19.61 Connecting to wwwcache.uni-koeln.de|134.95.19.61|:8080... connected. Created socket 3. Releasing 0x08086950 (new refcount 1). ---request begin--- HEAD http://www.extractnow.com/extractnow.exe HTTP/1.0 User-Agent: Wget/1.11-beta-1 Accept: */* Host: www.extractnow.com ---request end--- Proxy request sent, awaiting response... ---response begin--- HTTP/1.0 200 OK Content-Length: 981504 Content-Type: application/octet-stream Last-Modified: Sun, 20 Aug 2006 10:28:23 GMT Accept-Ranges: bytes ETag: "98caa15d43c4c61:4da" Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Wed, 23 Aug 2006 12:15:42 GMT Age: 165612 X-Cache: HIT from wwwcache.uni-koeln.de Proxy-Connection: close ---response end--- 200 OK Length: 981504 (958K) [application/octet-stream] Closed fd 3 --12:06:18-- http://www.extractnow.com/extractnow.exe Found wwwcache.uni-koeln.de in host_name_addresses_map (0x8086950) Connecting to wwwcache.uni-koeln.de|134.95.19.61|:8080... connected. Created socket 3. Releasing 0x08086950 (new refcount 1). ---request begin--- GET http://www.extractnow.com/extractnow.exe HTTP/1.0 User-Agent: Wget/1.11-beta-1 Accept: */* Host: www.extractnow.com ---request end--- Proxy request sent, awaiting response... ---response begin--- HTTP/1.0 200 OK Content-Length: 983005 Content-Type: application/octet-stream Last-Modified: Sat, 26 Aug 2006 21:38:35 GMT Accept-Ranges: bytes ETag: "4e9432fc57c9c61:4da" Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Sun, 27 Aug 2006 10:06:20 GMT X-Cache: MISS from wwwcache.uni-koeln.de Proxy-Connection: close ---response end--- 200 OK Length: 983005 (960K) [application/octet-stream] Saving to: `extractnow.exe' 100%[================================================================>] 983,005 265K/s in 3.6 s Closed fd 3 12:06:22 (265 KB/s) - `extractnow.exe' saved [983005/983005] And the result on the local disk: ....... 983005 20.08.2006 12:28 extractnow.exe The filesizes show that the newer version was downloaded but it got the time-stamp of the older one. Btw, a quick work-around is to download it a second time, the cache has now the newer file with newer file data, wget requests it new because it now sees the local file as older, the file is retrieved directly from the cache and gets the correct time-stamp now ;-) Best regards, Jochen Roderburg
