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 openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
