I've had a broken proprietary SSL module, with no accept filters, on Windows 2.4 for some time.
In this module, handshake failures result in ap_run_pre_connection() returning DONE, closing the socket, and setting c->aborted. In 2.4, the MPM leaves a copy of the non-disconnected FD sitting in context->accept_socket. This FD will be closed a second time, often shortly after a worker picks it up in this same FD being reused. The first recv fails with WSAENOTSOCK since the same FD was closed in the listener thread while the worker was pulling it off the queue (The second close is of the underlying FD/socket, not a shared apr_socket_t, so it's not short-circuited) This patch makes it a bit more 2.2.x-ish and solves my problem -- the context->accept_socket gets zapped at the bottom of the loop if !disconnected. http://people.apache.org/~covener/patches/httpd-trunk-preconnection_invalid_socket.diff There is at least 1 thing risky [albeit unchanged by patch] in this neighborhood worth mentioning: trunk and trunk+patch only call ap_lingering_close() when !disconnected and !c->aborted. But neither winnt in 2.2 or worker in 2.4 have the c->aborted guard around ap_lingering_close. Thanks, -- Eric Covener [email protected]
