| Robert Collins 2004-02-28, 5:33 pm |
| 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>.
|