Hello, > There are a huge number of corner cases I did not address, and it was > not > my intent to be a 100% complete discussion of the use of SSL_read. We are talking of one and specified (renegotiation) case.
> Nevertheless, I stand by my analysis of his problem. OK :-) > He called SSL_read with a blocking socket even though he did not want to > block. SSL_read has no way of knowing that he doesn't want to block because > he lied to it by invoking it as a blocking operation. Not HE but OpenSSL developer who created s_client OR OpenSSL developer who created SSL_read(). > There will never be any perfectly satisfactory solution to this problem. I agree. > SSL_read has no way of knowing whether he really wanted to block until > application-level data was available or whether he really didn't want to > block -- and short of modifying it to call 'select' before it calls 'read' > each time or save the blocking state of the socket set it to non-blocking > and then set it back, no conceivable implementation off SSL_read can > guarantee that it won't block when called on a blocking socket. OK, but SSL_read() knows that is doing renegotioation, and sometimes SSL_read() returns informations that user should call it again. Proper writted application should be prepared (today) to handle this. If not - may fail now too. So return WANT_READ if renegotiation take place nothing change but solves this problem. I stand by my analysis of his problem because from may point of view library is for user, not user for library :-) Best regards, -- Marek Marcola <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
