Jump to content

mjaspan

Members
  • Posts

    12
  • Joined

  • Last visited

  • Days Won

    1

mjaspan last won the day on August 20 2014

mjaspan had the most liked content!

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2010
  • Since
    1993

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

mjaspan's Achievements

Newbie

Newbie (1/14)

3

Reputation

1

Community Answers

  1. Solution found. Apparently starting in LV 2013, there is a default limit of 512 to the URL length. The default limit may be overridden as described below. Martin This is Brian in Applications Engineering from National Instruments. I am following up regarding the 511 character limit in your Web Service HTTP request following the port number. After some research I've figured out that the issue is related to a default web server setting called "LimitUri," which limits the maximum length of a URL. The default setting is 512 characters which is why we are seeing this issue. There are multiple ways of changing the URL length limit depending on how you are using your web service. If you are publishing the web service using the Application Web Server then modify "C:\Program Files (x86)\National Instruments\Shared\NI WebServer\NIWebAppServer.conf" and add "LimitUri 4096" to the end of the file without the quotes. If you are running the Debug Web Server by just clicking start on the web service then modify "C:\Program Files (x86)\National Instruments\LabVIEW 2013\resource\webserver\niwsdebugserver.conf" and add "LimitUri 4096" to the end of the file without the quotes.
  2. (* CROSS POST: http://forums.ni.com/t5/LabVIEW/Web-Service-URL-length-limits-LV2013-vs-LV2012/td-p/2957047 *) (* I've moved the discussion to the NI forums to increase visibility. *) (* Please do not reply here.*) Has anyone noticed a reduction to the limit on URL length for Web Services between LV versions 2012 and 2013? Under LV2012, a RESTful web service appears to accept URL with lengths at least as long as 4096 characters. With LV2013, the max URL length appears to be 511 characters for both RESTful and Project Item web services. Unfortunately for me the project I just converted trips over this issue. My goal with posting this query to here is to improve my understanding of this limitation before I decide how best to modify my code. Certainly using POST rather than GET with a long URL is an option, but again, I'm looking to understand the limitation change before I choose a solution. To illustrate I have attached three mostly identical projects which demonstrate the issue. In each case the project contains a webservice consisting of a single VI, "ComputeLength", which takes a String as an input parameter and which outputs the length of the string. The three projects are as follows. 1. LV2012 RESTful web service. 2. LV2013 RESTful web service. 3. LV2013 Project item web service. The web service contains a single VI. For the RESTful examples, the web service is started by selecting Deploy from the Build specification right click menu. For the Project Item example, the web service is started by selecting Start from the MyComputer/WebService right click menu. The use of this example is demonstrated with the following URL: (note that the port is 8080 for the two RESTful examples and is 8001 for the Project item web service if used in Debug mode, which is the default for the above instruction.) http://localhost:8080/webservice/computelength?string=1234567890 And the output looks like this. <Response> <Terminal> <Name>StringLength</Name> <Value>10</Value> </Terminal> </Response> To see the issue, extend the string parameter such that the URL contains more than 511 characters beyond the port number. For example something like this, http://localhost:8080/webservice/computelength?string=1234567890123456789012345678901234567890.... For the LV2012 example the string parameter may be at least as long as 4000 characters, which I've demonstrated using Chrome as my browser. For both of the LV2013 examples the URL is limited to 511 characters after the localhost and the port number. Anyone know whether this is a bug or this is an intentional design change? How about whether the URL length limit is configurable? I am also consulting NI tech support and will report back their response. Any advice appreciated. Thanks, Martin (* Please direct replies to the NI forum link at the top of this post *) EDIT: Cross post to NI mywebservice.LV2012.RESTful.zip mywebservice.LV2013.RESTful.zip mywebservice.LV2013.ProjectItem.zip
  3. Further info from NI, including some undocumented details. (Explanation, Solution, Workaround below) In my previous post I included a solution which is re-entrant. In this post I summarize the usage of the vi's included with the NI Internet Toolkit. Multiple instances of Get.vi will successfully execute simultaneously only if they have separate handles, previously created by OpenHandle.vi. The handles must be created in advance - ie a call to OpenHandle.vi is must wait when an instance of Get.vi is executing until Get.vi finishes. Apparently the non-reentrant behavior of Get.vi I reported in the top post is a result of this issue with OpenHandle.vi. A call to Get.vi without a handle wired in results in Get.vi creating a new handle internally (at least that's my interpretation - debugging this issue has been frustrated by password protection). Since new handles (apparently) may not be done while an instance of Get.vi is executing, one must pre-create a set of handles, or accept the serial performance of the non-reentrant behavior of Get.vi. Explicitly creating handles on the fly with OpenHandle.vi is problematic for the same reasons. At the end of the support ticket, I requested my NI tech support contact add these details to the documentation (either help files and/or kb), so hopefully others won't have to re-derive this subtle bug. Martin
  4. ShuanR: I'm curious where you found the HTTP_Get.vi you posted. Is it part of a Lavag library? Thanks. I noticed that some web servers (for example the LabView web service that's built by LV2010 Project Explorer) do not close the http connection and thus the version of HTTP_Get you posted is always left to hang until it times out. I modified HTTP_Get.vi (see attached) to look for the Content-Length: tag in the header, and if it's there use that information to determine when to close. If it's missing, then just read characters until the connection is closed, as in the orginal version. I also added a ParseURL.vi for my own sanity. So far this solution solves my need. thanks, Martin (attached files in LV2011) HTTP_Get_Modified.vi ParseURL.vi
  5. Awesome idea. It hadn't occurred to me how simple it might be to use the straightforward approach. I've been experimenting with your suggestion for a few days it appears to solve the primary issue by being non-blocking. I'm building on the vi you posted to try to improve it slightly. At present, it doesn't seem to know when to stop waiting for characters so each GET takes the full timeout time of 15 seconds. At least that's true for some web sites. For others it terminates quickly which I assume has to do with the server closing the connection. I noticed many web sites provide a ContentLength tag in the header so for those I can terminate once I see that many characters. I'm not sure what the procedure is supposed to be when the ContentLength tag is missing. I'll figure out the standard protocol for terminating a GET, add it to the vi, then post it here. Thanks! Martin
  6. update. after further testing, it appears that the vi Get.vi is configured to be reentrant, but does not behave as if it's reentrant. I've confirmed this for LV2010sp1 and LV2011. I'm starting to be concerned that something inside of it is not reentrant. I've spoken with NI tech support and am awaiting their response. Again, any suggestions from the peanut gallery gratefully welcomed. Martin
  7. Is it my imagination or is the vi, vi.lib\httpclient\Get.vi, which ships with LV2010SP1 not reentrant? Followup question, I don't suppose there's any way to make a password-protected vi reentrant? sigh. == Until recently, (see previous topic, Datasocket and 404 error), I was using DataSocket.vi for my http requests. This worked fine with two exceptions. 1) It fails to return the actual http text response when the http header contains an error status (ie 404 or 505 errors). 2) it appears to work 99.5% of the time, with ~0.5% of the time it times out for no apparent reason. My solution was to switch to using the Get.vi under vi.lib\httpclient\ which ships with LV2010SP1. It works much more reliably and solves the aforementioned two issues ... however ... I recently discovered a subtle bug in my code which I've chased down to an issue with Get.vi. It appears to be blocking other instances of itself - ie it's not reentrant. Since my code relies on parallel loops making simultaneous http requests this creates a new issue for which I'm looking for a solution. The most straight forward thing would seem to try to make Get.vi be reentrant, however it appears that the reentrant checkbox is not accessible (nor any of the VI properties) due to this vi being password protected. I assume if I purchase the Internet Toolkit, the Get.vi is the same vi, and is probably also still password protected, eh? anyone with suggestions or thoughts? thanks, Martin
  8. Thanks Shaun. If installing LV2011 solves my issue, then I may as well stop procrastinating (ie the disks are just sitting here waiting). Interestingly, once you mentioned the LV2011 http vis, I discovered that those same vis appear to have shipped when LV2010SP1 came out, and that I have them already... I gave the GET HTTP.vi a try and voila, success! Problem solved. Thanks!
  9. Anyone know if it's possible to force DataSocket Read.vi to return the raw text of an HTTP response, even if there was an error code (for example 404 error or 500 error)? For example if you set your browser to "http://www.google.com/blah", the google server responds with a customized 404 error web page, which the browser correctly displays. DataSocket Read.vi does not return the raw text of the customized 404 error page. More background: I am using DataSocket Read.vi to make HTTP requests of various URLs. For example, "http://localhost/mywebservice" or "http://www.google.com" as the "connection in" input. Works great for retrieving the raw text of the web page. My specific use is to call local web services on several computers on our local LAN - web services which perform various hardware control actions on equipment in the lab and then return a simple response in XML or plain text. Sometimes I need to append "[text]" to the url if the data is formatted as XML or other formats in order for DataSocket Read.vi to return the response. Again, works great for my needs. However, if the web server returns an error code, for example 404 error or 500 error, then DataSocket Read.vi returns an error and does not return the plain text of the response. The issue is that one of the web services we use returns a 500 error in addition to describing the error condition in the XML response - and DataSocket Read.vi returns with "Error 1184 // Path not found, FTP login incorrect, or no FTP write permission" rather than returning the raw text of the XML response with the error description. Calling the URL from a browser correctly displays the raw text of the XML response, so I know it's a DataSocket or Labview issue. I am not using the Internet Toolkit. Since DataSocket Read.vi met my needs (with this one exception) I had no use to purchase the Internet Toolkit. Seems silly to purchase the entire Toolkit for this one feature. I suspect that the Toolkit would do the right thing, though I have not tried, preferring to use built-in functions. If the answer is that the Toolkit is the best/only way to do what I want, that answer if valuable to me as well, even if disappointing. I'm using LV2010SP1 on Win7, and have LV2011 disks on my desk waiting to be installed. Any thoughts or suggestions appreciated. thanks, Martin
  10. Problem Solved. Paul, you were right, the solution resulted from calling NI. Luckily my company has the support subscription. The tech support guy I reached at NI talked me through it. The solution was two fold. (I'd tried both solutions on my own, but not at the same time) First, it's important for all of the VIs to be within the same application instance for the Single-Process variables to work AND it does not seem to be possible to prevent the Web Services VIs from existing inside their own application instance.... Thus Network-Published shared variables are required. Second, in Build Specification, I needed the "Deploy shared variables at application execution" check box. Apparently things work intermittently (rather than not at all) when I neglected properly deploy the shared variables. I've built a small example Installer which deploys the VIs and the Webservices VIs and the Network Shared variables all work. I'm now incorporating the changes into my real system. Thanks for the response. Hopefully if someone else stumbles on this issue, they will also stumble on this discussion. Martin
  11. Paul, thanks for the feedback. Single process shared variables can be used to communicate between VIs as well as within a VI. Referring to Using the LabVIEW Shared Variable, the key is that the multiple VIs be in the same application instance. This is the feature I'm trying to use. To be more concise about the challenge I'm trying to solve, I'm trying to compile and build a project which includes both regular VIs and Webservice VIs *in the same application instance*. It works fine to compile compile and build multiple regular VIs in same application instance OR multiple Webservice VIs, but not both. Apparently the instructions at LabVIEW Web Services FAQ, only partially accomplish building them all in one application instance as evidenced by the separate-instances of the single process variables. Probably what it accomplishes is an application instance within an application instance. I'm still working on it. I'm poking around with network shared variables now. If that fails I'll see if the folks at NI have an idea about how to compile and build a project which includes both regular VIs and Webservice VIs in the same application instance. thanks, Martin
  12. I'm deploying a built application with LabView 2009 and having trouble with Shared Variables. I have a suspicion what's going wrong but am puzzling over how to proceed. I'll describe it in more detail below in the hopes a generous programmer will throw me some pointers. (pun? what pun?) The application consists of several VIs (front panels on the screen) built as an application (EXE) and Web services VIs (RESTful) together in one Build with Shared Variables. The trouble is that it appears as if there are two instances of each Shared Variable; one from the application VIs in the EXE and one from the Web services VIs. The values in the Shared Variables are communicated correctly between the application VIs and also between the Web Services VIs, but not between the application Vis to/from the Web Services VIs. -- more detail: I have 3 VIs which control various instruments. These VIs have front panels intended for human users to interact with. These VIs are all in the same Project where several Shared Variables are declared. The VIs share data using these Shared Variables. The Project also includes a handful of Web Services VIs which respond to HTTP requests. These VIs are built with the RESTful specification. These VIs also use the same Shared Variables to communicate. Building all of this into one application took some doing. I finally figured it out by using the following instructions to glue it all together and create an installer. http://zone.ni.com/d...p/id/7747#toc12 In summary, the directions say to create a Web Services (RESTful) Build Specification with the Web Services VIs, then Build it. And then include the Built web services (niwebserver.conf) into an Application (EXE) Build Specification with the application VIs. After using the correct magic runes (as described in that link) It all gets bundled into a neat package complete with installer. Simply delightful. The trouble is that the Shared Variables behave as if there are two instances of each variable - one for the application VIs and one for the Web Services VIs. I can see how this is a likely outcome of this two-step build procedure, however I am unsure how else to create a Build Specification which includes both kinds of VIs (Application and RESTful). -- Example story: ApplicationA.vi: set Variable X = 5 ApplicationB.vi: read Variable X result: 5 WebServiceA.vi: read Variable X result: 0 WebServiceA.vi: set Variable X = 10 WebServiceB.vi: read Variable X result: 10 Application B.vi: read Variable X result:5 -- Anyone out there worked on something similar? Looking for suggestions for convincing the Shared Variables to behave as I desire. (ie one instance for each). I am using Single Process shared variables. I suspect that a possible solution will involve using Network-Published shared variables, though I'm not clear if that's the best way to go given that this all resides on one machine and one application. I am in the process of investigating the Network-Published shared variables to determine if they will work here. Alternatively I have built VIs which communicate using VI server and pulling/pushing values directly from/to the Front Panels, but that feels like having to start my car by manually turning the crank at the front bumper.... If it helps I can produce a stripped down version of my Project which illustrates the issue. Thanks for any advice, Martin
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.