> When you use blocking socket now, you must react on SSL_ERROR_WANT*
> any many more - if not - you are doing mistake.
If that's true, that's a defect in the implementation. People who use
blocking sockets should get blocking behavior.
> Good written application must react on this errors - sooner or later
> in development process.
Well-written applications should tolerate all kinds of failure
scenarios,
even the ones that aren't supposed to happen.
> My proposition was to add to one of this error situation when SSL_read()
> is doing renegotiation. Look at SSL dump.
Your proposition was to add further breakage. It is a mistake to issue a
blocking socket operation if you do not wish to block, end of story. This is
just a single example of one way this can break and it is impossible to fix
it completely without breaking proper blocking applications that really do
want to block.
> In what way this break already used applications ???
> In what way this break anything ???
It would have broken the application that this was about. If not for
this
"problem", the author of this application would have released it with a
serious defect -- namely that it attempts to perform operations with
blocking sockets in a case where it cannot afford to block. Fortunately for
the original poster, he was able to detect this problem and can now easily
fix it by using non-blocking sockets. (And with luck he won't make this same
mistake with TCP, UDP, or any other protocol. It bites more people more
often than you might think. It's a common issue on USENET.)
When code is broken and easy to fix, anything that makes the breakage
harder to detect is bad. Anything that makes it trigger more often and be
more easily detected is good. All other things being equal.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
