RT2518: fix pod2man errors

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

diff --git a/doc/ssl/SSL_shutdown.pod b/doc/ssl/SSL_shutdown.pod
index 3dcd0ddf457b59875467eb73258c91ef8118c6be..efbff5a0a3230ace064b5a5951aabc39cae2be4b 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
 
@@ -77,25 +80,31 @@ nothing is to be done, but select() can be used to check for the required
 condition. When using a buffering BIO, like a BIO pair, data must be written
 into or retrieved out of the BIO before being able to continue.
 
+SSL_shutdown() can be modified to only set the connection to "shutdown"
+state but not actually send the "close notify" alert messages,
+see L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>.
+When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
+and return 1.
+
 =head1 RETURN VALUES
 
 The following return values can occur:
 
 =over 4
 
-=item 1
-
-The shutdown was successfully completed. The "close notify" alert was sent
-and the peer's "close notify" alert was received.
-
-=item 0
+=item Z<>0
 
 The shutdown is not yet finished. Call SSL_shutdown() for a second time,
 if a bidirectional shutdown shall be performed.
 The output of L<SSL_get_error(3)|SSL_get_error(3)> may be misleading, as an
 erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
 
-=item -1
+=item Z<>1
+
+The shutdown was successfully completed. The "close notify" alert was sent
+and the peer's "close notify" alert was received.
+
+=item E<lt>0
 
 The shutdown was not successful because a fatal error occurred either
 at the protocol level or a connection failure occurred. It can also occur if
@@ -109,6 +118,7 @@ to find out the reason.
 
 L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_connect(3)|SSL_connect(3)>,
 L<SSL_accept(3)|SSL_accept(3)>, L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>,
+L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>,
 L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>,
 L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>