From 5dadf34209c288b8fffba1016e6a3c9446381153 Mon Sep 17 00:00:00 2001
From: Rob Austein <sra@hactrn.net>
Date: Thu, 7 Jun 2007 02:37:32 +0000
Subject: Replace hacked OpenSSL code with OpenSSL 0.9.8e distribution.

svn path=/openssl/Makefile; revision=659
---
 openssl/vendor/current/doc/ssl/SSL_accept.pod | 76 ---------------------------
 1 file changed, 76 deletions(-)
 delete mode 100644 openssl/vendor/current/doc/ssl/SSL_accept.pod

(limited to 'openssl/vendor/current/doc/ssl/SSL_accept.pod')

diff --git a/openssl/vendor/current/doc/ssl/SSL_accept.pod b/openssl/vendor/current/doc/ssl/SSL_accept.pod
deleted file mode 100644
index cc724c0d..00000000
--- a/openssl/vendor/current/doc/ssl/SSL_accept.pod
+++ /dev/null
@@ -1,76 +0,0 @@
-=pod
-
-=head1 NAME
-
-SSL_accept - wait for a TLS/SSL client to initiate a TLS/SSL handshake
-
-=head1 SYNOPSIS
-
- #include <openssl/ssl.h>
-
- int SSL_accept(SSL *ssl);
-
-=head1 DESCRIPTION
-
-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>.
-
-=head1 NOTES
-
-The behaviour 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 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
-when the underlying BIO could not satisfy the needs of SSL_accept()
-to continue the handshake, indicating the problem by the return value -1.
-In this case a call to SSL_get_error() with the
-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
-condition. When using a buffering BIO, like a BIO pair, data must be written
-into or retrieved out of the BIO before being able to continue.
-
-=head1 RETURN VALUES
-
-The following return values can occur:
-
-=over 4
-
-=item 1
-
-The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
-established.
-
-=item 0
-
-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 E<lt>0
-
-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.
-
-=back
-
-=head1 SEE ALSO
-
-L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_connect(3)|SSL_connect(3)>,
-L<SSL_shutdown(3)|SSL_shutdown(3)>, L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>,
-L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>,
-L<SSL_do_handshake(3)|SSL_do_handshake(3)>,
-L<SSL_CTX_new(3)|SSL_CTX_new(3)>
-
-=cut
-- 
cgit v1.2.3