[EMAIL PROTECTED] wrote:
> Well almost, but not quite. In order to do this, the proxy would need to
> be its own protocol server, and that just isn't going to happen. I'll
> outline my design in another note.
Ok.
> It isn't close at all. My prototype module is basically just a filter
> that directs the data to the disk, and even doing that it is broken,
> because it always uses the same file. :-) I had wrtten this to allow it
> to be thrown into the existing cache code, but that cache code is very
> difficult to track, so I gave up. :-)
I had this problem when I did the HTTP/1.1 patch - I rewrote much of the
core stuff within the proxy.
> What still needs to be done to mod_cache.c:
>
> The abstraction needs to be put in so that multiple cache back-ends can be
> used. This requires abstracting out:
>
> get_cache_location
> cache_read
> cache_write
> cache_open
Multiple backends I assume means a shared memory backend, a disk
backend, etc?
> Cache entries should be stored in a hash table that uses the key values:
>
> hostname:port/URI
>
> The handler just checks the hash and sends the file if it is there.
What I want to do is build in content negotiation into that as well. In
other words, you provide hostname:port/URI *and* the request headers,
and based on both you get a response back. This will allow you to cache
both an English and French representation of the same URL, or a
compressed and non-compressed representation of an URL at the same time.
> Once the handler is written and the filter can get the correct location to
> save the cached data, this module is done.
This effectively represents the caching filter part of the design I
proposed. What is needed now is a content-generator entity that
optionally returns cached data if it exists, or DECLINED if not.
These two together will make the start of a working cache.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
