summaryrefslogtreecommitdiffstats
path: root/doc/ssl
diff options
context:
space:
mode:
authorLutz Jänicke <jaenicke@openssl.org>2001-09-13 13:21:38 +0000
committerLutz Jänicke <jaenicke@openssl.org>2001-09-13 13:21:38 +0000
commit6d8566f2ebbd20a2f6e7ec656e299f5359138467 (patch)
tree05a6c64a4219abbed3b02252844a2e20d1b3d8b5 /doc/ssl
parent4e1b0d890489a1e13a3ea431de7dafda548c2d74 (diff)
Rework section about return values another time (based on hints from
Bodo Moeller).
Diffstat (limited to 'doc/ssl')
-rw-r--r--doc/ssl/SSL_read.pod12
-rw-r--r--doc/ssl/SSL_write.pod8
2 files changed, 9 insertions, 11 deletions
diff --git a/doc/ssl/SSL_read.pod b/doc/ssl/SSL_read.pod
index 6b47f2fbd1..f6c37f77e4 100644
--- a/doc/ssl/SSL_read.pod
+++ b/doc/ssl/SSL_read.pod
@@ -83,11 +83,13 @@ bytes actually read from the TLS/SSL connection.
=item 0
-The read operation was not successful, the SSL connection was closed by the
-peer by sending a "close notify" alert. The SSL_RECEIVED_SHUTDOWN flag in
-the ssl shutdown state is set (see L<SSL_shutdown(3)|SSL_shutdown(3)>,
-L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>).
-Call SSL_get_error() with the return value B<ret> to find out,
+The read operation was not successful. The reason may either be a clean
+shutdown due to a "close notify" alert sent by the peer (in which case
+the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown state is set
+(see L<SSL_shutdown(3)|SSL_shutdown(3)>,
+L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>). It is also possible, that
+the peer simply shut down the underlying transport and the shutdown is
+incomplete. Call SSL_get_error() with the return value B<ret> to find out,
whether an error occurred or the connection was shut down cleanly
(SSL_ERROR_ZERO_RETURN).
diff --git a/doc/ssl/SSL_write.pod b/doc/ssl/SSL_write.pod
index 7299f6e2ee..dfa42e9aee 100644
--- a/doc/ssl/SSL_write.pod
+++ b/doc/ssl/SSL_write.pod
@@ -78,12 +78,8 @@ bytes actually written to the TLS/SSL connection.
=item 0
-The write operation was not successful, because the write side of the
-SSL connection was shut down (the SSL_SENT_SHUTDOWN flag in the shutdown
-state is set) by calling L<SSL_shutdown(3)|SSL_shutdown(3)> or
-L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>. It is also possible, that the
-underlying connection was closed.
-Call SSL_get_error() with the return value B<ret> to find out,
+The write operation was not successful. Probably the underlying connection
+was closed. Call SSL_get_error() with the return value B<ret> to find out,
whether an error occurred or the connection was shut down cleanly
(SSL_ERROR_ZERO_RETURN).