httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject RE: conserving file descriptors vs. ap_save_brigade()
Date Sat, 06 Jul 2002 19:30:40 GMT
On Sat, 2002-07-06 at 12:09, Ryan Bloom wrote:
> > From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> > 
> > On Sat, Jul 06, 2002 at 08:25:18AM -0700, Ryan Bloom wrote:
> > > > From: Justin Erenkrantz [mailto:jerenkrantz@apache.org]
> > > > 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.
> > 
> > <Pine.LNX.4.21.0205051824430.16421-100000@shell.ntrnet.net>
> > 
> > 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



Mime
View raw message