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. > > 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. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
