On Sat, Sep 29, 2007 at 01:19:38PM -0700, Davide Libenzi wrote: > > 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.
Yes, I'm well aware of that. I maintain a great deal of code that uses OpenSSL with non-blocking BIOs, and, yes, when any underlying condition causes the session to not be ready to be shut down, SSL_ERROR_SYSCALL is always the error code returned. No, it's not ideal. Yes, it's what existing application code expects. So it's necessary to be careful about changing this. > 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). I'm sorry, but your assertion about WANT_READ/WANT_WRITE is false. In practice, the way it's been for many years is that if you get SSL_ERROR_SYSCALL back, you simply put the socket in your select set for all event types (read/write/exception). Yes, it is a rough spot in the API. Yes, in an ideal world, it would never have worked this way. The problem, as with so much else in OpenSSL, though, is that there's a lot of application code out there by now that knows how the API actually works -- not how it _should_ work, but how it _does_ -- and adding new error returns that weren't possible before will break some of that code. Thor ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
