Re: Expires: headers for Packages.gz, Sources.gz
On Sat, 10 Feb 2001, Matt Zimmerman wrote:
> > If you use Expires in the absolute mode then you are correct, however that is
> > not a good idea because of timezone skew on the mirrors, and the fact that we
> > don't actually update our package files every day unless they have changed.
>
> I don't see what effect timezone skew would have...Expires: contains the time
> zone information. If the object is expired after 24 hours, but the file hasn't
It does in HTTP, most of our mirrors are FTP based and have a nasty habit
of adding hours to the times, this totally wacks the whole idea of using
absolute Expires headers.
> been updated, I'm not sure how that's handled. What happens when an object's
> expiration time (as specified by the origin) is in the past? At any rate, an
Then the cache has to IMS every query.
> I don't see how using Expires: could possibly make things worse than
> they are now, and it seems like it would do a lot to help caches do the
> right thing more often.
Expires make it so things like stable (which has static package files)
will always result in a IMS query, instead of 1 every day, as it is now.
> Come to think of it, .deb's should get a very long expiry time, as they should
> never change. RFC2068 recommends using an expiry time one year from the
> response time.
The default expiry mechanisms in a cache should handle this case well
enough. DEBs do expire BTW, not their content, but the value in keeping
them (we churn DEB files at the rate of ~150 meg/day in the archive)
> import priority standard and higher packages into a CVS repository. Why
> not fix the problem once and for all on the server side?
Er, we have about 170 mirrors. Having even a noticable fraction of them
insert expires headers that are worthwhile just isn't going to happen.
For us the best solution is to let the clients do it because that is the
side we control.
BTW, you can use apt-get to fetch those source files for you..
Jason
Reply to: