httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: Apache 1.2b7-dev performance
Date Sun, 09 Feb 1997 07:51:21 GMT
Marc Slemko wrote:
> On Sat, 8 Feb 1997, Ben Laurie wrote:
> > Marc Slemko wrote:
> > > 
> > > Hang on a minute here.  lingering_close() is NOT just intended to fix a
> > > problem with PUTs.  As I have said before, there are other workarounds
> > > which can be done to solve the PUT problem without lingering_close() and
> > > there are other workarounds to solve the SVR4 problem where sockets are
> > > destroyed on close() before the data is sent.  If those were the only
> > > problems, we could get rid of lingering_close().
> > > 
> > > The problem is persistent connections.  There are times when the server
> > > closes the connection.  The main ones are:
> > > 
> > > 	- keepalive timeout
> > > 	- "unusual" response that results in the server closing the
> > > 	  connection.  Currently for Apache those include things like
> > > 	  server errors, redirects. etc.
> > > 	- max number of requests per connection; used to be a big
> > > 	  issue, but not anymore unless someone sets that low.
> > > 
> > > Whenever the server closes the connection, there is a risk of the 
> > > client getting an error if it tries to send data before it knows the
> > > connection is closed.
> > 
> > But the question is, why do we care if the client gets an error? After all, we
> > got an error already...
> Because closing a keepalive connection is NOT an error; there may have been
> an error for one request (but not necessarily , since there are
> other conditions), but that doesn't mean others should get errors.
> The client should retry the requests which have not yet been answered
> in a new connection if the connection is closed before the client
> gets a response.
> However, if the client gets a RST it is treated as a TCP connection 
> error and it will likely whine based on the return from the TCP stack.
> It will NOT necessarily retry if it gets an error from the TCP stack.
> This is client dependent and some clients may quietly retry even
> when they get a RST but they may not.

Hang on, this is getting more and more tenuous. You're saying that we should
use lingering close because under some circumstances a broken client (don't
forget there is a clean way to close a keepalive under HTTP/1.1) _may_ get an
error, and _may_ consequently display an error. And then, oh my god, the user
would have to click a link for a second time. And for this, we are supposed to
take a 20% or worse performance hit, and force everyone to reboot every two
days, and make every major Unix vendor patch their TCP/IP stack?

If all that is required to fix this is a client that retries silently, I'd say
we should let them fix the clients. Even if they don't it isn't the end of the



Ben Laurie                Phone: +44 (181) 994 6435  Email:
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL:
A.L. Digital Ltd,         Apache Group member (
London, England.          Apache-SSL author

View raw message