On Sat, Sep 29, 2007 at 12:51:52PM -0700, Davide Libenzi wrote:
>
> The reason I posted the patch was because I noticed a SSL_ERROR_SYSCALL
> back from SSL_get_error().
> This is what the documentation says:
>
> --
> If the underlying BIO is non-blocking, SSL_shutdown() will also return
> when the underlying BIO could not satisfy the needs of SSL_shutdown() to
> continue the handshake. In this case a call to SSL_get_error() with the
> return value of SSL_shutdown() will yield SSL_ERROR_WANT_READ or
> SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after
> taking appropriate action to satisfy the needs of SSL_shutdown(). The
> action depends on the underlying BIO. When using a non-blocking socket,
> nothing is to be done, but select() can be used to check for the required
> condition. When using a buffering BIO, like a BIO pair, data must be
> written into or retrieved out of the BIO before being able to continue.
The documentation *also* says:
RETURN VALUES
The following return values can occur:
1 The shutdown was successfully completed. The "close notify" alert
was sent and the peer's "close notify" alert was received.
0 The shutdown is not yet finished. Call SSL_shutdown() for a second
time, if a bidirectional shutdown shall be performed. The output
of SSL_get_error(3) may be misleading, as an erroneous
SSL_ERROR_SYSCALL may be flagged even though no error occurred.
I guess the question is whether this SSL_ERROR_SYSCALL is "erroneous" or
not. I assume your intent here is to actually get back WANT_READ or
WANT_WRITE so you can put the underlying socket in the correct select set,
and I agree that that would be a useful thing to be able to do. But I am
concerned that adding possible return values here would break existing
code that switches on the "possible" return values from the SSL_get_error
in this case. I realize that that's not strictly supported by the API as
documented now, but looking through one codebase I work on, I do in fact
see a number of things your change might break if it added new possible
error returns there...
Thor
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
