On Mon, 8 Oct 2007, Howard Chu wrote: ...
There are a number of ways this can be handled:
- change the client to wait until it sees the server's close_notify alert
by replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines: if (SSL_shutdown( p->ssl ) == 0) SSL_shutdown( p->ssl ); (I have confirmed that this works. As documented, the first call will return 1 if the server's close_notify has already been received, if not, the second call will block until it is received.)
So if the server doesn't send one, the client will be stuck waiting forever?
It would also unblock if the server closed the connection. One downside of this option that I thought of later is that it shifts the TCP CLOSE_WAIT state from the client to the server. Fixing that would add more complexity to the sockbuf layer than this entire change is worth.
Having chatted with Kurt about this at the last IETF meeting and pondered failure modes, I'm no longer in favor of this option.
- change the client to not bother to send a close_notify alert when it's just going to close() the connection; change the server to not send a close_notify if it didn't get one. <...>
Sounds like a change in the SSL library, not something for us to worry about.
Since "send a close_notify alert" == "call SSL_shutdown() for the first time", it would be a change in how the SSL library was used by libldap.
Anyway, this issue isn't worth keep an ITS open about, as it doesn't actually cause failures or visible errors. I might someday chase down a clean way of implementing this second option, but only after the much more useful work of coming up with a reasonable API to let event-driven apps do STARTTLS without blocking. Someday.
Philip Guenther