On Wed, 2002-07-03 at 20:07, Ryan Bloom wrote:
> > From: Brian Pane [mailto:bpane@pacbell.net]
> >
> > On Wed, 2002-07-03 at 15:26, Ryan Bloom wrote:
> > > How big a problem is this really? Most of the time, the
> content-length
> > > filter isn't supposed to actually buffer the brigade. It should
> only be
> > > doing the buffering if we are doing a keepalive request and we can't
> do
> > > chunking.
> >
> > I'm seeing the buffering in non-keepalive tests, though.
>
> Then we have a bug. The C-L filter should only be trying to compute the
> C-L if we MUST have one on the response, and we don't have to have one
> in the non-keepalive case.
As it's currently implemented, the C-L filter is trying to compute
the C-L on everything by default. It only gives up in a few cases:
* More than 32KB of output buffered, and either
* A flush bucket in the brigade
* EAGAIN when trying to read from a pipe bucket
And in all of these cases, it it also requires either a non-keepalive
request or a client that supports chunked encoding in order to give up
on computing the length.
So if we have a long stream of small file buckets from an SSI request,
we'll never hit any of the conditions that cause the C-L filter to give
up trying to compute the C-L.
--Brian
|