Re: Caching Algorithms

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.

http://dancer.brisnet.org.au/patches/

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.

D

-- 
-----BEGIN GEEK CODE BLOCK-----
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-@ 
------END GEEK CODE BLOCK------