httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Date Fri, 31 Aug 2001 20:17:34 GMT

> 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.

>
> 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.
>
> 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


Mime
View raw message