> I agree with this. Our current AP_FTYPE_* classifications is not granular enough to
> support this but that is easily fixed. Patch on the way...
>

Err.... or not. Jeff convinced me that it was premature to add additional AP_FTYPES. 
For
now, everything FTYPE_HEADERS (cache, content encoding, charset translations, et. al.)
should be an FTYPE_CONTENT filter.

Bill

> Bill
>
> > A transfer encoding isn't a byterange or chunking output.  It's a compression
> > scheme, and that we _want_ to cache, to avoid the cpu overhead.
> >
> > Handler (e.g. Core/autoindex/mod_webapp etc)
> >  V
> > Includes and other Filters
> >  V
> > Charset Translation (Transform to Client's preference)
> >  V
> > Content Encoding (gz) (Body - large packets - higher compression)
> >  V
> >  X <<< cache here
> >  V
> > Byterange
> >  V
> > Chunking
> >  V
> > Headers
> >  V
> > SSL Crypto
> >  V
> > Network I/O
> >
> >
> >
>

Reply via email to