httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: more lingering_close...
Date Sun, 09 Feb 1997 19:30:55 GMT
Marc Slemko wrote:
> One might expect that the server would not generate RSTs to packets until
> the client had closed its half of the connection; at the time the
> server sends the RSTs, the connection is only half-closed.  However,
> that isn't the way it happens.

Hang on. I understood up to this point (finally), but surely this is wrong?
If the server isn't doing an l_c(), then it won't have half-closed at this
point, it will have full-closed, and hence the RST's are exactly what is
expected. In this case, we should definitely half-close (which is surely the
point of l_c()?), or wait for the client to complete their send (which may be
lame - but since the spec doesn't give us a slot at this point in the protocol
to say "OK" or "Oops", we shouldn't really be talking or closing connections

It seems to me that this is really a deficiency in the HTTP spec - in that the
spec leaves us in a situation where it isn't clear whose turn it is to speak.
But I don't suppose it is fixable before HTTP/2.0...

> *** THIS IS IMPORTANT: *** When the client gets the RST, the RST
> includes the sequence number of the last packet from the server
> ACKed by the client at the time the RST was sent.  The client WILL
> normally flush any buffered incoming data received from the server
> after that sequence number.  This means that if the client is to
> reliably get the entire error message to display, the server MUST
> NOT send a RST until it has received an ACK of the last packet in
> the error message it sends to the client.  Nothing the client
> can do without modifying the TCP stack can change this, no matter what
> it does with errors.
> I think this illustrates the issue at the TCP layer and how you have
> problems when the server closes the connection but the client keeps
> sending.  It is only an example, however, since the above can
> be solved by simply not sending a response until we get all the
> data.  A bit wasteful and lame, but a possible workaround.  I think 
> some of Netscape's newer servers do this; older ones appear to act
> just like Apache 1.1.x.  

As I say above, the problem is not really in the TCP layer, it is our fault
for closing the connection early.

That said, I'm going to move on to the second part. Perhaps more later.



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