[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.

GPG key available at: <http://www.robertcollins.net/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: