LabView web servers via the reverse proxy does not work

[wo]

We have made two LabView applications with web server support. These two applications are launched on two independent computers, so they can be accessed from the Internet from two different URLs (for example www.lab_1.com and www.lab_2.com ). We want to make access for these laboratories from one ULR but from different paths on this URL (in our example – the first application could be accessed from www.lab.com/lab_1/ and the second application from www.lab.com/lab_2/ . So we will obtain the one URL for two independent LabView webservers. We consider that this can be done with the Reverse Proxy technique.

We have launched the Reverse Proxy on Apache software. Both webpages from both applications can be viewed correctly but the Remote Panels can not be displayed. The “Server does not support Remote Panels” text is displayed.

What is the reason? Can You tell us how we must to configure our reverse proxy if we want to work it with LabView Web servers correctly? 
Sincerely

wo

[Kevin_H]

Hey Wo,

Thank you for contacting National Instruments.  I have taken a look at your issue, and there does not appear to be any documentation on how to achieve this.  I did find some KnowledgeBase articles that may shed some light on this issue.

In this KB, it says the following:

"If a third-party server is needed for supporting the rest of your website, you must redirect users to access the remote front panels on the computer running the LabVIEW web server."

This seems to imply that you must issue a URL redirect in order to get the Remote Front Panel to appear.

This KB is directly related to the error message you are receiving. It says:

"The server hosting the remote panel is not a LabVIEW Web Server. You cannot use third-party servers to manage remote front panels."

I do realize that these KB's are a couple years old, so I will do some research and try and find out if anything has changed.

Regards,

Kevin H

[wo]

Thank You for replying.

I know this KB but in my opinion it does not cover my issue. It says that we can not move

webpages generated by LabView (containing remote panels) into third-party webserver. This

is true because the LabView webserver not only acts as typical webserver hosting webpages

but also it makes connection between remote panels and LabView application.

In my example, webpages generated by LabView that contains remote panels are still hosted

by LabView webservers located on (in this example) www.lab_1.com and www.lab_2.com.

Reverse proxy connects both physical webservers into one URL. In this case the

reverse proxy application is used only as transmiter of traffic between client and

LabView webservers.

Regards
Wo, W.U.T.

[Kevin_H]

Hey Wo,

There do seem to be some issues in general trying to accomplish what you are doing.  Can I ask why you can not simply issue a html redirect to www.lab1.com when a user navigates to www.lab.com/lab1 ?  If I understood your last post correctly, I believe that is what you are essentially doing with the reverse proxy.

We have no documentation on using a reverse proxy with the LabVIEW web server, but I will see if I can locate anything that will be useful for you.

Have a great weekend.

Regards,

Kevin H

[wo]

> Can I ask why you can not simply issue a html redirect to www.lab1.com when a user navigates to www.lab.com/lab1 ?  If I understood your last post correctly, I believe that is what you are essentially doing with the reverse proxy.

This is because of two reasons.

1. All laboratory computers must be visible from the Internet on only one URL.

2. Both laboratory computers are in our Intranet (but different subnets) and they are not directly visible from the Internet. So access to these laboratory computers with LabView webservers could by controlled by the main computer with reverse proxy.

Sincerely

Wo

[Kevin_H]

Hey wo,

The reverse proxy scenario doesn't work because Remote Front Panels use HTTP as well as an additional, proprietary information passing protocol.  The reverse proxy is properly returning the HTTP requests from the LV servers, however, the Front Panel communication is not HTTP, and as such, can not be proxied using a simple HTTP proxy.  There could possibly be a way to make this work, but it would not be a supported issue, and as I have said earlier, we have no known documentation on how to acheive this.

If you do develop a method to accomplish this, please do post a how-to here.

Regards,

Kevin H

[wo]

You are right

I will try to use the NAT address translation with the new configuration of the network scheme.

Thanks

wo