httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Lingering close: a summary
Date Sun, 09 Feb 1997 21:11:14 GMT
First, thanks, Marc, for persisting for so long (if not so patiently ;-) with
this. I've finally understood, I hope, what exactly this is all about. So,
I'm going to summarize my understanding below.

1. The essential point is that when a connection is fully closed, if the client
is still sending data, then any amount of previously sent server data can be
lost at the client end. This is because of an ambiguity in the TCP/IP protocol
over the meaning of RST, and just generally not catering for that situation
(TCP/IP takes the view that if you close a connection while traffic is still
flowing both ways, then you meant to abort the connection).

2. Error messages generated "early" (i.e. before all incoming data has been
read), followed by a connection close can, therefore, get lost.

3. Such errors occur in PUTs, since we write the error and close.

4. Such errors occur in piplelined keptalive connections, for the same reason.
That is, we can send an error and close for request 1, then lose that error
because request 2 arrives.

5. The problem with errors of this kind in keptalive connections is that the
client may repeat the request in another keptalive connection, and hit the same
problem, and so on ad infinitum (remembering that all the subsequent requests
also need a retry).

Now, there's the question of how to fix the problem. Several things occur to

A. Decide that TCP/IP is broken (there should be a way to reliably deliver our
data to the far end but still abort the input from it). This is surely not
fixable in v4, but may be worth mentioning to the v6 persons. Or maybe v6 does
it anyway.

B. Don't close keptalive connections when we send an error. I'm sure there's
a blindingly good reason we can't do this, but it escapes me.

C. Mandate in HTTP/1.1 that the first unsatisified request in an aborted
keepalive session must be retried alone, or at least without pipelining, and
explain carefully why. It would probably also be good to mandate that the
connection should be closed after a timeout (from both ends).

D. Half-close the session instead, and drain the input. With a timeout, of

D is, of course, the current proposal. B & C seem more appropriate to me.

Note that I'm not currently interested in the side-effects of the various
solutions, I just want to be clear that this is what is going on.


Ben (totally prepared to be all wrong on this one).

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