John Gardiner Myers via RT wrote: > There's no good reason for SSL_shutdown() to ever return a value of 0. > The attached patch simplifies things.
One point of view is: Maybe so. But this is how it has always worked and is documented as such. Your patch does not attempt to update the documentation which talks of the return value 0 which now won't exist. However my point of view is: Actually there is. It is important for OpenSSL to convey back to the application when it has successfully carried out all the following tasks: * to encode SSL control packet (with the way OpenSSL is imlemented this actually means to have flushed all outstanding application payload data down) * to enqueue SSL control packet * to push SSL control packet into BIO / kernel layers In reference to the data that makes up the SSL control packet indicating end-of-encrypted-stream. Any one of these operations might fail due to network conditions. Knowing this state has occurred is important if you want to call TCP shutdown(fd, SHUT_WR) on the underlying socket. Which is a TCP level end-of-write-stream indicator. A single return value of "1" can not indicate both points in the proceedings. * The point the SEND shutdown control packet has been push into BIO / kernel layers. * The point in the proceedings when both the SEND and the RECEIVE end-of-encrypted-stream control packet have been fully processed. So maybe for you it seems like a simplification as you have a simpler mental model of what is going on :) If there was a chance to start over I think a much better interface would be to return the state of the SSL_RECEIVED_SHUTDOWN and SSL_SENT_SHUTDOWN flags, i.e. just like SSL_get_shutdown() would instead of 0 or 1 scenarios that currently exist. Regards, Darryl ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
