CGI's are not processing LabVIEW InternetToolkit 8.2.1

[pbailey]

When I upgraded to 8.2.1 CGI vi's stopped working, is this a known problem or have I mis-configured the system?

 I have upgraded from 8.2 to 8.2.1, re-installed Internet Toolkit 6.0 ( from May 2007 distribution ) and applied ITK 6.0f1 Patch.vi.

No other LV installation on my mnachine is configured to use the Toolkit or run a Web Server. Did mass compile on InternetTK and my CCI.vi

WebSite & GWebServer share port 81

Document root is: .../LabVIEW 8.2.1/www

Internet config files are located at:

.../LabVIEW 8.2.1/internet/http/conf

srm.cfg contains the following line: ScriptAlias /cgi-bin/ cgi-bin/

The VI's are being found, but create a temporary copy and open front panel and do not run.

 I get the same behavior when I use CGI Template.vit. or CGI/examples.

Any help would be welcome.

Phil Bailey

[Caseyw]

Hi Phil,

As far as I can tell, this is not a common problem encountered when upgrading to LabVIEW 8.2.1. Are you able to see the CGI VIs within your Internet Toolkit palette? I would like to narrow the problem down to see if this appears to be an installation issue, or something going on with the web server aspect. What exactly do you mean when you say that your CGI VIs stopped working?

I am sure that we can work together to resolve this issue and get your application up and running. I look forward to your response Phil; have a great day!

Regards,

Casey Weltzin
Applications Engineer
National Instruments

[pbailey]

Casey,

Thanks for responding.

My application needs to embed RemotePanels in .Net generated ASPX pages. In past versions of LabVIEW I used a CGI_VI to generate the content of an IFRAME.

In previous versions of LabVIEW (7.0 through 8.2) I configured the GWebServer and the LabVIEW WebServer to share one port, usually 81. Document root was set to ../National Instruments/LabVIEW x.x/www, CGI directory was www/cgi-bin. I used a CGI_VI to generate an IFRAME's content that did the actual publishing of a RemotePanel. The remote panel was served by the LabVIEW WebServer.

GWebServer configuration files are in LabVIEW x.x/internet/http/conf.

When I run this configuration with 8.2.1 the CGI vi's are loaded into the temp directory and do not process the input, but pop-up a frontPanel on the host machine. This also happens with any supplied example CGI_VI's.

If I disable the LabVIEW WebServer the CGI_VI's do function, but unless I open another port for the LabVIEW WebServer I can not serve the RemotePanels.

I have changed the ASPX page generation code to directly output the OBJECT block that defines the RemotePanel control, and disabled the GWebServer. Several years ago I had been informed that the control could only be placed in LabVIEW served pages, but this no longer seems to be the case. New documentation includes parameters for server, and how to specify the server in the EMBED block.

I suspect the shared port problem is in how the servers detect what is the CGI directories, but have been unable to resolve what has changed.

Thanks for your help, I would still like to understand how to get the shared port mode with CGI's working again.

Phil Bailey

[Caseyw]

Hi Phil,

Based on your previous post, I will attempt to reproduce this issue on my end using a shipping CGI example. After this point, I can ask our R&D team what might have changed between LabVIEW versions, and if there is any workaround other than placing the two web servers on different ports.

Regards,

Casey Weltzin
Applications Engineer
National Instruments

[Caseyw]

Hi Phil,

After experimenting a bit with the G Web Server and LabVIEW Web Server, I have been able to reproduce the issue that you are seeing. I will check with our R&D team to find out if it is possible to use both servers on port 80 at the same time. In the meantime, I will look for alternate solutions to your problem. Is there a reason that you aren't able to use two ports for your application?

Regards,

Casey Weltzin
Applications Engineer
National Instruments

[pbailey]

Casey,

Thanks for checking this out. I have found a work around, I'm now directly generating the OBJECT blocks in my ASPX pages.

My issue is more that it does not work as in earlier versions ( I prefer the current solution ).

My issue with ports is that I am already using port 80 for the .Net WebServer, adding one port is not as much a problem as getting multiple ports through a firewall. Some of thetargeted sites for the application are in locals where getting any ports open is an administrative hassle.

Phil Bailey

[Caseyw]

Hi Phil,

Have you tried navigating to Tools >> Internet Toolkit >> G Web Server Configuration? There you can select the Share LabVIEW Server Port option to instruct the G Web Server only to handle CGI requests.

I hope this helps; please let me know if your CGI server still doesn't work properly with the LabVIEW web server enabled and I would be glad to help troubleshoot this issue further. I hope you have a great day Phil!

Regards,

Casey Weltzin
Applications Engineer
National Instruments

[pbailey]

Casey,

I have tried, 'use shared port' that is the mode I used prior to 8.2.1. Unless there is an additional argument to only use GWebServer for CGI, the share port mode in the past always had that behavior.

Phil Bailey

[Caseyw]

Thank you for your prompt response Phil. So, even with the option selected you are still not able to run the simple example VIs that ship with the Internet Toolkit? Which specific example are you attempting to run? If this is the case, I will try to reproduce the behavior on my end and report it to our R&D team if I find that it doesn't work. Since the option exists to share the web server port, I don't see any reason why you shouldn't be able to do so.

Regards,

Casey Weltzin
Applications Engineer

National Instruments

[pbailey]

Casey,

I thought in your reply of 06-25-2007 you had replicated the problem. I did check the Internet toolkit configuration and the interface has not changed in 8.2.1, still an option to share with GWeb only handling CGI or not shared. The examples I used are the ones suppliedd as part of the install of Internet Tookkit.

Phil Bailey