Greg Marr wrote:
> How exactly do you use Cache-Control directives so that the content that
> is cached is before includes are processed, and that when it is
> retrieved from the cache, the includes are processed? It just doesn't
> work that way. In this case you have to put the includes before the
> cache.
mod_cache and mod_include should have no knowledge of each other.
mod_cache is interested in content going to the browser. There are
already two caches in the loop (a transparent ISP cache, and the browser
cache) so if mod_include doesn't generate proper Cache-Control: headers
then mod_includes is broken already without any help from mod_cache.
Any Cache-Control headers generated by CGIs (or whatever) embedded in
includes should already be combined intelligently into the final output
result otherwise mod_include is broken now.
> > mod_cache should behave exactly like a transparent cache would.
>
> In your application, yes, not in the one in question.
I don't see any reason why mod_cache should interfere with mod_include
(or vice versa). mod_cache only cares about what is spat out at the end
of the filter chain - how that filter chain is constructed is not
important to mod_cache (or any transparent cache or browser cache) at
all.
One of the fundamental design points about mod_cache was to separate it
from all other modules (specifically mod_proxy). Tying mod_cache
behaviour to mod_include (or any other module) is a step backwards in
the design.
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
S/MIME Cryptographic Signature
