On 4/25/2012 1:21 AM, Darryl Miles via RT wrote: > 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. That was deliberate. The patched implementation conforms to the interface contract of the existing documentation. If the corresponding change were made to the documentation, then callers written to the new documentation would fail when run against downrev/existing versions of the library.
Put another way, the implementation change is appropriate for a minor release. The obvious corresponding documentation change is only appropriate for a major release. > 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. The current documentation does not permit the caller to infer that it is safe to do a TCP shutdown(SHUT_WR) from a 0 return value. Neither does the implementation--it will return a 0 before the output BIO has been completely flushed. > > 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 :) As I mentioned above, neither does the existing return value of "0" indicate this. If one wants to encode assumptions about the actual behavior of the existing TLS protocol and that one is not currently doing a handshake, one could use a return value of "-1" plus a SSL_get_error() of SSL_ERROR_WANT_READ to indicate this. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
