This is a discussion on Re: Non-blocking SSL shutdown - Openssl ; 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 ...
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.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org