cgi executable

[bww]

I'm a little confused about how to make an executable VI that uses CGI components. Basically I'm using an html "POST" method and have a CGI enabled vi processing the request. This works great on my development machine, but I'd like to move it to another machine and run the process with the run-time engine. I have succesfully deployed an executable version of the G Server but I can't get the CGI part to work. I think I might just mis-understand how or where the cgi vi needs to be located.

On the development machine, I can just locate the cgi vi in the cgi-bin and have the server running and everything works fine. This doesn't seem to be the case with the executable version. I'm using the following html snippets to make this call

<form action=http://server/cgi-bin/cgi_test.exe method="post"> - I get the contenct of the exe or a screen of gibberish.

<form action="http://server/cgi-bin/cgi_test.vi" method="post"> - I get the following error "HTTP 500 - Internal server error"

In both instances, I can see the request on the G Server's log. Any thoughts or ideas would be greatly appreciated.

Regards,

Bryan

[Travis_M.]

Hello,

Thanks for posting!  I believe this question might be related to this KB.  I believe that there might need to be some additional resource files that need to be included with your build or runtime engine.  If this does not fix the problem please post and let us know -- there may be a couple of other things to try.

Hope this helps!

[bww]

Travis,

Thanks for your reply.  The two files: lvpng.dll, lvjpeg.dll are both located in the run-time engine folder, but I'm not trying to view the front panel remotely so this isn't really the problem. Basically what I'm doing is using the G Web Server to host a web page and I've written a CGI vi that updates an image of the front panel, so that the web page can be somewhat dynamic....I know that the remote panels can do all this but....1) I don't want our clients to be required to download the runtime engine and 2) if they are behind a corporate firewall the remote panels won't be allowed because they don't follow standard http protocol anyway. I've been down the remote panel road with an NI engineer already, which is why I'm trying to do things with CGI...but this is really getting off subject.

I have the G Web Server running which is built from an exe and I can see clients request come in and web pages being served, however what I can't get working is making an executable CGI vi process "POST" requests. This works fine on my development machine, so I'm assuming that it is possible to build this as an exe. The way that I see this working is to have the G Web Server running, then when a client requests info via a "POST", the CGI exe processes the request and updates the image and returns the updated web page. I believe that my problem lies in how I've built the CGI vi or where I stored it on the server. 

I've modified the "srm.cfg" file and my DocumentRoot seems to be working correctly but I'm not sure where my cgi-bin should go...I've assumed that is should go under htdocs as show in the following:

<application directory>\internet\htdocs\cgi-bin

atleast this is how I understand the section of the "srm.cfg" file that reads:

ScriptAlias /cgi-bin/ cgi-bin/

Anyway, maybe I mis-understand this directive....maybe you could comment on this

Alternatively, when I call the CGI exe from the "POST" I get a screen full of giberish. This leads me to believe that my CGI exe is not accept/processing the request an the G Server is streaming the content of the file...thus the streaming binary. Anyway...I think the answer lies somewhere in the NI document:

 "How to Build the G Web Server Using CGI Into an Executable"  near item 10 but I haven't sorted it out yet. Any advice would be greatly appreciated.

Regards,

Bryan

[Travis_M.]

Hello Bryan,

A couple things to check.  Basically when in your development environment file paths are relative to the LabVIEW.exe file.  When you build this into an executable the file paths are relative to the Application.exe.  In your case, you will want to make sure your file structure in your exe is the same as LabVIEW. 

You mention the file path: "\internet\htdocs\cgi-bin", but I notice in my folder that I have the path "<application dir>\www\cgi-bin".  Double check and see if the directory should be in the www folder -- if you are still using the www directory as the default directory, is this directory still available with your executable?

I also found an internal document (over 6 years old) of someone encountering a similar problem the solution (or at least a semi-readable version of it) is:

"1. when you run your executable it will create a couple of folders. To be exact it will create internet/http/conf Under LabVIEW, you should have an equivalent folder labview/internet/http/conf.  Please make a copy of all these files and move them to the new location.
2. In that folder there is a file called: SRM.cfg at the end of the file you can find the following lines: -------------- # If you want to use CGIs outside ScriptAliased directories, # uncomment the following line. #AddType application/x-lvhttp-cgi vi ----------------.  Please remove the comment on the last line. this will let you execute your VI.  It should look like this: AddType application/x-lvhttp-cgi vi
3. verify that you have set the proper directory.  At the beggining of this file you have a section that say: # DocumentRoot: The directory out of which you will serve your # documents.  By default, all requests are taken from this directory, but # symbolic links and aliases may be used to point to other locations.  DocumentRoot /D/temp/customers/internet executable/internet <-- Put here the folder where your file is located. You MUST use /, not \ please let me know if you need any extra help."

Maybe this snippet can offer a little more information on the issue?

-please let me know if any of this was useful-

[bww]

Travis,

I've verified that my DocumentRoot directive works...everything in or under the <app dir>/internet/http/htdocs is accesible via remote client, this include the cgi-bin. I believe that even the call to the cgi works from the web page because I see the request in the G Web Server's Log file,as show below:

11/23/2005 4:33:20 PM: Setting DocumentRoot to "/C/DM_dbase/internet/http/htdocs" (C:\DM_dbase\internet\http\htdocs)
11/23/2005 4:33:20 PM: Setting DocumentRoot to "/C/DM_dbase/internet/http/htdocs" (C:\DM_dbase\internet\http\htdocs)
11/23/2005 4:33:32 PM: GRAPH - "GET / HTTP/1.1"
11/23/2005 4:33:32 PM: GRAPH - "GET /gweb.gif HTTP/1.1"
11/23/2005 4:34:03 PM: GRAPH - "POST /cgi-bin/wbm_dbase_query_3.vi HTTP/1.1"

I think the only problem I'm having now is correctly building my CGI vi because when I try and "POST" to the vi I get the following error:

Error 500: Internal Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator and inform them of the time the error occurred, and anything you might have done that may have caused the error.

CGI request "POST /cgi-bin/wbm_dbase_query_3.vi HTTP/1.1" could not be fulfilled.

The error must be in how I'm adding Dynamic and supporting vi's in the build process....I guess I keep fiddling with the "How to Build a G Web Server...." ideas unless anyone can see my errors.

Regards,

Bryan

[bww]

I've successfully built a CGI vi and G Web Server that are running smoothly on a remote machine. The problems were as I suspected, in how I was adding my dynamic vi's and support files. Basically I followed the "How to Build the G Web Server...." (link posted above) and replaced the "listdir.vi" with my vi and everything started working. I think the real crux to the problem is getting the "srm.cfg" files configured to match your remote system but there is decent documentation inside the files to achieve this...thanks for your ideas.

Regards,

Bryan

[Travis_M.]

Hello,

Glad to hear you found the solution.  I hadn't forgotten about this issue, by the way, I had just been away from my desk for a couple of days so I hadn't had a chance to talk with the developers about it.  Thanks for posting the solution -- this forum might help out others who encounter similar problems.

thanks again!