At 12:57 PM 3/13/2003, Bill Stoddard wrote:
>[EMAIL PROTECTED] wrote:
>>ake 2003/03/04 14:15:52
>> Modified: . CHANGES
>> server/mpm/winnt child.c mpm_winnt.c mpm_winnt.h
>> Log:
>> Added the WindowsSocketsWorkaroud directive for Windows NT/2000/XP
>> to work around problems with certain VPN and Firewall products that
>> have buggy AcceptEx implementations
>>
>> Revision Changes Path
>> 1.1103 +5 -0 httpd-2.0/CHANGES
>>
><snip>
>
>>
>> static const command_rec winnt_cmds[] = {
>> LISTEN_COMMANDS,
>> @@ -224,6 +243,9 @@
>> "Number of threads each child creates" ),
>> AP_INIT_TAKE1("ThreadLimit", set_thread_limit, NULL, RSRC_CONF,
>> "Maximum worker threads in a server for this run of Apache"),
>> +AP_INIT_TAKE1("WindowsSocketsWorkaround", set_sockets_workaround, NULL, RSRC_CONF,
>> + "Set \"on\" to work around buggy Winsock provider implementations of certain
>> VPN or Firewall software"),
>> +
>> { NULL }
>> };
>
>Rather than WindowsSocketsWorkaround, why not WinUseWinsock1 or ??. It would be
>better I think if the directive somehow indicated exactly what it was doing (causing
>the winnt mpm to use the select/accept winsock1 calls rather than AcceptEx, a
>winsock2 call).
That would be a misnomer - since our handle inheritance requires winsock2.
What about WindowsUseAcceptEx on|off? That's really descriptive of what
the workaround does. Or, we could call it WindowsFastSockets on|off,
which is the effect of the workaround.
I was also looking at this entire patch - it seems silly to retest for both the
version of windows and this flag throughout the code. Why not simply
initialize it in the register_hooks() call based on the OS version? Then let
the directive override its default value. We should prevent Win9x users
from enabling the flag, however :-)
Bill
