On 07 Oct 2015, at 7:46 PM, Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com> wrote:
> I guess we are talking of different things. During the initial handshake > (client or server) we never hand back > control to the event part of the MPM. We never use ssl_filter_write and > ssl_io_filter_output as this is only used for data we want to encrypt on the > connection. During the handshake we deal directly with the core output filter. > We are just synchronous here. And I think this is not a big deal as the > amount of data that needs to be transferred here is low and buffered by the > socket buffer anyway. So we would not really notice the difference between > synchronous and asynchronous since the socket is not blocking / says its > writable. This is probably where we’re going wrong. With mod_ssl non blocking behaviour is an all-or-nothing deal. We must follow all of openssl’s instructions to the letter, otherwise we’ll hang. We can’t sometimes be synchronous and sometimes not. Accidentally waiting to be ready to write when we actually need to be waiting to read is easy to get away with, because almost always we are ready to write. The opposite however isn’t true. If we accidentally wait to be readable when openssl wanted us to tell when it’s writable we can very much hang with the client not sending anything to trigger that read (why would it, it’s expecting to receive something). Regards, Graham —
