On Fri, 2001-08-31 at 13:17, Bill Stoddard wrote:
>
> > On Friday 31 August 2001 11:48, Graham Leggett wrote:
> > > Bill Stoddard wrote:
> > > > How do you handle things like byterange requests if CACHE_IN is a network
> > > > filter? The byterange filter will filter out all but the range requested
> > > > so the CACHE_IN filter will never see the full response. Ditto the
> > > > output chunking filter. Also, there could be various content translation
> > > > filters installed in the filter stack (ASCII <--> EBCDIC, language
> > > > translation, whatever. The list is indeterminate so we cannot reliably
> > > > put code into CACHE_IN to detect these conditions and not cache.
> > >
> > > Hmmm - ok...
> > >
> > > Part of the job of cache_storage.c is to handle optimisations. What
> > > CACHE_IN can do is apply mod_gzip before delivering the content to the
> > > cache, and if necessary mod_gunzip can be applied by CACHE_OUT before
> > > delivery to any browser who did not negotiate a gzip encoding.
>
> I'm a bit fuzzy on how to run the GZIP filter from CACHE_IN but I assume something
>clean
> can be done. Detecting if the client supports unzip and conditionally installing
>GUNZIP is
> simple and should just work without resorting to anything unnatural.
(hmm.. did someone apply my GZIP filter contribution??)
>
> >
> > My own opinion is that the cache should be the last content filter run. Basically,
> > it should probably be specified as the first HTTP_HEADER filter type.
not necessarily.
we have a situation where we need to uniquly modify outgoing HTML to
insert ads and tracking things into the HTML (which is different for
each user)
we would mod_cache in the middle of the content chain.
(ie cache the result from the CGI/proxy call) and then run a mod-include
filter on top of that (possibly pushing the result through gzip)
> >
> > Ryan
>
> I was playing around with AP_FTYPE_CONTENT+1 :-) yes, it's a hack. Maybe introduce
> AP_FTYPE_CACHE and position it right between CONTENT and HTTP_HEADER to prevent any
> clashes with third party modules... I am concerned about module FTYPE clashes in
> general... We should keep to a minimum the cases where a filter relies on relative
> position within its FTYPE class.
>
> Bill
--
Ian Holsman [EMAIL PROTECTED]
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
