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 _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
