httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: [PATCH] buff.c bug fix
Date Sat, 25 Jan 1997 08:59:39 GMT
I've mailed Henrik to ask him to help me reproduce the bug.  I wasn't able
to do it against my server, but I was just force feeding it a hand-made
set of GET/HEADs and eye-balling the result.  The buff.c patch I gave
probably won't help the problem at all. 

I'll make up a patch for the flush() behaviour.  Something like a call
into the buff.c code to either test the buffer or do a select() and answer
yes-no if there's data waiting.

I'm moderately concerned about DoS attacks without some limit on
keep-alive sessions.  Emphasis on moderate.


On Sat, 25 Jan 1997, Alexei Kosut wrote:

> On Fri, 24 Jan 1997, Dean Gaudet wrote:
> []
> > I've been looking into this one.
> Good! Glad someone has.
> > So far I can see a definite bug in bcwrite().  It's probably due to
> > the assumption that if r=write(f,b,n) then r is one of -1, or n unless
> > f is non-blocking.  That isn't the case, all values -1 <= r <= n are
> > possible for any f.  I notice later on in bwrite() that it also indicates
> > that assumption... but the bwrite() code looks ok on my first reading.
> Okay... the patch you provide seems to compile and run fine, although
> I don't know if it fixes the problem. How about we put it into 1.2b5,
> and I can email Henrik and ask him if he'd mind running his test again
> on it?
> On a related note... Henrik's other point: The flush that we call
> before going into keep-alive state (waiting for another request)
> causes performance problems (a lot of them, apparently) when
> pipelining requests - but causes functional problems if not. We had
> discussed checking to see if there was any input waiting to be read,
> and if there was, not flushing, otherwise, flush away. Did anyone ever
> look into this furthur, to the point of having a patch for it? I would
> myself, but TCP and things like that aren't what I do
> best. BTW, specifically, he's talking about the bflush() calls at
> lines 1676 and 2145 of the current http_main.c.
> Another thing he mentions about Apache is something I had always meant
> to change, even back in 1.1... that Apache requires you to cut off a
> kept-alive connection after a certain number of requests, and that it
> defaults at five (which is a ridiciously low number, when you stop to
> think about how the Web is currently). Originally, this was done
> because (in an early development version of 1.1), Apache used the same
> pool for all the requests in a connection, which could eat up quite a
> lot of memory. This was, however, changed, and near as I can tell,
> there's no real reason why we should keep it around. Ideally, we'd use
> the NCSA model; KeepAlive On|Off (though we could support numbers as
> well, for backwards compatibility - they'd be equivilent to "On"). I
> suppose it's a bit late in the beta cycle to do that, but it's a
> thought. Anyone?
> Thanks.
> -- 
> ________________________________________________________________________
> Alexei Kosut <>      The Apache HTTP Server
> URL:

View raw message