Raj wrote:
> I have tried one more method to read the data from the socket,
> which was
> partially successful it is defined as follows
> do
> {
> dwReadDataLen = SSL_read(Serverssl,pBuff,iBufferSize); // Gets
> the
> data from the server side
> SSL_write(SourceSsl,pBuff,dwReadDataLen); // Writes the data back
> to
> the SSL
> } while(dwReadDataLen > 0 );
This is the basic idea of how you proxy, but it can't work for a
general HTTP proxy. For one thing, it assumes the end of a reply is marked
by the close of a connection. This is true for some HTTP requests, but it's
not true in general.
You can write a proxy two different ways:
1) You can understand the protocol you are parsing and know when it
changes directions. Based on this understanding, you can switch from
proxying in one direction to proxying in the other.
2) You can avoid having to understand the protocol you are parsing.
But in this case, you will not know which side is supposed to send data
next, so you must always be ready to proxy in either direction.
It seems you do neither of these two things. You try to proxy in
only one direction at a time but you don't track the protocol. How do you
even know when you've sent the entire request and can even enter this loop?
How do you know when you've read the entire reply and can begin reading the
next request?
Your test condition, 'dwReadDataLen>0' will be true so long as the
connection is healthy. It will typically remain healthy even when the reply
has been fully sent.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
