Graham Leggett wrote:
> 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):
>
just to add my 2c to the picture.
I dont see why the cache-filter could not live anywhere in the filter chain
it could sit just after the handler (where it could cache a report generator)
which would then feed into php/include
it could sit after php/include and possibly after the gzip/byte ranges as well.
the thing it needs to do, (which I haven't seen yet) is address how it uniquely
identifies what is the same request.
It needs to be cofigurable so that it could use the
* incoming vhost+request (simple case)
* the user agent
* a cookie value (or part of)
* any part of the incoming request header.
so.. you might have something like
SetOutputfilter CACHE INCLUDE GZ
CACHECRITERIA REQ, UserAgent
or
SetOutputFilter INCLUDE GZ CACHE
CACHECRITERIA REQ, Cookie: Foo+8 (last 8 bytes of Foo)
..Ian
(on a side note this would be a great way to implment Edge Side Includes
in 2.0 http://www.esi.org)
> 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
>