On 15 Aug 2013, at 09:56, Stefan Fritsch <s...@sfritsch.de> 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. 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. One possible reason for not triggering the one path could be that mod_ssl implements read and write channels in one direction, but only read channels in the other (or vice versa, code isn't in front of me). This would need to be fixed before mod_ssl could properly support a non-request-response protocol, and again, this is a separate problem. This limitation doesn't justify implementing only half of the async behavior. Regards, Graham --
