From aa4d426b4d3527d7e166df1a05058c9a4a0f6683 Mon Sep 17 00:00:00 2001 From: Wojtek Kosior Date: Fri, 30 Apr 2021 00:33:56 +0200 Subject: initial/final commit --- openssl-1.1.0h/doc/ssl/SSL_get_error.pod | 143 +++++++++++++++++++++++++++++++ 1 file changed, 143 insertions(+) create mode 100644 openssl-1.1.0h/doc/ssl/SSL_get_error.pod (limited to 'openssl-1.1.0h/doc/ssl/SSL_get_error.pod') diff --git a/openssl-1.1.0h/doc/ssl/SSL_get_error.pod b/openssl-1.1.0h/doc/ssl/SSL_get_error.pod new file mode 100644 index 0000000..47d2358 --- /dev/null +++ b/openssl-1.1.0h/doc/ssl/SSL_get_error.pod @@ -0,0 +1,143 @@ +=pod + +=head1 NAME + +SSL_get_error - obtain result code for TLS/SSL I/O operation + +=head1 SYNOPSIS + + #include + + int SSL_get_error(const SSL *ssl, int ret); + +=head1 DESCRIPTION + +SSL_get_error() returns a result code (suitable for the C "switch" +statement) for a preceding call to SSL_connect(), SSL_accept(), SSL_do_handshake(), +SSL_read(), SSL_peek(), or SSL_write() on B. The value returned by +that TLS/SSL I/O function must be passed to SSL_get_error() in parameter +B. + +In addition to B and B, SSL_get_error() inspects the +current thread's OpenSSL error queue. Thus, SSL_get_error() must be +used in the same thread that performed the TLS/SSL I/O operation, and no +other OpenSSL function calls should appear in between. The current +thread's error queue must be empty before the TLS/SSL I/O operation is +attempted, or SSL_get_error() will not work reliably. + +=head1 RETURN VALUES + +The following return values can currently occur: + +=over 4 + +=item SSL_ERROR_NONE + +The TLS/SSL I/O operation completed. This result code is returned +if and only if B 0>. + +=item SSL_ERROR_ZERO_RETURN + +The TLS/SSL connection has been closed. +If the protocol version is SSL 3.0 or higher, this result code is returned only +if a closure alert has occurred in the protocol, i.e. if the connection has been +closed cleanly. +Note that in this case B does not necessarily +indicate that the underlying transport has been closed. + + +=item SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE + +The operation did not complete; the same TLS/SSL I/O function should be +called again later. If, by then, the underlying B has data +available for reading (if the result code is B) +or allows writing data (B), then some TLS/SSL +protocol progress will take place, i.e. at least part of an TLS/SSL +record will be read or written. Note that the retry may again lead to +a B or B condition. +There is no fixed upper limit for the number of iterations that +may be necessary until progress becomes visible at application +protocol level. + +For socket Bs (e.g. when SSL_set_fd() was used), select() or +poll() on the underlying socket can be used to find out when the +TLS/SSL I/O function should be retried. + +Caveat: Any TLS/SSL I/O function can lead to either of +B and B. In particular, +SSL_read() or SSL_peek() may want to write data and SSL_write() may want +to read data. This is mainly because TLS/SSL handshakes may occur at any +time during the protocol (initiated by either the client or the server); +SSL_read(), SSL_peek(), and SSL_write() will handle any pending handshakes. + +=item SSL_ERROR_WANT_CONNECT, SSL_ERROR_WANT_ACCEPT + +The operation did not complete; the same TLS/SSL I/O function should be +called again later. The underlying BIO was not connected yet to the peer +and the call would block in connect()/accept(). The SSL function should be +called again when the connection is established. These messages can only +appear with a BIO_s_connect() or BIO_s_accept() BIO, respectively. +In order to find out, when the connection has been successfully established, +on many platforms select() or poll() for writing on the socket file descriptor +can be used. + +=item SSL_ERROR_WANT_X509_LOOKUP + +The operation did not complete because an application callback set by +SSL_CTX_set_client_cert_cb() has asked to be called again. +The TLS/SSL I/O function should be called again later. +Details depend on the application. + +=item SSL_ERROR_WANT_ASYNC + +The operation did not complete because an asynchronous engine is still +processing data. This will only occur if the mode has been set to SSL_MODE_ASYNC +using L or L and an asynchronous capable +engine is being used. An application can determine whether the engine has +completed its processing using select() or poll() on the asynchronous wait file +descriptor. This file descriptor is available by calling +L or L. The TLS/SSL I/O +function should be called again later. The function B be called from the +same thread that the original call was made from. + +=item SSL_ERROR_WANT_ASYNC_JOB + +The asynchronous job could not be started because there were no async jobs +available in the pool (see ASYNC_init_thread(3)). This will only occur if the +mode has been set to SSL_MODE_ASYNC using L or +L and a maximum limit has been set on the async job pool +through a call to L. The application should retry the +operation after a currently executing asynchronous operation for the current +thread has completed. + +=item SSL_ERROR_SYSCALL + +Some non-recoverable I/O error occurred. +The OpenSSL error queue may contain more information on the error. +For socket I/O on Unix systems, consult B for details. + +=item SSL_ERROR_SSL + +A failure in the SSL library occurred, usually a protocol error. The +OpenSSL error queue contains more information on the error. + +=back + +=head1 SEE ALSO + +L, L + +=head1 HISTORY + +SSL_ERROR_WANT_ASYNC was added in OpenSSL 1.1.0. + +=head1 COPYRIGHT + +Copyright 2000-2016 The OpenSSL Project Authors. All Rights Reserved. + +Licensed under the OpenSSL license (the "License"). You may not use +this file except in compliance with the License. You can obtain a copy +in the file LICENSE in the source distribution or at +L. + +=cut -- cgit v1.2.3