to a bug on the client side
Reply-To: 
In-Reply-To: 
<2a0efb9c05d0164e98f19bb0af3708c7120c61f...@usmbx1.msg.corp.akamai.com>

On Sat, Apr 26, 2014 at 01:16:08PM -0400, Salz, Rich wrote:
> If the API requires the same buffer and count, then perhaps the SSL structure 
> should hold those values, and require the user to send NULL/0 in subsequent 
> calls?
> 
> Or assert().  It's a programming error that requires source changes to fix. 

To me this all sounds like an we end up in an inconsistent state.

I'm expecting write(2) like behaviour of SSL_write(). I think it
should either have returned < 0 and have done nothing with the
buffer or > 0, but maybe != num, and that the rest of the buffer
needs to be send again the next call at which point it might
return the < 0.

But maybe that doesn't work correctly for the blocking case?  The
documentation mentions that you might need to call SSL_read()
because of renegiotation, and I would love that the library
could just handle that internally without the application having
to call the correct function and then later call SSL_write() again
with the same parameters.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to