David Schwartz wrote:
if ((s->s3->wpend_tot > (int)len)
|| ((s->s3->wpend_buf != buf) &&
!(s->mode & SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER))
|| (s->s3->wpend_type != type))
{
SSLerr(SSL_F_SSL3_WRITE_PENDING,SSL_R_BAD_WRITE_RETRY);
return(-1);
}
This 'ol chestnut.
But the piece of code quoted above only serves the purpose of performing
the check and generate a "self serving error code" no other part of
OpenSSL is impacted by the setting. Check out my other threads on
openssl-users list over the past few years.
Maybe someone can better describe the idea / concept / purpose behind
this configuration setting and why the
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER isn't turned on by default ?
But I think what you are trying to do is just not sane. You need a
definitive send queue to flush to OpenSSL. (Not that it has to be insane.
One could imagine an SSL library that supported this. OpenSSL just doesn't,
largely for historic reasons.)
Of course it is sane; it is sane for OpenSSL to provide clear
demarkation of exactly which data is committed and which data is
uncommitted.
It is conceivably possible for an application to implement a priority
queue just above the SSL layer so that its possible for the application
data to change between a previously failed call and the next successive
SSL_write() call. It is after all possible to do this with direct
send() calls to a socket since the kernel provides clear demarkation.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
