25c25,33
< The behaviour of SSL_shutdown() depends on the underlying BIO.
---
> The shutdown procedure consists of 2 steps: the sending of the "close notify"
> shutdown alert and the reception of the peer's "close notify" shutdown
> alert. According to the TLS standard, it is acceptable for an application
> to only send its shutdown alert and then close the underlying connection
> without waiting for the peer's response (this way resources can be saved,
> as the process can already terminate or serve another connection).
> When the underlying connection shall be used for more communications, the
> complete shutdown procedure (bidirectional "close notify" alerts) must be
> performed, so that the peers stay synchronized.
26a35,68
> SSL_shutdown() supports both uni- and bidirectional shutdown by its 2 step
> 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
> 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
> first call to SSL_shutdown() is sufficient. In order to complete the
> bidirectional shutdown handshake, SSL_shutdown() must be called again.
> The second call will make SSL_shutdown() wait for the peer's "close notify"
> 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 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
>
> It is therefore recommended, to check the return value of SSL_shutdown()
> and call SSL_shutdown() again, if the bidirectional shutdown is not yet
> complete (return value of the first call is 0). As the shutdown is not
> specially handled in the SSLv2 protocol, SSL_shutdown() will succeed on
> the first call.
>
> The behaviour of SSL_shutdown() additionally depends on the underlying BIO.
>
28c70
< handshake has been finished or an error occurred.
---
> handshake step has been finished or an error occurred.
40a83,88
> 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.
>
49c97,98
< The shutdown was successfully completed.
---
> The shutdown was successfully completed. The "close notify" alert was sent
> and the peer's "close notify" alert was received.
53,54c102,105
< The shutdown was not successful. Call SSL_get_error() with the return
< value B<ret> to find out the reason.
---
> 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.
59c110
< at the protocol level or a connection failure occurred. It can also occur of
---
> at the protocol level or a connection failure occurred. It can also occur if
61c112,113
< Call SSL_get_error() with the return value B<ret> to find out the reason.
---
> Call L<SSL_get_error(3)|SSL_get_error(3)> with the return value B<ret>
> to find out the reason.
68a121
> L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>,