|
@@ -2,7 +2,7 @@
|
|
|
|
|
|
=head1 NAME
|
|
|
|
|
|
-SSL_accept - Wait for a TLS client to initiate a TLS handshake
|
|
|
+SSL_accept - wait for a TLS/SSL client to initiate a TLS/SSL handshake
|
|
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
|
@@ -12,22 +12,22 @@ SSL_accept - Wait for a TLS client to initiate a TLS handshake
|
|
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
|
|
-SSL_accept() waits for a TLS client to initiate the TLS handshake.
|
|
|
+SSL_accept() waits for a TLS/SSL client to initiate the TLS/SSL handshake.
|
|
|
The communication channel must already have been set and assigned to the
|
|
|
-B<ssl> by setting an underlying B<BIO>. The behaviour of SSL_accept() depends
|
|
|
+B<ssl> by setting an underlying B<BIO>. The behavior of SSL_accept() depends
|
|
|
on the underlying BIO.
|
|
|
|
|
|
-If the underlying BIO is B<blocking>, SSL_accept() will only return, once the
|
|
|
-handshake has been finished or an error occured, except for SGC (Server
|
|
|
-Gated Cryptography). For SGC SSL_accept() may return with -1 but
|
|
|
-SSL_get_error() will yield SSL_ERROR_WANT_READ/WRITE and SSL_accept()
|
|
|
+If the underlying BIO is B<blocking>, SSL_accept() will only return once the
|
|
|
+handshake has been finished or an error occurred, except for SGC (Server
|
|
|
+Gated Cryptography). For SGC, SSL_accept() may return with -1, but
|
|
|
+SSL_get_error() will yield B<SSL_ERROR_WANT_READ/WRITE> and SSL_accept()
|
|
|
should be called again.
|
|
|
|
|
|
-If the underlying BIO is B<non-blocking>, SSL_accept() will also return,
|
|
|
+If the underlying BIO is B<non-blocking>, SSL_accept() will also return
|
|
|
when the underlying BIO could not satisfy the needs of SSL_accept()
|
|
|
to continue the handshake. In this case a call to SSL_get_error() with the
|
|
|
-return value of SSL_accept() will yield SSL_ERROR_WANT_READ or
|
|
|
-SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after
|
|
|
+return value of SSL_accept() will yield B<SSL_ERROR_WANT_READ> or
|
|
|
+B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
|
|
|
taking appropriate action to satisfy the needs of SSL_accept().
|
|
|
The action depends on the underlying BIO. When using a non-blocking socket,
|
|
|
nothing is to be done, but select() can be used to check for the required
|
|
@@ -42,20 +42,20 @@ The following return values can occur:
|
|
|
|
|
|
=item 1
|
|
|
|
|
|
-The TLS handshake was successfully completed, a TLS connection has been
|
|
|
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
|
|
|
established.
|
|
|
|
|
|
=item 0
|
|
|
|
|
|
-The TLS handshake was not successfull but was shut down controlled and
|
|
|
-by the specifications of the TLS protocol. Call SSL_get_error() with the
|
|
|
+The TLS/SSL handshake was not successful but was shut down controlled and
|
|
|
+by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
|
|
|
return value B<ret> to find out the reason.
|
|
|
|
|
|
=item -1
|
|
|
|
|
|
-The TLS handshake was not successfull, because a fatal error occured either
|
|
|
-at the protocol level or a connection failure occured. The shutdown was
|
|
|
-not clean. It can also occure of action is need to continue the operation
|
|
|
+The TLS/SSL handshake was not successful because a fatal error occurred either
|
|
|
+at the protocol level or a connection failure occurred. The shutdown was
|
|
|
+not clean. It can also occur of action is need to continue the operation
|
|
|
for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
|
|
|
to find out the reason.
|
|
|
|