On Mon, Aug 20, 2012 at 5:35 PM, Bert Huijben <bert_at_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
Received on 2012-08-20 21:20:39 CEST