Can a LabVIEW web-service respond to a root URL request, such as www.myip.com ?

[soren_jensen]

LV2010

I recently modified my internet webpage www.pendlernet.dk from being based on the LabVIEW internet toolkit to being based on LabVIEW web services. Now I am having the problem that I can not get my users in through the "front door".

I can not get the webservice to respond to the domain name itself, rather, it can only respond to requests such as  www.pendlernet.dk/pnet/ or similar. Trying to setup a system where the NI System web server displayed the top domain URL and the web-services displayed all the rest seems to fail when both of them have to share port 80.

A bit of history/background, bare with me its a long story (you dont need to read it to understand my problem) :

Pendlernet.dk has been in operation since 1996, its a web-based carpooling database. In 2000 I upgraded to LabVIEW+ G web server from Internet Toolkit thus leaving the orginal soluiton programmed in PERL behind. The last many years it has been operating in LV 7.1 (btw, the most stable release of LabVIEW ever!). Recently my windows 2000 server died and I could only purchase a new one with Windoze7. Win7 is not compatible with the Internet Toolkit LV7.1 and IE7 + IE8. I dont know why that is, but it relates to sequrity issues in IE7+IE8. However, IE6+ Win7 + LV7.1 worked just fine - but thats a rare combination.

Instead of batteling the Internet toolkit G-web server, which had/has many flaws I decieded to look into the LV WebServices. Over the years I had to create several hacks around the G-web server, to force it out of its natural state which seem to be a "freezing state-engine", so I needed to get out of this solution. Empty http-requests seemed to not work well in the G-web server and many other type of requests would stall the G-web-server. The workaround was to dig deep into the VIs and programatically kill request that would hang the server. Not very practical.

Porting the actual cgi-bin scripts was not that easy, until I came up with an easy solution. Web-services have all sorts of compile issues and my well-known well-proved code did simply not compile as a web-service. I came up with a simple solution to bypas this mess. By reducing the web-service itself to a simple handler of:

Http Request in <-> Http Respond out

Thus, GET and POST requests are send via shared variables to an application handling the logic of the server, and then the raw fromatted HTML resonse is sent back to the web-service via another shared variable. Therefore the web-service itself does not contain any code and needs not be build/redepolyed if codes changes are made. I will post an example of this later.

Any help is greatly appriciated

/søren

[InfiniteNothing]

I just came to post a similar question. I need a folder (like C:\www) with static files that I can edit easily and often on the same port as the webservice. This worked just fine on 8.6 but in 2010, the webservice and the normal page server don't seem to want to share a port.

[james brunner]

I just wanted to add my experiences to this thread.  We have a similar web application, and in fact it seems like we followed many of the same trials with the Internet Toolkit and G Web Server.

As of today, I have migrated our GWS/cgi based application to use web services and the LabVIEW 2009 built-in web server.  It was a fairly straightforward move, though I did run into difficulties bridging the gap between our "normal" application instance and that of the web server that holds the web service VI's.

Now I'm looking to move to LabVIEW 2010 and right away running into some problems.  While our web application has individual pages served depending on the web service called, it also uses a common pool of static web pages.  Typically these would install to the traditional "web root" folder and would be served from there.

LabVIEW 2010 has the "Application Web Server" set up as a service that starts with the system.  That seems to work fine.  It also hosts its own configuration page through the "System Web Server" on port 3580.  This too seems to work, but has very few configuration options available.

I have also spotted this article that discusses serving static pages from the Application Web Server:

http://digital.ni.com/public.nsf/allkb/2D926638796FB20E8625778F00572966

I believe I can drill down into the web server configuration (.conf) files and set things appropriately, but I think there should be more documentation available from NI describing the configuration options and how to support these in a deployed web application.

--

James