Cache-Control: max-age sent by apt might delay installation of security updates (was: apt experimental breaks w/ webcaching)

[Marc Haber <mh+debian-devel@zugschlus.de>]

On Fri, 16 Jan 2004 18:23:44 -0800, Matt Zimmerman <mdz@debian.org>
wrote:
>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.

Greetings
Marc

-- 
-------------------------------------- !! 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