In message <_A2958@delegate-en.ML_> on 06/02/05(09:09:37) you "James Brooks" <ppufqbdyi-mykgh47vkstw.ml@delegate.org> wrote: |Again, sorry to bother you but I am still having problems with HTTPS |redirects. I have downloaded every version of sslway that is on your ftp |site under sslway old. I noticed that you log file claims you compiled |the win32 9.0.0 version of delegate 050413, So I downloaded all versions |of sslway from sslway-20020226 to sslway-20041208 and still none seem to |fix the problem. I even download openssl and created a new |server-key.pem and server-cert.pem and placed them in the same folder as |delegate. Still no luck with sites that do http to https redirects. |Such as http://mail.berea.edu which redirects to https://mail.berea.edu Are you using DeleGate on Windows??? |I have tried delegate version 8.11.4 to 9.0.2 Here is my setup. | |delegate -f -v -P81 SERVER=https FCL=sslway CMAP=/test/sslway:FSV:https |ADMIN="admin@berea.." RELAY=proxy,delegate:*:*:* URICONV=where:any | |Do you see anything I am doing wrong? |Thanks again for all your help and the great product. The problem is caused by shareing (jamming) a SSL context in SSLway between FCL and FSV, sharing SSLway on memory linked by dinaymic linking. Thus forking SSLway as a process can solve it. SSLway can be invoked as a function of DeleGate like "delegated -Fsslway", it can be used like this: CMAP="delegated -Fsslway:FSV:https" I tested it with DeleGate/9.0.2 on MacOSX exactly as follows, without any extra certificate or private-key: delegated -v -P81 SERVER=https FCL=sslway \ CMAP="delegated -Fsslway:FSV:https" \ ADMIN="me@my.." RELAY="proxy,delegate:*:*:*" URICONV=where:any Then accessed https://delegate:81/-_-https://www.att.com without problem. Cheers, Yutaka -- D G Yutaka Sato <pfqcabdyi-mykgh47vkstw.ml@delegate.org> http://delegate.org/y.sato/ ( - ) National Institute of Advanced Industrial Science and Technology _< >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan Do the more with the less -- B. Fuller
V