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 majordomo@openssl.org