On Thu, Mar 14, 2002 at 01:00:46PM -0800, John Hughes wrote:
Since s-rstate is set to SSL_ST_READ_HEADER prior to record
decryption and decompression, wouldn't SSL_pending() still
incorrectly indicate that there is data ready to be read in cases
where either of these fail?
I guess so, but
Title: RE: SSL_pending() and SSL_ERROR_WANT_READ
Hi John, Lutz,
Thanks for your reply. I can reproduce the
SSL_pending() reporting non-zero but immediate call to SSL_read() returns
WANT_READ. Since SSL_read() will not
block when using nonblocking socket, we should be safe to not rely
John Hughes [EMAIL PROTECTED]:
I can confirm: There is a discrepancy between the SSL_pending()
manpage and the source. SSL_pending() returns rrec.length in
ssl3_pending() (as of 0.9.6a, we also verify that the SSL record
being processed is application data, else zero is returned). This
Title: RE: SSL_pending() and SSL_ERROR_WANT_READ
Bodo,
Since s-rstate is set to SSL_ST_READ_HEADER prior to record decryption and decompression, wouldn't SSL_pending() still incorrectly indicate that there is data ready to be read in cases where either of these fail?
John Hughes
Software
Hi,
SSL_pending() returns the number of bytes in the SSL buffer that have been
decrypted by not requested by SSL_read(). This will occur when there is a
mismatch between the number of bytes requested by SSL_read() and the block
size used to encrypt/decrypt the data.
SSL_ERROR_WANT_READ (and
