>
> 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.
Are you referring to the fact that a single URL may actually represent multiple views
(and
perhaps multiple cache entries)?
I believe Graham's idea was to allow caching multiple views using the same URL.
Searching
the cache using a URL as key would return a collection of cache objects.
cache_select_url() would negotiate across the collection to determine which object, if
any, should be served. An alternate solution would be to cache content using complex
search keys, rather than just the URL (i.e., don't return collections, only unique
single
cache objects).
>
> 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)
>
We need a whole new class of configuration directives to control how cache search keys
are
built. For ESI (and other HTML tag driven caches) you would probably want to allow
dynamically constructing a rule set that contains rules for building search keys.
cache_select_url() would use the rule set as a guide for building sophisticated search
keys using cookies, request parameters, etc. The rule set could be built at startup
based
on config directives or at runtime based on whatever runtime criterion you choose.
Interesting stuff...
Bill
