Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 52476] SSL failures on windows with AcceptFilter
 https none
Date: Fri, 20 Jan 2012 10:24:32 +0000
Message-ID: <bug-52476-7868-Nlu5gHEBGJ@https.issues.apache.org/bugzilla/>
In-Reply-To: <bug-52476-7868@https.issues.apache.org/bugzilla/>
References: <bug-52476-7868@https.issues.apache.org/bugzilla/>
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=52476

--- Comment #14 from Joe Orton <jorton@redhat.com> 2012-01-20 10:24:32 UTC ---
[Thu Jan 19 15:22:52.397200 2012] [ssl:trace7] [pid 4816:tid 1028]
ssl_engine_io.c(475): [client 127.0.0.1:50779] read of 11 bytes => 0, mode =
blocking, brigade is empty

Thanks, Gregg.  This would suggest Bill's intuition about an EAGAIN is correct,
but specifically, the only way this could happen is if apr_bucket_read() is
returning EAGAIN for a blocking read.  The core input filter should really
treat that as an error, because it should never happen.

The obvious step on Unix would be to get "strace" output to see what the system
calls are doing, but somebody with Windows domain expertise will have to
suggest what to do.

-- 
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