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: