Rev. proxying a java applet

[aruzsi]

Hi Francis,

Thank you for your questions. ;-)
I try to answer them as I can.

> > I want to rev. proxying a page with java applet. I think it is usual
> and
> > nothing special ...
> 
> The applet itself will be a http request, which it looks like you have
> working.

The start page is almost working.
First of all there are some upstream servers which are connected to
different devices (serial line) so I want some URL to different the
servers or (places).

So I use http://nginx.server.com/<diff-places>/<orig_URL>.

Something is working because IcedTea asks my permissions for
Java thing and the siloutte of the WEB page appears full of error
messages (missing IDs, etc.)
I think this first stage is not correct because the different (virtual)
URL.
 
> What the applet actually *does* is another matter -- and in general,
> only you know what that is.

Yes, I know this. I just think I know some thing about the behaviour
of the applet on the network.

> > The java applet wants to connect to TCP/7000 on the proxied host.
> > Something has happened but it doesn't work. :-(
> 
> Can you describe the full network traffic when the applet works
> normally?

Maybe. I can use tcpdump of course.
With rev. proxy and without it (through SSH port forwarding). Is that
right for you?

> The machines involved are:
> 
> * the client (your browser)
> * the nginx server
> * the upstream web server

OK.
As I can see no communication between my client (browser) and 
upstream server. It would not be a problem, because I want to
proxying everything (separated subnet, no route, firewall, etc.),
But my browser needs communicate on TCP/7000 port to the
nginx or upstream server and it doesn't try. :-(
I think some other Java archives (.jar) not loaded by my browser.
I don't know why.

> If nginx were not involved, the client would make a http request of
> the
> upstream web server to fetch the applet, and then... what?

I don't know.
I tried to check the upstream server's Apache access and error.log
without any information for me except missing some Java files
when nginx is involved in the request.
 
> The applet runs on the client and tries to access port 7000 of the
> server
> the client got it from? And speaks http on port 7000; or speaks its
> own
> protocol? Does it use anything other than port 7000?

I think client try to connect TCP/7000 but not HTTP. (without nginx,
so in normal situation when no proxy)
But something is different because I did a test when the TCP/7000
wasn't included in SSH port forwarding. The applet started perfectly
without the error messeges in it (missing IDs, etc.) but when I try to
connect to the serial port I got an error message that no communication
which was right because the TCP/7000 wasn't forwarded.
So I'm somewhere before the 7000 port problem, I think. The behaviour of the
applet
is different when the proxy is involved in the communication or normal
SSH port forwarding was used without (or disabled) TCP/7000 port.
And that's why I don't understand what is the difference!

> If it speaks http, then possibly a nginx http server{} which listens
> on
> port 7000 and proxy_passes to the upstream port 7000 could work.
> 
> If it uses a single port, then possible a nginx stream server{}
> could work.

Not HTTP protocol, I think. TCP stream between the browser (client) and
 remote server.

> If the applet knows the upstream it came from, and tries to access
> that
> directly, then nginx is probably not involved.

I have to proxy all the communication. Of course SSH port forwarding
will work but I don't like it or I don't want it.
 
> The best way to understand how to proxy this service (if it is even
> possible), is to know what it wants to do, at the network level.

I try to get some information about this applet.
 
> Good luck with it,

Thank you. Will you help me if I got more information?
 
TIA,

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,265320,265387#msg-265387