> It is very simple - if SSL_read() has to do other work than reading
> application data records (encrypted user data) like renegotiation
> it should return WANT_READ.
An SSL_read on a blocking socket should block until data can be read,
just
as a regular 'read' on a TCP connection does.
> Than upper layer may retry SSL_read() after select().
> For me this is SSL_read() problem and may be simply corrected.
That makes no sense. Why should the upper layer retry when it already
asked
for a blocking read?
> > >That 'read' blocks forever because there was
> > > never any application-level data to read. Sorry, you're screwed.
> I do not agree. SSL_read() should be corrected.
If you call SSL_read, an application-level read function, with a
blocking
socket, you are asking it to block until it can read application-level data.
The error is simple -- for an SSL connection, a read hit from 'select'
does
not guarantee that application-level data has been received, so it is an
error to call an application-level blocking read function just because of
this. The change you would suggest would break applications that use a
blocking SSL_read correctly, as a way to block until application-level data
has been read.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
