On Sat, 29 Sep 2007, Thor Lancelot Simon wrote: > 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...
But that code *never* returns WANT_READ/WANT_WRITE. Non blocking sockets always get SSL_ERROR_SYSCALL. Well, unless the case where they both succeed immediately - but that's like blocking behaviour. As far as changes to the existing behaviour, blocking BIOs will never get the new error code (<0). And noone could have used the non-blocking BIOs in a sane way, with the current behavior (lack of proper WANT_READ/WANT_WRITE). - Davide ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
