> 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.
Sounds good to me. > 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? Depends on some other projects I have to do. I would hope to post the code either late today or tomorrow sometime. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
