QuasarApp/openssl
4
0
Fork 0
mirror of https://github.com/QuasarApp/openssl.git synced 2025-05-03 13:09:38 +00:00
Code Issues Projects Releases Wiki Activity

Improve SSL_shutdown documentation.

Browse Source 
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11531)
This commit is contained in:
Kurt Roeckx 2020-04-13 13:01:29 +02:00 committed by Richard Levitte
parent 3327c8d6f3
commit e307e616f2
1 changed files with 14 additions and 2 deletions

16
doc/man3/SSL_shutdown.pod

@ -75,6 +75,16 @@ state but not actually send the close_notify alert messages,
see L<SSL_CTX_set_quiet_shutdown(3)>.
When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
and return 1.
Note that this is not standard compliant behaviour.
It should only be done when the peer has a way to make sure all
data has been received and doesn't wait for the close_notify alert
message, otherwise an unexpected EOF will be reported.
There are implementations that do not send the required close_notify alert.
If there is a need to communicate with such an implementation, and it's clear
that all data has been received, do not wait for the peer's close_notify alert.
Waiting for the close_notify alert when the peer just closes the connection will
result in an error being generated.
=head2 First to close the connection
@ -124,8 +134,10 @@ The following return values can occur:
The shutdown is not yet finished: the close_notify was sent but the peer
did not send it back yet.
Call SSL_read() to do a bidirectional shutdown.
The output of L<SSL_get_error(3)> may be misleading, as an
erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
Unlike most other function, returning 0 does not indicate an error.
L<SSL_get_error(3)> should not get called, it may misleadingly
indicate an error even though no error occurred.
=item Z<>1