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

Re: apt experimental breaks w/ webcaching (was Re: apt 0.6 in experimental)

On Jan 2, 2004, at 14:47, Matt Zimmerman wrote:

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.

Sorry about that. I was using stale to mean "data in cache is older than what the application expected", not "older than what the protocol allows."

[ I was looking at apt < 0.6.11 when I made that statement, and certainly that older apt was getting data older than it wanted, due to failing to send Cache-Control. ]

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.

I'm not going to suggest that, because that would be silly. We can both agree on that!

Would it be possible to have the mirrors use Expires: headers to make sure the files all expire at the same time?

Some other suggestions:
	o Check for time skew, do max-age 0 if-modified-since to fix.
probably won't work, reload http://http.us.debian.org/debian/dists/testing/main/binary-alpha/ a few times to see why. (modified times are
	  apparently not sync'd).

	o Keep yesterday's md5sums in the Release file. Either go ahead
	  silently with the old packages.gz files, or do a max-age 0 to
	  get current versions.

	o Similar to the first one, add sequence numbers to the files.
	  Force a refresh on old sequences.

Yep. And apt needs to be fixed to guarantee that doesn't happen.

Patches welcome.

Ugh, you're gonna make me become an apt-hacker, aren't you? ;-)

Reply to: