On Sat, 2002-07-06 at 12:09, Ryan Bloom wrote: > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > > > On Sat, Jul 06, 2002 at 08:25:18AM -0700, Ryan Bloom wrote: > > > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] > > > > Of course, in the common case of a static file with no filters, we > > > > already know the content-length (default handler sets it). > > > > > > > > IIRC, I've brought up skipping the C-L filter when we already know > > > > the C-L (as defined by r->headers_out), but that was not met with > > > > approval. > > > > > > Who didn't approve that? I was under the impression that we did > skip > > > the C-L filter if we already had a C-L, and it was the filters > > > responsibility to remove the C-L if it was changing it. > > > > <[EMAIL PROTECTED]> > > > > I don't know who might have said that. =) -- Justin > > Pay attention to what that message says please. It says "The filter > should always be in the stack, and it should always collect > information." It doesn't say "The filter should always be touching the > C-L for the response." We use the data collected by the c-L filter in > other places, so we should always try to compute the C-L in the filter. > However, we should NEVER buffer unless we absolutely have to.
Agreed. But what are the circumstances in which we absolutely have to buffer? I suppose keepalive requests for clients that don't support chunked encoding are the canonical absolutely-must-buffer case. But even there, I'd rather force a "Connection: close" in cases where the buffering is going to cause performance problems or cause us to run out of file descriptors. --Brian
