On Mon, Aug 20, 2012 at 5:35 PM, Bert Huijben <b...@qqmail.nl> wrote: > > > Maybe you should call SSL_get_error() in the handler to find out the exact > reason on why OpenSSL reports the connection as closed? > > From man SSL_read on my FreeBSD box: > > 0 The read operation was not successful. The reason may either be a > clean shutdown due to a "close notify" alert sent by the peer (in > which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown > state > is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also > possible, that the peer simply shut down the underlying transport > and the shutdown is incomplete. Call SSL_get_error() with the > return value ret to find out, whether an error occurred or the > connection was shut down cleanly (SSL_ERROR_ZERO_RETURN). > > SSLv2 (deprecated) does not support a shutdown alert protocol, so > it can only be detected, whether the underlying connection was > closed. It cannot be checked, whether the closure was initiated > by > the peer or by something else. > > > Looking further through that man page I think serf should also handle > SSL_ERROR_WANT_WRITE like SSL_ERROR_WANT_READ in the error handling block, > but that is unrelated to this patch. > > Bert >
I agree, there is some room for improvement here to handle all return cases of the SSL API. I'm wondering if there's an easy way to simulate all theses possible return paths, I don't like to add untested code. Lieven
