Re: Caching Algorithms

From: Dancer <>
Date: Thu, 13 Aug 1998 14:25:14 +1000

Marc Haber wrote:
> On Thu, 30 Jul 1998 13:43:15 -0600, you wrote:
> >If a site tells a cache that it doesn't want to be cached or tells a cache that
> >it wants to expire after a certain period of time, there is probably a good
> >reason for it.
> Yes, but I would vouch for a configuration option to ignore expiration
> or do-not-cache-settings on a per-url-match basis. I really would like
> to ignore that reason if it is only to increase the hit rate or to
> transmit a new commercial (which is promptly killed by junkbuster
> afterwards).
> It's like the Expired:-Header in a news posting: A hint how the
> article would like to be handled. But it's _my_ system, I would like
> to control what happens on _my_ disk.

Specifically the immortality patch. Setting the max to 1 in a
refresh_pattern (eg: refresh_pattern/i .zip$ 1 100% 1) makes sure that:
* Once fetched, the object is cached.
* Once cached, it will never be checked, and the object will _always_ be
a TCP_HIT until the cache pushes it out to make space for something more
recent. Nothing the client can do will cause it to be checked or
reloaded or in any way refreshed.

This is a gross violation of HTTP. This is handy for objects which do
not change content without also changing filenames.

May cause your users grief. May cause hair-loss in pets and the elderly.
Keep out of reach of children. No warranties expressed or implied. Code
may not be the Holy Grail(tm). Code may eat your disk, your dog, and
cause the sun to go nova. Shakespeare was right about the lawyers.


Version: 3.1
GAT d- s++: a C++++$ UL++++B+++S+++C++H++U++V+++$ P+++$ L+++ E-
W+++(--)$ N++ w++$>--- t+ 5++ X+() R+ tv b++++ DI+++ e- h-@ 
Received on Wed Aug 12 1998 - 21:27:21 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:41:30 MST