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
> 



Reply via email to