Rev. proxying a java applet

[Francis Daly]

On Wed, Mar 16, 2016 at 06:43:53AM -0400, aruzsi wrote:

Hi there,

> > 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>.

Start simple.

Get just one working first.

> 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.

Check the apache logs for when you connect to apache directly; you will
want to know what the full set of requests and responses is.

Then when you go through nginx, do you see the same requests and
responses? If not, find out why and fix it.

> > 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.

You will need to know that, if you want to configure nginx to support it.

For example: how does the applet know to use port 7000? How does the
applet know which server to connect to on port 7000?

> > 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?

SSH port forwarding is a new thing.

Keep it simple.

Until you know what is supposed to happen, you will not be able to know
whether everything is working the way you want.

> > 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.

Should there be any communication there?

> 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. :-(

Which server should your browser choose? Why should it choose that server?

Learn that first, and then it might be clear what you need to configure.

> I think some other Java archives (.jar) not loaded by my browser.
> I don't know why.

Which other jars? How does your browser know to load them? Which urls
does your browser use for them?

Check logs for when things work.

> > 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.

I do not understand what network traffic you are describing.

That's ok - I don't need to understand it.

But you should understand it, and be able to draw a picture of what
talks to what.

> > 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.

In that case, nginx is not involved, no?

How does the browser know to talk to the remote server?

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

If you have enough information, it may be clear what is needed.

So long as it remains nginx-relevant, keep updating this thread.

Someone will probably be able to offer advice.

Cheers,

	f
-- 
Francis Daly        francis at daoine.org