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
