|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: knitti (knitti
gmail.com)
Date: Wed Dec 12 2007 - 10:32:52 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/12/07, Raimo Niskanen <raimo+openbsd
erix.ericsson.se> wrote:
> * A httpd server socket enters CLOSE_WAIT when the client
> closes (or half-closes) its end and sends FIN to the
> server TCP stack that replies ACK and enters CLOSE_WAIT.
> The socket proceeds out of CLOSE_WAIT when httpd calls
> close() on the socket.
>
> So, the remaining question is why httpd does not close the socket.
> Even though KeepAlive is in effect, since the client has closed its
> end there can come no more request on it, and the server
> should be able to notice that the client has closed its
> socket end either by recv() returning 0, or from a poll()
> return value. The server also should be able to know if
> it has more data to send to complete the reply.
> I see no reason to hold the socket in CLOSE_WAIT the whole
> KeepAliveTimeout time, and am interested to learn why.
WARNING: I'm not very experienced reading C code, so take my words
with heaps of salt.
The interesting code is most probably in http_main.c,
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/httpd/src/main/http_main.c
The problem would be to "forget" calling ap_bclose() after ending a
connection, either because all data has been sent or the connection has
been aborted. What I can read with some confidence, is that keeping a
socket open beyond sending any data is not intentional, and there is
nothing (for me) which suggests that it would happen at all.
Noob questions/statements ahead:
The code, which implications (aside from the clear visible intention what the
code *should do) are least clear to me for lingering_close() and lingerout()
(is this a signal handler for SIG_ALRM?).
I would suspect some kind of (signal?) race (not nessessarily there), in
which ap_bclose() gets called on a different socket than intended (thus
shutting down another connection as a side effect). BUT since the whole
code doesn't run threaded, I can't come up with something which would
actually suggest that.
I would appreciate if someone told me whether my interpretation is rather
wrong or rather right ;)
--knitti
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]