David Schwartz wrote:
This goes pear-shaped as follows:
The application is broken. Once SSL_read returns 0, the connection is dead.
Quote chapter and verse of the OpenSSL API documentation, or desist from
such vehement statements.
You can not scold an API user for violating rules that are not in the
documentation.
I already claimed that the application programmer is not given the
knowledge that this restriction exists.
My claim might be proven wrong of course, but there is naturally a
burden on you to provide a hint of evidence for it. I would have
expected a relevant quote from the SSL_read() or SSL_want_read() manual
pages in your email.
* Say "Silly OpenSSL API user! You should have known/guessed that
you can't use SSL_want_read() / SSL_want_write() anymore after
SSL_read() has returned 0."
You can't use them that way. You can call them if you want. SSL_want_read is
the correct indication, telling you that you can make SSL calls as soon as
the socket is readable, which it already is. There is nothing to wait for,
SSL_want_read returning true or false are equally valid, since the socket is
readable.
The entire point is that the socket is *not* readable, as you claim it
to be.
The OS kernel has already told OpenSSL that (the downstream direction
of) the socket is shut down. [OpenSSL did read() on the socket and it
returned 0]
That event is the very reason why SSL_read() decided to return 0 to the
application in the first place!
The socket is not and never again will be readable. It's passed on. It's
bereft of life. It's not pinin' for the fjords. Etc.
And more importantly, OpenSSL is the only party who knows this
underlying cause, and SSL_want_read() is the designated channel to for
the application to query the information in order to do a correct
select() or poll().
* The OpenSSL code can be updated to handle this nicely: make sure
SSL_want_read() and SSL_want_write() return false, and wait for
the application to call SSL_write() sooner or later, which will
return an error as normal. At that moment the non-blocking
application can be expected to "get the idea" and clean up the
connection smoothly.
The application may never call SSL_write. It may have already sent all the
data it ever plans to send. This is not a sensible plan.
Now *That* would be a broken application. An application like that would
not work right when doing non-blocking plain TCP either.
All I'm asking for is: either make OpenSSL behaviour comparable to the
Unix socket API, *or* completely document the API as it is, with its
diferent use rules.
I should think that this is an eminently reasonable suggestion, either
way, and I don't understand the resistance.
Nanno
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
