From e307e616f25a6b7b0f343fc1e62a35b2cba888f3 Mon Sep 17 00:00:00 2001 From: Kurt Roeckx Date: Mon, 13 Apr 2020 13:01:29 +0200 Subject: [PATCH] Improve SSL_shutdown documentation. Reviewed-by: Tomas Mraz (Merged from https://github.com/openssl/openssl/pull/11531) --- doc/man3/SSL_shutdown.pod | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/doc/man3/SSL_shutdown.pod b/doc/man3/SSL_shutdown.pod index 608cd7195e..f7476500fd 100644 --- a/doc/man3/SSL_shutdown.pod +++ b/doc/man3/SSL_shutdown.pod @@ -75,6 +75,16 @@ state but not actually send the close_notify alert messages, see L. 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 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 should not get called, it may misleadingly +indicate an error even though no error occurred. =item Z<>1 -- 2.25.1