Am Freitag, 16. August 2013, 00:31:01 schrieb Graham Leggett: > 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
Thanks for the pointers. FTR, the issue with pipelined requests I mentioned above seems to have been fixed by r533820 and r535879. > > 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. The whole code is rather complex. And as you wrote in one of your other mails, writing instead of read does not seem to be implemented in mod_ssl. But I have now voted +1. Should we maybe add a log message to all these bio methods that "should never be called" according to the comments? And implement the missing ones to log a message, too? This may make it easier to debug any issues found by normal users. If yes, at what log level? So high that is is triggered during normal operations or at some trace level? > > 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. Yes. As I said, that was one of the reasons for my comment one week after the commit. It is certainly no longer a valid argument.
