Anonymous Monk said: it still insists on trying to connect directly to the remote server rather than using the proxy.
...I can't be sure exactly what you're trying to do, but the thing that jumps out at me has to do with the Java Applet security model.
You see, in order to make Applets safe to run in the first place, they are placed under the restriction that no Applet may make a connection to a host other than that from which it is originally sent. (Applets are also prevented from accessing the local filesystem where they run, and from invoking processes on the local machine.)
I'm sure that most of us can appreciate that we would never be sent an Applet that wanders into our browser, snoops out the topology of our network, and then transmits it to the originator.
One way you can test this is to run the Applet in the AppletViewer that comes with the Java SDK. It is possible to force the AppletViewer to override the network connection restriction while you are testing and developing. If you can get the AppletViewer to behave as you wish (after you turn off the security), then this problem is with the security model.
If you discover this to be the case, the only workaround I can think of would be to slurp the Applet class file (or the jar file that contains it) and run it from a server running on your local host. Having done that, the Applet will be allowed to make network connections to the local host which is where your proxy lives. (I guess)
Not a Perlish solution, but one that might work. If that is not suitable for you (or if I've missed the problem completely), then give us a little more detail and perhaps there's a simpler (or "right-er") solution.
...All the world looks like -well- all the world,
when your hammer is Perl.
---v
|