Current Challenges with the native LabVIEW HTTP Client
The following are a list of challenges with the native LabVIEW HTTP Client
- Can't create new handles when a GET operation is is progress -- this creates locking and unnecessary synchronous behaviors (and potentially a deadlock)
- No Way to Abort a GET in Progress -- you have to wait for it to complete and closing the http handle doesn't even work.
- No Way to Monitor GET in Progress
Can't create new Handles when a GET operation is in progress, which limits the ability to do parallel operations, and eve has the potential to create deadlock situations.
The solution to this problem is to pre-allocate a "pool" of handles before doing the HTTP GET operation. An example is shown below:
There's no way to abort a GET that's in progress (however, doing a VI:Abort on the top-level VI in the call chain of the GET operation works to abort it). This means that one could spawn an asynchronous actor (that's running top-level) to do the GET operation and then call a VI:Abort on the actor to abort the GET opereration.
There's do direct way to monitor the progress of a GET operation However, there's a hack in that one can specify an output file, instead of simply returning the string data of the body, and then monitor the output file size on disk. The current file size could be compared with the expected file size, which would be obtained by calling the HEAD operation (to get the header information which contains the file size, but not actually get the file contents) before the GET (which then gets the file contents).
The following are a set of common use cases that are not directly implemented in the native LabVIEW HTTP Client:
- Asynchronous GET
- Follow Redirects Automatically
Need ability to start a GET operation asynchronously and:
- monitor progress and
- abort the operation if needed
The developer must manually parse the response headers to see if a 3xx code was returned, then parse the redirect URL in the headers, and then try the operation again with the new URL.