httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 52476] SSL failures on windows with AcceptFilter https none
Date Mon, 23 Jan 2012 04:29:19 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=52476

--- Comment #18 from William A. Rowe Jr. <wrowe@apache.org> 2012-01-23 04:29:19 UTC
---
So, there is no special-case filter... I had modified the logic that was
unusable within the 'public', simple-yet-insufficient ap_process_connection,
which would otherwise do;

    ap_update_vhost_given_ip(c);

    rc = ap_run_pre_connection(c, csd);
    if (rc != OK && rc != DONE) {
        c->aborted = 1;
    }

    if (!c->aborted) {
        ap_run_process_connection(c);
    }

Note that the event, simple and winnt mpm's all have custom implementations
of that not-altogether useful sequence of instructions.

So mpm/winnt/child.c worker_main() reimplements this logic for those cases
where we must inject an initial bucket of data, pulled from the accepted
socket by AcceptEx.  Really there is little special about Acceptfilter none;
it bypasses that magic, the initial brigade is empty and obtains one socket
bucket.

Now the only idea I have left is that somewhere in the code path
        else /* (accf = 0)  e.g. 'none' */
where we handle accept(), play some setsockopt games, and call apr_os_sock_make
apr and mpm_winnt disagree on the default state of that new apr_socket_t.

That is about the last explanation which would address these interesting
timing observations, that apr is not blocking, but httpd assumes that it is.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message