httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: r1470679, async write completion, non blocking writes, and mod_ssl
Date Thu, 15 Aug 2013 22:31:01 GMT
On 15 Aug 2013, at 6:15 PM, Stefan Fritsch <sf@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
--


Mime
View raw message