www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Current plan
Date Mon, 13 Nov 2000 17:35:15 GMT
rbb@covalent.net wrote:

> Great.  You and I are on the same page.  You posted something to new-httpd
> about a new caching framework, that uses filters.  Let me add to it.  :-)


> I will post the filter when I get a chance to clean it up a bit more.  I
> am not going to bother putting in the logic to figure out the correct
> filename for the cache, but I do want to make it obvious how different
> data stores can be plugged in.

One important thing I wanted the caching framework to handle is that of
content negotiation. Previously the cache design in mod_proxy made the
assumption that each URL had one possible return object, which is an
incorrect assumtion. Trying to add kludges to handle this only made it
all uglier and more difficult to understand. 

The way I see it is that all cache entries should be stored by URL. If I
want to retrieve a cache entry, I provide an URL and request headers.
The cache then decides on the request headers whether a version of the
cached object is in the cache. To place an entry in the cache, the
response headers will determine whether the newly cached object should
replace an existing object (if it's the same) or should be stored
alongside the existing object (if the object is a different
representation). At this stage various optimisations can be introduced
giving the system a little added intelligence: If an uncompressed object
is requested, and a compressed object is in the cache, then return the
cached object via the decompression filter instead of return a cache
MISS and generating the request from scratch.

How long till we see the code?

minfrin@sharp.fm		"There's a moon
					over Bourbon Street

View raw message