On Sun, 2004-02-29 at 07:10, Marc Haber wrote: > 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. Thats incorrect. max-age tells squid it MUST revalidate entities with an age >= the max-age value. If squid considers an entity stale it will revalidate it regardless - and your local squid config can tune when this occurs. > 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. See above for why this is wrong. > 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. apt-get should issue cache-control: max-age=0 for metadata files. (Packages/Releases). It should also provide the cache validators and use conditional requests, this will allow some potential (correctness-preserving) optimisations if the cache's current entity differs from apt's, but apt's is correct. Do not issue Expires headers unless you can predict when the Metadata files will change. Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
Attachment:
signature.asc
Description: This is a digitally signed message part