httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: more lingering_close... (tcpdump analysis)
Date Sun, 09 Feb 1997 20:33:32 GMT
Marc Slemko wrote:
> Below is a bit of discussion on the issues surrounding
> lingering_close.  It starts off going through an example of a 
> PUT, then moves on to persistent connections.
> (alive is the client, obed is the server.  alive running FreeBSD 2.1.x, 
> obed running SunOS 4.1.x)
> Ok, I'll start with a recap of the situation with PUTs.  Below
> is an annoated tcpdump from doing a PUT to an Apache server 
> w/o lingering_close from a client running Navigator Gold.  The
> server will return an error message because that is how it is setup.
> 19:57:29.171129 > . 234:746(512)
ack 1 win 16384 (DF)
> 19:57:29.171291 > . 746:1258(512)
ack 1 win 16384 (DF)
> The first packet is the headers from the client to the server.  The second
> is the start of the data being PUT.
> 19:57:29.600864 > P 1:338(337)
ack 746 win 4096
> This is the error message from the server to the client.  It is 
> sent by the server right after it gets our first packet.
> 19:57:29.601314 > . 1258:1770(512)
ack 338 win 16047 (DF)
> 19:57:29.601569 > . 1770:2282(512)
ack 338 win 16047 (DF)
> This is the document continuing to be sent.
> 19:57:29.610947 > F 338:338(0)
ack 746 win 4096
> This is the server sending the FIN to close the connection; it sends it
> right after it sends the one at 19:57:29.600864, it just shows up
> here later because of latency (~250ms between client and server).
> 19:57:29.611247 > . ack 339 win
16307 (DF)
> We are still sending data.
> 19:57:29.611549 > R 865216001:865216001(0)
win 0
> 19:57:29.880585 > R 865216338:865216338(0)
win 4096
> 19:57:29.990543 > R 865216338:865216338(0)
win 4096
> 19:57:29.990921 > R 865216339:865216339(0)
win 4096
> The server doesn't like keeping to get data after it said the connection
> was closed, so it sends a RST.  There is sortof one for each packet
> the client sent after the headers, but not exactly; would need to make
> tcpdump print absolute seq. numbers to figure out exactly which one is
> in response to which message.  Navigator generates a 'A network error 
> occurred while Netscape was receiving data.  (Network Error: Connection
> reset by peer)'.
> In this situation, if lingering_close() was used the client would not
> get the RSTs and so would not pop up the TCP error; it should, of 
> course, pop up a box with the error that the HTTP server sent.
> 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.

I see where you're coming from. The server has closed the connection (fully),
but the protocol still has data to send, which it does, followed by a FIN. The
client, meanwhile, is sending its PUT data, which now has no home to go to at
the server end. The server, naturally enough, sends RSTs in response.
Unfortunately RSTs also mean "abort this connection", so Netscape gets an
error. So, as you say, it might be reasonable for the stack to not send RSTs
until the other end has closed. On the other hand, that would seem prone to
problems - the client may carry on sending forever, and there's really no point
in permitting it to. If data is expected from the other end, the only correct
thing to do is half-close (in the real sense of the word - the above usage is
misleading; the connection is in the process of doing an orderly close). That
is, to close the server's output, and leave the input open, and read to EOF.
Otherwise known as an l_c(), I believe.

Now I really am going to read the second half.



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