On 15 Aug 2013, at 6:15 PM, Stefan Fritsch <s...@sfritsch.de> wrote: > Do you still have a pointer to that report? I have found the commit > notice of the initial commit (r105919) which talks about pipelined > requests not working with ssl+mpm_event. But in my tests those worked > fine without entering the SSL_ERROR_WANT_READ code path.
This was the original report that introduced the "clogging" concept to work around the lack of async support: http://osdir.com/ml/dev-httpd/2007-06/msg00054.html I had investigated this problem after someone had told me at a conference that the reason mod_ssl didn't work in the event mpm was because openssl couldn't support async SSL, which isn't true. I asked for clarification here: http://comments.gmane.org/gmane.comp.apache.devel/50310 > Any test that actually executes the new code would be fine. From the > discussion so far, it seems to me like nobody actually did that so > far. But I don't see any problem with my comment. The backport > proposal was made only one week after commit to trunk. Considering the > subtleties involved in that area, and that it now took quite some > discussion to determine what is and what is not the scope of the > patch, I still think that a rushed backport would have been wrong. Can you clarify what subtleties there were in this area? Without explicit async support mod_ssl would certainly hang if httpd's core polled for read when openssl had expected a write. To enable async behaviour in SSL you need to enable it using BIO_set_nbio(). Having enabled this openssl will ask permission before write-during-read or read-during-write instead of just performing the read or write in a blocking fashion. This allows you to poll for the correct event, write or read. http://linux.die.net/man/3/bio_set_nbio "BIO_set_nbio() sets the non blocking I/O flag to n. If n is zero then blocking I/O is set. If n is 1 then non blocking I/O is set. Blocking I/O is the default. The call to BIO_set_nbio() should be made before the connection is established because non blocking I/O is set during the connect process." > And > pquerna commented on IRC that the solution seemed wrong to him, but > unfortunately it appears he didn't have time to look at the patch in > detail. We need something more specific than "it seems wrong". If there is a genuine problem I want us to find it, but we can't remain blocked indefinitely by a problem that hasn't been defined anywhere. Regards, Graham --
