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 Engineer
F5 Networks, Inc.
www.f5.com
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 14, 2002 11:25 AM
> To: John Hughes
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: SSL_pending() and SSL_ERROR_WANT_READ
>
>
> 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
> > variable is updated in ssl3_get_record() when an SSL record header
> > is processed. If the remainder of that SSL record has not yet been
> > received, SSL_pending() will return a non-zero value even though
> > there may not be that amount of data ready. This contradicts the
> > SSL_pending() manpage, which indicates that its return value
> > represents the amount of data immediately available. I haven't yet
> > examined whether SSLv2 connections experience the same problem.
>
> This patch should fix the bug:
>
> diff -u -r1.57 s3_lib.c
> --- s3_lib.c 2001/10/20 17:56:35 1.57
> +++ s3_lib.c 2002/03/14 19:20:58
> @@ -943,6 +943,9 @@
>
> int ssl3_pending(SSL *s)
> {
> + if (s->rstate == SSL_ST_READ_BODY)
> + return 0;
> +
> return (s->s3->rrec.type == SSL3_RT_APPLICATION_DATA) ?
> s->s3->rrec.length : 0;
> }
>
>
>
> --
> Bodo Möller <[EMAIL PROTECTED]>
> PGP
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
