Darryl Miles wrote:
The SSL_want() man page indicates it does not account for errors or
any other special overriding circumstances and the values only make
sense when the SSL channel is in a normal condition. I'm sure you
will agree that SSL channel is not in a normal state as soon as it
starts handling an end-of-stream in any direction.
No, I do not in fact agree. I hope you'll believe I'm not actively
trying to be difficult.
At least in the case of TCP (the "gold standard" reference point),
half-duplex shutdown is a completely normal point in the state diagram
of a connection. It is most certainly not an 'error' state.
However, reading the rest of your email I see that you actually agree
that the SSL_want_read() documentation is vague, so I do not think that
we have very differing opinions overall.
I think you agree that what is a "normal state" is not defined clearly
anywhere, and that the innocent API programmer is not told anywhere that
he can't use SSL_want_read() anymore for select()/poll() after he got
SSL_read()==0, and that this should be fixed.
Now *That* would be a broken application. An application like that
would not work right when doing non-blocking plain TCP either.
Urgh. A non-blocking server application that reads telemetry data
from a source would never write anything back the other way.
.... In which case there is no problem: an app that knows it does not
want to write can of course stop regular operations and clean up the
connection as soon as it gets 0 back from the read call.
Whether it's TCP or SSL.
Non-problem.
Nanno
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
