settings are kept, a side effect is the handling of the current SSL session.
If a session is still B<open>, it is considered bad and will be removed
from the session cache, as required by RFC2246. A session is considered open,
-if L<SSL_shutdown(3)|SSL_shutdown(3)> was not called for the connection
-or at least L<SSL_set_shutdown(3)|SSL_set_shutdown(3)> was used to
+if L<SSL_shutdown(3)> was not called for the connection
+or at least L<SSL_set_shutdown(3)> was used to
set the SSL_SENT_SHUTDOWN state.
If a session was closed cleanly, the session object will be kept and all
session was a TLSv1 session, a SSL client object will use a TLSv1 client
method for the next handshake and a SSL server object will use a TLSv1
server method, even if TLS_*_methods were chosen on startup. This
-will might lead to connection failures (see L<SSL_new(3)|SSL_new(3)>)
+will might lead to connection failures (see L<SSL_new(3)>)
for a description of the method's properties.
=head1 WARNINGS
handshake). It only makes sense for a new connection with the exact
same peer that shares these settings, and may fail if that peer
changes its settings between connections. Use the sequence
-L<SSL_get_session(3)|SSL_get_session(3)>;
-L<SSL_new(3)|SSL_new(3)>;
-L<SSL_set_session(3)|SSL_set_session(3)>;
-L<SSL_free(3)|SSL_free(3)>
+L<SSL_get_session(3)>;
+L<SSL_new(3)>;
+L<SSL_set_session(3)>;
+L<SSL_free(3)>
instead to avoid such failures
-(or simply L<SSL_free(3)|SSL_free(3)>; L<SSL_new(3)|SSL_new(3)>
+(or simply L<SSL_free(3)>; L<SSL_new(3)>
if session reuse is not desired).
=head1 RETURN VALUES
=back
-L<SSL_new(3)|SSL_new(3)>, L<SSL_free(3)|SSL_free(3)>,
-L<SSL_shutdown(3)|SSL_shutdown(3)>, L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>,
-L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>, L<ssl(3)|ssl(3)>,
-L<SSL_CTX_set_client_cert_cb(3)|SSL_CTX_set_client_cert_cb(3)>
+L<SSL_new(3)>, L<SSL_free(3)>,
+L<SSL_shutdown(3)>, L<SSL_set_shutdown(3)>,
+L<SSL_CTX_set_options(3)>, L<ssl(3)>,
+L<SSL_CTX_set_client_cert_cb(3)>
=cut