Nanno Langstraat wrote:
> Can we agree on the convention that as long as no OpenSSL call has
> returned -1, there is no error condition in effect, at least as far as
> the application knows?

Nope. A return value of 0 from SSL_read() is also a special case. The
same is true of the kernel call read(). No amount of calls to read data
will yield any more data.

So now you should call SSL_get_shutdown() if you SSL_RECEIVED_SHUTDOWN
is set then you at least received a graceful shutdown. If you did not
you can presume the other end does not care for a secure shutdown (or
the socket has some other error) so should close handles.

If you are still in play then at this point you know 100% you are never
going to receive any more application data and that the remote end has
gracefully initiated a secure shutdown. But... you are not sure if the
sending side if the tcp socket you are holding is still open, if it is
then you have the opportunity to send your secure shutdown.

At TCP level (if you have SIGPIPE ignored) when write() will return
-1/EPIPE if the socket really is closed.

Now things start to get messy.

You want to instruct OpenSSL to attempt to commit a shutdown response
and then write that response to the BIO layer. If the BIO layer accepts
the data without any error then it was open and now you can tidy up
knowing you got your graceful shutdown reply out. If it didn't then it
will may return one of 2 things:

* the socket couldn't accept all the data just yet (EAGAIN) in this case
you want to retry pushing that data out later (when the socket is
writable). Or

* it may indicate some other error (like EPIPE) which is not
recoverable, so you should tidy up.

It gets messy because the obvious way to implement it to me would be to
call SSL_shutdown() and expect to get back -1/WANT_WRITE (meaning try
again later) or 1 (meaning all done).

But I think the problem with SSL_shutdown() never returning -1 is very
well known now, LOL.

__________________________________________________ ____________________
OpenSSL Project
Development Mailing List
Automated List Manager