Let the TLSv1_method() etc. functions return a const SSL_METHOD

[openssl.git] / doc / ssl / SSL_shutdown.pod

diff --git a/doc/ssl/SSL_shutdown.pod b/doc/ssl/SSL_shutdown.pod
index e205eac3091c27f9f99ec5a136cf2f980a15cd0b..89911acbcac89a89c8de068297be4b7f7858b4ef 100644 (file)
--- a/doc/ssl/SSL_shutdown.pod
+++ b/doc/ssl/SSL_shutdown.pod
@@ -38,7 +38,7 @@ behaviour.
 =over 4
 
 =item When the application is the first party to send the "close notify"
-alert, SSL_shutdown() will only send the alert and the set the
+alert, SSL_shutdown() will only send the alert and then set the
 SSL_SENT_SHUTDOWN flag (so that the session is considered good and will
 be kept in cache). SSL_shutdown() will then return with 0. If a unidirectional
 shutdown is enough (the underlying connection shall be closed anyway), this
@@ -49,9 +49,12 @@ shutdown alert. On success, the second call to SSL_shutdown() will return
 with 1.
 
 =item If the peer already sent the "close notify" alert B<and> it was
-already processed implicitly inside another call of e.g.
-B<SSL_read(3)|SSL_read(3)>, SSL_shutdown() will send the "close notify"
-alert, set the SSL_SENT_SHUTDOWN flag and will immediately return with 1.
+already processed implicitly inside another function
+(L<SSL_read(3)|SSL_read(3)>), the SSL_RECEIVED_SHUTDOWN flag is set.
+SSL_shutdown() will send the "close notify" alert, set the SSL_SENT_SHUTDOWN
+flag and will immediately return with 1.
+Whether SSL_RECEIVED_SHUTDOWN is already set can be checked using the
+SSL_get_shutdown() (see also L<SSL_set_shutdown(3)|SSL_set_shutdown(3)> call.
 
 =back