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>]

stoddard@apache.org wrote:

>   Add content negotiation and expiration policy to mod_cache and mod_mem_cache.
>   mod_disk_cache still needs work.

In the original cache design, the cache was able to cache more than one
variant of a specific URL. If an english page came along, it would cache
the english page. If a french page came along, it would cache the french
page alongside the english page. If a browser was returned cache data,
content negotiation would be used to select the best cached variant.

As a result of the above I am confused why "content negotiation has been
added to mod_cache" - isn't content negotiation built in already?

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

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..."

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

[Bill Stoddard <bi...@wstoddard.com>]

> stoddard@apache.org wrote:
>
> >   Add content negotiation and expiration policy to mod_cache and mod_mem_cache.
> >   mod_disk_cache still needs work.
>
> In the original cache design, the cache was able to cache more than one
> variant of a specific URL. If an english page came along, it would cache
> the english page. If a french page came along, it would cache the french
> page alongside the english page. If a browser was returned cache data,
> content negotiation would be used to select the best cached variant.
>
> As a result of the above I am confused why "content negotiation has been
> added to mod_cache" - isn't content negotiation built in already?
>
> Regards,
> Graham

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.  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 :-)

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...

Bill