On 12/12/07, Raimo Niskanen <[EMAIL PROTECTED]> 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

Reply via email to