Whoops real sorry guys! Its not a Win32::GUI problem. I finally traced the bug to MIME::Base64.
Here is an outline of what I am trying to do. Maybe it will help understand the reason for the weird behavior better. and maybe someone will point out a better way to do it. -------- step 1: bind to host and port and wait for incoming connections. step 2: on incoming connection accept it and pass it on to a thread. do step 1 and 2 forever. thread: step 1: connect to intranet or company proxy/firewall step 2: send a CONNECT request to secureapacheproxy:443 with the required authentication. (secureapacheproxy running on a cable or dsl somewhere) step 3: check the data from proxy for the string 200. if 200 is received then we are connected to secureapacheproxy then proceed to step 6 else proceed to step 5. step 5: proxy request failed for whatever reason. for debug purposes dump the proxy response to STDOUT and close both sockets (from client and to proxy) and exit thread. step 6: start SSL on the proxied connected to secureapachesocket socket by calling start_SSL(proxySocket) function. on error close both sockets and exit thread. step 7: on packets available on client socket copy to proxy socket and vice versa for ever till there either sockets close or either socket reports an error. on close or error close both sockets and exit thread. --------- In the browser you could use a proxyautoconfig Javascript to direct the browser to the appropriate proxy automatically when accessing blocked (email) sites. -------- In the GUI I had a password prompt for the user to enter his password for HTTP Basic Auth to the proxy. So in the script I had to base64 encode the userid:password for auth to work. By default encode_base64() pads the encoded string with a "\n". The proxy was not reading the extra "\n" that MIME::Base64 introduced. Therefore when start_SSL kept failing because of the extra "\n" that was being sent. Thanks a lot, Jeremy and others! Yes I am planning to put up the script on CPAN soon. Will keep you posted. Right now the only issue with the script is that it really eats up memory. Once around 250 threads have been spawned and destroyed, Taskmanager reports that the script is using 200 Megs of RAM! Theres no option but to stop it and start it again. I am using the Net_SSLeay 1.25 compiled packages from theoryx5.uwinnipeg.ca. Thanks a lot once again. Cheers, Emmanuel > --- Ursprüngliche Nachricht --- > Von: "Jeremy White" <[EMAIL PROTECTED]> > An: [EMAIL PROTECTED], [EMAIL PROTECTED] > Kopie: perl-win32-gui-users@lists.sourceforge.net > Betreff: Re: [win32gui] Re: [perl-win32-gui-users] SSLeay fails when GUI > is initialized > Datum: Wed, 20 Jul 2005 07:24:06 +0000 > > > >Yup the script works perfectly fine if no GUI is created. > > I agree with Rob, using Win32-gui should not cause your problems, yet it > seems it is somehow - I'm a little concerned that something strange is > going > on. > > >In fact I had no intention of writing a GUI as it served my purpose > without > >one. But certain "non command prompt friendly" friends of mine would like > a > >GUI. So I tried my hand at creating one. > > > >Let me try undef'ing all the GUI objects and see if it makes a > difference. > > If that doesn't make a difference could you submit some example code? Just > a > few lines showing the connection working in a script, and then the > connection failing within a GUI? > > Cheers, > > jez. > > -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse f�r Mail, Message, More +++
