diff options
Diffstat (limited to 'src/lib/libssl/src/doc/ssl/SSL_accept.pod')
-rw-r--r-- | src/lib/libssl/src/doc/ssl/SSL_accept.pod | 72 |
1 files changed, 72 insertions, 0 deletions
diff --git a/src/lib/libssl/src/doc/ssl/SSL_accept.pod b/src/lib/libssl/src/doc/ssl/SSL_accept.pod new file mode 100644 index 0000000000..0c79ac515e --- /dev/null +++ b/src/lib/libssl/src/doc/ssl/SSL_accept.pod | |||
@@ -0,0 +1,72 @@ | |||
1 | =pod | ||
2 | |||
3 | =head1 NAME | ||
4 | |||
5 | SSL_accept - wait for a TLS/SSL client to initiate a TLS/SSL handshake | ||
6 | |||
7 | =head1 SYNOPSIS | ||
8 | |||
9 | #include <openssl/ssl.h> | ||
10 | |||
11 | int SSL_accept(SSL *ssl); | ||
12 | |||
13 | =head1 DESCRIPTION | ||
14 | |||
15 | SSL_accept() waits for a TLS/SSL client to initiate the TLS/SSL handshake. | ||
16 | The communication channel must already have been set and assigned to the | ||
17 | B<ssl> by setting an underlying B<BIO>. | ||
18 | |||
19 | =head1 NOTES | ||
20 | |||
21 | The behaviour of SSL_accept() depends on the underlying BIO. | ||
22 | |||
23 | If the underlying BIO is B<blocking>, SSL_accept() will only return once the | ||
24 | handshake has been finished or an error occurred, except for SGC (Server | ||
25 | Gated Cryptography). For SGC, SSL_accept() may return with -1, but | ||
26 | SSL_get_error() will yield B<SSL_ERROR_WANT_READ/WRITE> and SSL_accept() | ||
27 | should be called again. | ||
28 | |||
29 | If the underlying BIO is B<non-blocking>, SSL_accept() will also return | ||
30 | when the underlying BIO could not satisfy the needs of SSL_accept() | ||
31 | to continue the handshake. In this case a call to SSL_get_error() with the | ||
32 | return value of SSL_accept() will yield B<SSL_ERROR_WANT_READ> or | ||
33 | B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after | ||
34 | taking appropriate action to satisfy the needs of SSL_accept(). | ||
35 | The action depends on the underlying BIO. When using a non-blocking socket, | ||
36 | nothing is to be done, but select() can be used to check for the required | ||
37 | condition. When using a buffering BIO, like a BIO pair, data must be written | ||
38 | into or retrieved out of the BIO before being able to continue. | ||
39 | |||
40 | =head1 RETURN VALUES | ||
41 | |||
42 | The following return values can occur: | ||
43 | |||
44 | =over 4 | ||
45 | |||
46 | =item 1 | ||
47 | |||
48 | The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been | ||
49 | established. | ||
50 | |||
51 | =item 0 | ||
52 | |||
53 | The TLS/SSL handshake was not successful but was shut down controlled and | ||
54 | by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the | ||
55 | return value B<ret> to find out the reason. | ||
56 | |||
57 | =item -1 | ||
58 | |||
59 | The TLS/SSL handshake was not successful because a fatal error occurred either | ||
60 | at the protocol level or a connection failure occurred. The shutdown was | ||
61 | not clean. It can also occur of action is need to continue the operation | ||
62 | for non-blocking BIOs. Call SSL_get_error() with the return value B<ret> | ||
63 | to find out the reason. | ||
64 | |||
65 | =back | ||
66 | |||
67 | =head1 SEE ALSO | ||
68 | |||
69 | L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_connect(3)|SSL_connect(3)>, | ||
70 | L<SSL_shutdown(3)|SSL_shutdown(3)>, L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)> | ||
71 | |||
72 | =cut | ||