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.
That might be cool. Post a patch and I'll review it.
We should prevent Win9x users from enabling the flag, however :-)
Bill
WindowsUseAcceptEx is much better I think. Since it is on by default on systems which support it. Another (better?) suggestion: WindowsDisableAcceptEx (with no arguments)?
Bill
