httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: more lingering_close... (tcpdump analysis)
Date Mon, 10 Feb 1997 00:33:17 GMT
Marc Slemko wrote:
> 
> I have said this a dozen times before.  I am getting tired of saying it. 
> You don't seem to acknowledge the fact that the socket may not be closed
> on the client when you send the data but it may be partly closed on the
> server by the time it arrives at the server.
> 

Without l_c() the socket is not partly closed at all (we'll consider
a socket close atomic right now). Thus, without l_c() the above doesn't
come into play. The problem I think you are refering to is when
the server goes to close the link and during that period, when all
looks clear to the client, the client starts sending data. However,
by the time it reaches the server, the server has closed the connection.
Thus, the client gets a RST. I have no idea how frequently this
could occur or what the odds are that this happens. In any case,
the client did all that it was supposed to, checked the line, all
looked OK and then sent the data. It then got a RST and it doesn't
know why. Now as I read the HTTP1.1 spec, the client should have
some knowledge of state and know that request 25 went OK but I
got a RST when sending request 26 and that it should reattempt
that request... This could be my own misunderstanding of the spec
(which is quite likely) but surely the client has some responsibility
for handling errors mid-stream.

-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim@jaguNET.com           |       http://www.jaguNET.com/
                  "Not the Craw... the CRAW!"

Mime
View raw message