Cache-Control: max-age sent by apt might delay installation of security updates (was: apt experimental breaks w/ webcaching)
On Fri, 16 Jan 2004 18:23:44 -0800, Matt Zimmerman <firstname.lastname@example.org>
>apt 0.6.11+ sends an appropriate Cache-Control: max-age header, so if the
>cache honors it (and the standard requires this),
Can you please explain "aproppriate"? apt 0.5.21 seems to always send
Cache-Control: max-age: 86400 which I consider inappropriate. How does
apt 0.6.11 calculate the max-age header?
The problem that I see is the following: From what I have understood
and tested, squid will not even ask the server addressed in the URL
for a later version if the object in the local cache is younger than
the max-age value given by the client.
This means the following: If a client does apt-get update via a squid
at time x, and Debian issues a security update at time x+10m, all
clients using this squid instance and apt 0.5 will not get that
security update until x+86400s, which might be 86399 seconds too late.
In my humble opinion, the default value for Cache-Control: max-age
needs to be much lower, in the range of a few minutes. If we don't
lower that default value, our mirrors should issue Expires-Headers
with a much shorter time to live on Packages files. This _especially_
goes for s.d.o.
I'd appreciate comments about this, as I might be misled.
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29