Re: Expires: headers for Packages.gz, Sources.gz
On Fri, Feb 09, 2001 at 11:00:57PM -0700, Jason Gunthorpe wrote:
> On Sat, 10 Feb 2001, Matt Zimmerman wrote:
> > max-age. However, max-age=1 day will not have the same effect as the
> > Expires: header I proposed. Unless I am mistaken, max-age refers to the
> > maximum time since the object was last refreshed (newly retrieved or
> > IMS/Not Modified).
>
> 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
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
IMS request should still keep it from being downloaded again.
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.
Some users don't have a choice about using a caching proxy, and others
(including me) would like to take advantage of one to increase performance for
a bunch of Debian systems on the same network.
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.
> Really though, the way APT does IMS queries they are *cheap*, even setting a
> 0 max-age for your cache should not cause noticable performace problems.
True, that should fix things for APT, but what about other programs? I have a
makefile that runs wget to fetch its own copy of Sources.gz to import priority
standard and higher packages into a CVS repository. Why not fix the problem
once and for all on the server side?
--
- mdz
Reply to: