Bug#203741: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)
On Fri, Jan 02, 2004 at 02:13:08PM -0500, Anthony DeRobertis wrote:
> On Jan 1, 2004, at 21:52, Matt Zimmerman wrote:
>
> >>Squid is certainly within its rights to not fetch a new version of
> >>Packages.gz and Sources.gz while fetching the new Release file, and it
> >>seems it happens. Especially with the amount of transparent proxying
> >>that exists in the wild, this could be a problem...
> >
> >A cache which serves stale data is a broken cache.
>
> No, it isn't. That's how a webcache is supposed to work.
I'm afraid not. Caches must return data which is "fresh enough" according
to the requirements of the various parties involved, and therefore by
definition, must not serve stale data.
APT sends a Cache-Control: max-age header which must be honored by compliant
caches. It turns out that this was not actually being sent for Release with
the new code, and that is now fixed in 0.6.11. This is not perfect either,
but should help. Unfortunately, max-age is not exactly what we want.
> > I think that apt is within its rights to expect a consistent view from
> > the world.
> No. See RFC 2616, Chapter 13. HTTP explicitly does not guarantee this.
APT is doing the best that it can with the available HTTP mechanisms. There
is no way for APT to be perfect in this respect without going to
unreasonable lengths (such as separate no-cache HEAD requests to check
last-modified).
If you have a solution, by all means, describe it. And no, I won't take you
seriously if you suggest that apt should use no-cache for everything.
> > You would see other failures if you got mismatched versions of Release
> > and Release.gpg.
>
> Yep. And apt needs to be fixed to guarantee that doesn't happen.
Patches welcome.
--
- mdz
Reply to: