On Thu, Nov 30, 2000 at 09:37:29AM -0800, Geoff Thorpe wrote:
> The more tricky issue is one of the SSL state itself ... in theory doing
> an SSL_peek() should allow some data to be generated but with a guarantee
> that the internal state is completely unchanged.
Should it? I'd have thought that what counts is that any application
data stays in the buffer for future SSL_read/peek() calls, whereas if
the request cannot be satisfied, SSL_peek() would return an error just
like SSL_read(). This should be OK for applications -- you can use
SSL_peek() to decide how to process the data sent by the peer, but if
there's no data because of an error, then you don't have much of a
choice anyway.
My plans include adding flags to SSL objects that allow disabling
BIO_read and/or BIO_write. Then instead of calling SSL_pending(),
applications could disable all BIO operations and call SSL_peek(),
which unlike SSL_pending() can report errors (so it'll work when
readahead is enabled, which is a case in which SSL_pending()
does not work well).
--
Bodo M�ller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
