You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/03/17 02:32:12 UTC
Windows testers, AcceptFilter troubles solved?
Ok folks, here's what we know; on some platforms the blocking behavior
is not being honored and SSL is terminated due to the "client's failure"
to provide enough bytes in time. In fact it is the fault of apr plus
the socket stack for not returning without more bytes.
That said, I neglected the fact that the following functions replace
the passed variable with the old value, "un-zeroing" the value of zero!
Please give this patch a whirl and let us know what you all see on various
windows boxes with AcceptFilter data|connect|none against the ssl listener;
Index: server/mpm/winnt/child.c
===================================================================
--- server/mpm/winnt/child.c (revision 1301675)
+++ server/mpm/winnt/child.c (working copy)
@@ -291,7 +291,7 @@
SOCKADDR_STORAGE ss_listen;
int namelen = sizeof(ss_listen);
#endif
- u_long zero = 0;
+ u_long zero;
core_sconf = ap_get_core_module_config(ap_server_conf->module_config);
accf_name = apr_table_get(core_sconf->accf_map, lr->protocol);
@@ -655,16 +655,21 @@
sockinfo.remote = context->sa_client;
sockinfo.family = context->sa_server->sa_family;
sockinfo.type = SOCK_STREAM;
+
/* Restore the state corresponding to apr_os_sock_make's default
* assumption of timeout -1 (really, a flaw of os_sock_make and
* os_sock_put that it does not query to determine ->timeout).
* XXX: Upon a fix to APR, these three statements should disappear.
*/
+ zero = 0;
ioctlsocket(context->accept_socket, FIONBIO, &zero);
+ zero = 0;
setsockopt(context->accept_socket, SOL_SOCKET, SO_RCVTIMEO,
(char *) &zero, sizeof(zero));
+ zero = 0;
setsockopt(context->accept_socket, SOL_SOCKET, SO_SNDTIMEO,
(char *) &zero, sizeof(zero));
+
apr_os_sock_make(&context->sock, &sockinfo, context->ptrans);
/* When a connection is received, send an io completion notification
Re: Windows testers, AcceptFilter troubles solved?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 3/18/2012 7:17 AM, Steffen wrote:
> What are you trying to solve ?
>
> That we do not get anymore the errors like: winnt_accept: Asynchronous AcceptEx failed.
That bug goes to the actual socket stack, nothing we can fix, something
we want to avoid and simply disable AcceptEx due to the broken network
stack drivers who don't know how to recycle sockets correctly. So not
the bug this fixed.
> the broken Acceptfilter https none and connect, which gives errors in the browser like:
>
> Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.
> Error 15 (net::ERR_SOCKET_NOT_CONNECTED): Unknown error
>
> I tested the patch and still the errors above with none and connect.
That is good to know. It was the programmatic bug, now the question
is; how has MSDN misdocumented the behavior? I believe there is only
one way to determine this, I'll throw a patch out there to document the
socket behavior into the log (timeouts/blocking/etc) which have to be
correct in order for apr_socket API's to correctly process the socket.
Testing was much appreciated!
Re: Windows testers, AcceptFilter troubles solved?
Posted by Steffen <in...@apachelounge.com>.
What are you trying to solve ?
That we do not get anymore the errors like: winnt_accept: Asynchronous AcceptEx failed.
or
the broken Acceptfilter https none and connect, which gives errors in the browser like:
Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.
Error 15 (net::ERR_SOCKET_NOT_CONNECTED): Unknown error
I tested the patch and still the errors above with none and connect.
Not yet seen the AcceptEx failed errors with the default(data), but it can go a day or a few seconds.
-----Original Message-----
From: William A. Rowe Jr.
Sent: Saturday, March 17, 2012 2:32 AM Newsgroups: gmane.comp.apache.devel
To: dev@httpd.apache.org
Subject: Windows testers, AcceptFilter troubles solved?
Ok folks, here's what we know; on some platforms the blocking behavior
is not being honored and SSL is terminated due to the "client's failure"
to provide enough bytes in time. In fact it is the fault of apr plus
the socket stack for not returning without more bytes.
That said, I neglected the fact that the following functions replace
the passed variable with the old value, "un-zeroing" the value of zero!
Please give this patch a whirl and let us know what you all see on various
windows boxes with AcceptFilter data|connect|none against the ssl listener;
Index: server/mpm/winnt/child.c
===================================================================
--- server/mpm/winnt/child.c (revision 1301675)
+++ server/mpm/winnt/child.c (working copy)
@@ -291,7 +291,7 @@
SOCKADDR_STORAGE ss_listen;
int namelen = sizeof(ss_listen);
#endif
- u_long zero = 0;
+ u_long zero;
core_sconf = ap_get_core_module_config(ap_server_conf->module_config);
accf_name = apr_table_get(core_sconf->accf_map, lr->protocol);
@@ -655,16 +655,21 @@
sockinfo.remote = context->sa_client;
sockinfo.family = context->sa_server->sa_family;
sockinfo.type = SOCK_STREAM;
+
/* Restore the state corresponding to apr_os_sock_make's default
* assumption of timeout -1 (really, a flaw of os_sock_make and
* os_sock_put that it does not query to determine ->timeout).
* XXX: Upon a fix to APR, these three statements should disappear.
*/
+ zero = 0;
ioctlsocket(context->accept_socket, FIONBIO, &zero);
+ zero = 0;
setsockopt(context->accept_socket, SOL_SOCKET, SO_RCVTIMEO,
(char *) &zero, sizeof(zero));
+ zero = 0;
setsockopt(context->accept_socket, SOL_SOCKET, SO_SNDTIMEO,
(char *) &zero, sizeof(zero));
+
apr_os_sock_make(&context->sock, &sockinfo, context->ptrans);
/* When a connection is received, send an io completion notification