Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[Graham Leggett]

Justin Erenkrantz wrote:

> handler--->content-filter->cache-filter->transfer-filter->network
> (default)  (mod_include,   (mod_cache)   (mod_gz{ip},     (core)
>             mod_php)           ^          mod_proxy,
>                                |          byte ranges)
>                          can short-cut
>                   handler and content-filters

Almost - mod_proxy is a handler, not a transfer filter (otherwise you
could never cache proxy requests):

Basically, there are three "states" of operation, answering the question
"is this URL cached" with the answers "yes", "no" and "maybe". The
mod_cache handler works out each "state", and in each "state", the
filter stack is set up to look like this:

o NO - a virgin URL

handler -> content -> CACHE_IN -> transfer -> core
(mod_cache (mod_include           (mod_gzip,
mod_proxy   mod_php)               BYTERANGE)
mod_core)

o YES - a cached URL

handler -> CACHE_OUT -> transfer -> core

o MAYBE - a stale URL

handler -> content -> CACHE_CONDITIONAL -> CACHE_IN|CACHE_OUT ->
transfer -> core

To sum up, the cache is always first and last (last except for transfer
encodings) so ordering of content filters should not matter to
mod_cache.

Regards,
Graham
-- 
-----------------------------------------
[EMAIL PROTECTED]                "There's a moon
                                        over Bourbon Street
                                                tonight..."

S/MIME Cryptographic Signature