httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c
Date Fri, 31 Aug 2001 20:21:32 GMT
On Friday 31 August 2001 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.
>
> > 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.

That is why I think it should happen as the first HTTP_HEADER filter.  This filter
is essentially dealing with meta-data, whether the data can be cached, and 
this FTYPE is essentially used to indicate that all meta-data has been
generated by the time this filter type is hit.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message