This is a discussion on RE: make SSL_shutdown work with non-blocking BIOs - Openssl ; Nanno Langstraat: > 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. > > ...
> 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
> I already claimed that the application programmer is not given the
> knowledge that this restriction exists.
OpenSSL does its best to document where it fails to make SSL connections
look like TCP connections. It does not always document where it succeeds. It
is assumed that the programmer is familiar with how TCP works and does not
need every similarity documented.
> The entire point is that the socket is *not* readable, as you claim it
> to be.
Incorrect. It is readable. If a dead connection were neither readable nor
writable, how would a classic non-blocking application (think 'select') ever
discover a dead connection? Even if it wait for both readability and
writability, it would never be told that a connection had been closed by the
other end if a closed connection were neither readable nor writable.
That is why the convention is that dead connections are readable.
> 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.
Thus it is always readable. Read will always succeed immediately and
correctly report that the connection is dead. That is the definition of a
readable socket (read will complete immediately).
> 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().
And OpenSSL is reporting correctly that all it needs to make further
progress is a readable socket. It has a readable socket, and further
progress can be made immediately. If the socket were not readable, OpenSSL
could not make forward progress immediately.
> > 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.
Huh? Once a web server has sent all the data it plans to send, it will never
call 'write' for that connection again. It may still try to close the
connection down cleanly.
You only call SSL_write if you have data to send.
> 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.
This is a case where it is comparable.
> I should think that this is an eminently reasonable suggestion, either
> way, and I don't understand the resistance.
What do you see as the difference between OpenSSL's behavior and classic TCP
behavior in this case? In both cases, the socket is readable. In both cases,
forward progress (which would presumably be closing the socket or tearing
down the connection) can be made because the socket is readable.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org