Re: cvs commit: httpd-2.0/modules/experimental cache_storage.c cache_util.c mod_mem_cache.c mod_cache.c mod_cache.h

[Graham Leggett <mi...@sharp.fm>]

Bill Stoddard wrote:

> The cache still does not support caching multiviews of an object. A lot of the
> infrastructure is there but the code has not been written.

Ok... the idea behind the caching engine was for it to be handed the
variant along with the complete header set. The caching engine would
then decide based on the headers (content negotiation) whether this
variant should replace an existing variant, or be cached alongside
existing variants.

When the variant was served from the cache, again content negotiation
would be used to determine whether a cached variant is the most
relevant, or whether the request must be passed through.

>  My commit fixed an RFC2616
> violation; we were placing negotiated documents (responses containing a Vary: header) in
> the cache but we were not saving the original request headers and we were not making the
> checks to to keep us from serving up negotiated content incorrectly. It can certainly be
> substantially improved :-)

Ok.

> In your design, where did the code that did the content negotiation live?   Were you
> envisioning maintaining a cached *.var file then issuing a subrequest against that .var
> file to drive content negotiation? There are a lots of possibilities...

I didn't give too much thought on how it would practically work -
however using the existing content negotiation framework would save a
lot of time. Would the cache files then be saved in the same format as
expected by the content negotiation subsystem...? Would it support both
languages and different compression options...?

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."