From: "Bill Stoddard" <[EMAIL PROTECTED]>
Sent: Tuesday, September 04, 2001 10:02 AM


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

That works for me ... I'd agree, if this is what it looks like;

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

FTYPE_CONTENT >>>

> > > Includes and other Filters
> > >  V
> > > Charset Translation (Transform to Client's preference)
> > >  V
> > > Content Encoding (gz) (Body - large packets - higher compression)

<<< END FTYPE_CONTENT

> > >  X <<< cache here
> > >  V
> > > Byterange

> > >  V

I forgot to insert about here...

      Transfer-Encoding (gz) (Really unsupported today by any clients per Kiley)
> > >  V
> > > Chunking
> > >  V
> > > Headers
> > >  V
> > > SSL Crypto
> > >  V
> > > Network I/O
> > >
> > >
> > >
> >
> 
> 

Reply via email to