Hi,
I have used the curl options properly. And I can able to get
application data continuously from specific server if I do following
modification in s3_pkt.c file. Please refer if condition from s3_lib.c file.
This -1 is returning from s3_pkt.c file(SSL_MODE_AUTO_RETRY). It is
returning -1 while receiving handshake data instead of application data.
Whether we need to set s->s3->in_read_app_data=2 in the second module.
Please let me know whether it will create any problem or not.
Module 1:
static int ssl3_read_internal(SSL *s, void *buf, int len, int peek)
{
int ret;
clear_sys_error();
if (s->s3->renegotiate) ssl3_renegotiate_check(s);
//s->s3->in_read_app_data=1;
ret=s->method->ssl_read_bytes(s,SSL3_RT_APPLICATION_DATA,buf,len,peek);
if ((ret == -1) && (s->s3->in_read_app_data == 2))
//Original
{
/* ssl3_read_bytes decided to call
s->handshake_func, which
* called ssl3_read_bytes to read handshake data.
* However, ssl3_read_bytes actually found
application data
* and thinks that application data makes sense
here; so disable
* handshake processing and try to read application
data again. */
s->in_handshake++;
ret=s->method->ssl_read_bytes(s,SSL3_RT_APPLICATION_DATA,buf,len,peek);
s->in_handshake--;
}
.
.
.
Etc
}
Module 2:
if (!(s->mode & SSL_MODE_AUTO_RETRY))
{
if (s->s3->rbuf.left == 0) /* no read-ahead left? */
{
BIO *bio;
/* In the case where we try to read application
data,
* but we trigger an SSL handshake, we return -1
with
* the retry option set. Otherwise renegotiation
may
* cause nasty problems in the blocking world */
s->rwstate=SSL_READING;
bio=SSL_get_rbio(s);
BIO_clear_retry_flags(bio);
BIO_set_retry_read(bio);
s->s3->in_read_app_data=2; //
Added statement
return(-1);
}
}
