httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Date Fri, 31 Aug 2001 20:26:32 GMT
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          IanH@cnet.com
Performance Measurement & Analysis
CNET Networks   -   (415) 364-8608


Mime
View raw message