On Thu, Aug 9, 2012 at 7:35 PM, William A. Rowe Jr. <[email protected]> wrote:
> On 8/9/2012 11:26 AM, Claudio Caldato (MS OPEN TECH) wrote:
>> Better patch, fixed minor issue after another code review.
>
> Sadly, it won't fix the defect.
>
> Yes, you are successfullly performing a blocking initial read.
>
> And the pipe remains unblocked for the rest of the connection, so any
> further blocking reads will be ignored (just like the initial read by
> mod_ssl failed to block). Any module expecting blocking behavior on
> subsequent reads will be disappointed.
The SSL case with the chitchat to set up the connection is a bit
different than the simple case where as soon as you read you have
everything needed, so it does seem moderately interesting that the
read|peek makes the simple SSL testcase work.
Also in the FWLIW department:
a. once we get to the process_connection hook, APR's limited knowledge
of the socket state (timeout, non-blocking) is the same on Linux and
Windows
(That was expected all along.)
I had hoped to query state directly from the OS socket too, but
apparently the Microsoft folks don't think you need to be able to do
that, and I don't see any external sysinternals|other tools to tell
you anything interesting about the socket other than the normal
netstat stuff.
b. Using WSAEnumNetworkEvents to clear any existing events didn't seem to help
/* start new */
rv = WSAEnumNetworkEvents(context->accept_socket, 0, &lpNetworkEvents);
if (rv == SOCKET_ERROR) {
ap_log_error(APLOG_MARK, APLOG_WARNING, 0, ap_server_conf,
"failed to clear network events on connected socket");
}
/* end new */
apr_os_sock_make(&context->sock, &sockinfo, context->ptrans);
c. switching out the WSAEvent stuff for a straight
select(is-listener-readable) doesn't work around the problem either
--
Born in Roswell... married an alien...
http://emptyhammock.com/
