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
