In message <_A2958@delegate-en.ML_> on 06/02/05(09:09:37)
you "James Brooks" <firstname.lastname@example.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:
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.
D G Yutaka Sato <email@example.com> 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