Am Donnerstag, 15. August 2013, 10:45:25 schrieb Graham Leggett: > On 15 Aug 2013, at 09:56, Stefan Fritsch <[email protected]> wrote: > > I have understood that. But I would have liked to see the sense > > code in action, but failed to trigger it. At least > > t/ssl/pr12355.t in the test suite uses renegotiation, and I have > > also tried client initiated renegotiation (after removing the > > code that rejects it), but neither causes httpd to use the new > > code paths. So, do you have a test setup where the new code paths > > are actually used? > > The original report was of a hang, and the cause of the hang was > clear - OpenSSL async behavior was switched on but the sense > reversal was ignored. The fix was to complete the functionality. By > committing it to trunk I hoped that those who had seen the hang > would be able to verify the hang was gone, as I struggled to > reproduce it.
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. > What didn't help at all was the message in STATUS that more testing > was needed, as it didn't elaborate what kind of problem or > behaviour people should be testing for. 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. 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.
