Bug#218760: acknowledged by developer (Re: Bug#218760: apt-get update doesn't check timestamps on already loaded "unstable" package files)
On Mon, 3 Nov 2003, Luke Kenneth Casson Leighton wrote:
> if apt-get update then reloads all of the unstable packages
> obtained so far then you have successfully reproduced the
> problem.
This particular bit of code has been unchanged for about 7 years so I'd be
surprised if it is broken somehow..
I just tried it with ftp.uk. I ctrl-c'd it during a fetch of
unstable/main, started it again and it resumed at the exact byte position
it left off. I let apt-get update finish, and ran it again, 0 bytes were
downloaded.
ftp.uk runs apache, which I know is not flawed, so I think it is something
specific to your configuration, quite possibly a broken transparent proxy.
They are surprisingly common :<
You can convince yourself of this by using an APT debug mode.
Place only ftp.uk.debian.org in your sources.list. Do
rm /var/lib/apt/lists/* /var/lib/apt/lists/partial/*
Run:
apt-get update -o Debug::acquire::http=true -qq &> /tmp/first
Then again:
apt-get update -o Debug::acquire::http=true -qq &> /tmp/second
The file first will contain output like this:
GET /debian/dists/unstable/main/binary-i386/Packages.gz HTTP/1.1
Host: ftp.uk.debian.org
Connection: keep-alive
User-Agent: Debian APT-HTTP/1.3
HTTP/1.1 200 OK
Date: Tue, 04 Nov 2003 04:14:55 GMT
Server: Apache/1.3.26 (Unix) Debian GNU/Linux PHP/4.1.2 mod_ssl/2.8.9 OpenSSL/0.9.6g
Last-Modified: Mon, 03 Nov 2003 20:20:17 GMT
ETag: "31d8f6-2987a2-3fa6b881"
Accept-Ranges: bytes
Content-Length: 2721698
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: application/binary
Content-Encoding: x-gzip
And the file second will contain output like:
GET /debian/dists/unstable/main/binary-i386/Packages.gz HTTP/1.1
Host: ftp.uk.debian.org
Connection: keep-alive
If-Modified-Since: Mon, 03 Nov 2003 20:20:17 GMT
User-Agent: Debian APT-HTTP/1.3
HTTP/1.1 304 Not Modified
Date: Tue, 04 Nov 2003 04:17:59 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
ETag: "1204062-2987a2-3fa6b881"
Now, what you want to see is that in the file second the If-Modified-Since
header exactly matches the Last-Modified header from the file first.
If it does not then we really need to ask why on earth didn't the mtime of
the file in the filesystem get set right. If it does match and the server
does not answer with a 304 Not Modified then you have an unclean path to
ftp.uk.debian.org that screws up the protocol.
Jason
Reply to: