LabVIEW
Mini-Circuits LabVIEW HTTP client doesn't work but browser/CURL does
Solved!
Trying to implement LabVIEW drivers for this switch using HTTP communication. To get started I'm trying to implement a firmware version check, the example is "http://10.10.10.10/FIRMWARE?" and my device is at 192.168.1.60 so http://192.168.1.60/FIRMWARE? is my URL. When I go to this URL in Chrome I get back the expected version string.
I can also do "Invoke-WebRequest -Uri "http://192.168.1.60/FIRMWARE?" in PowerShell which returns "F6-2" in the content.
For the life of me I can't get the LabVIEW HTTP client to give me back this same string, I always get back "-99 unknown command MN:RC-2SP4T-A18 SN:<redacted>" in the body. I used the chrome dev tools to exactly replicate the headers used in its request but nothing changes this response.
Based on the fact I do get an intelligible response back from the switch, I don't think it's a security or encryption issue. Maybe encoding but I don't know what to try with that. Any ideas?
Been at this a long time, some more info that might mean something to someone who understands HTTP:
- The vendor provides example code for both LabVIEW and python
- Both examples append a ':' after the / so 'http://192.168.1.60/:FIRMWARE?'
- Only the python example works
- Omitting the ':' in the python example does not affect the result so I think it's a red herring
- The python example uses "urllib" module when I tried python myself I used "requests" and got the same (bad) response as my LabVIEW attempt
- The LabVIEW example doesn't work and has the same issue as the one I wrote from scratch because it's doing the same thing
- The NI advanced HTTP toolkit and JKI toolkit both have the same issue as the built-in library
The fact the LabVIEW example doesn't work means it may be something to ask the vendor about...
@avogadro5 wrote:
Been at this a long time, some more info that might mean something to someone who understands HTTP:
- The vendor provides example code for both LabVIEW and python
- Both examples append a ':' after the / so 'http://192.168.1.60/:FIRMWARE?'
- Only the python example works
- Omitting the ':' in the python example does not affect the result so I think it's a red herring
- The python example uses "urllib" module when I tried python myself I used "requests" and got the same (bad) response as my LabVIEW attempt
- The LabVIEW example doesn't work and has the same issue as the one I wrote from scratch because it's doing the same thing
- The NI advanced HTTP toolkit and JKI toolkit both have the same issue as the built-in library
The fact the LabVIEW example doesn't work means it may be something to ask the vendor about...
As with every question of the class "WTF is going on with my TCP/IP messages?", WireShark is the answer.
https://www.wireshark.org/download.html
Load wireshark up and you can see the actual messages going back and forth, makes it easy to see what each program is really doing : )
@Jay14159265 wrote:
Also I have never used the LabVIEW HTTP GET Vi. Maybe it's a wrapper on the lower level TCP VIs, which are awesome.
Nope. The NI HTTP library uses an ni version of libcurl. This is a C module that NI uses for their ni-curl shared library, wrapped by a ni-http shared library written in C or C++ to be used from the NI HTTP Client VIs. While it is not very difficult to write a basic HTTP library on top of the native TCP/IP nodes, the HTTP protocol with all it’s versions, flavors and vendorisms can get a real beast to tackle when you want to go beyond very basic HTTP commands.
@Jay14159265 wrote:
@rolfk wrote:
@Jay14159265 wrote:
Also I have never used the LabVIEW HTTP GET Vi. Maybe it's a wrapper on the lower level TCP VIs, which are awesome.
Nope. The NI HTTP library uses an ni version of libcurl. This is a C module that NI uses for their ni-curl shared library, wrapped by a ni-http shared library written in C or C++ to be used from the NI HTTP Client VIs. While it is not very difficult to write a basic HTTP library on top of the native TCP/IP nodes, the HTTP protocol with all it’s versions, flavors and vendorisms can get a real beast to tackle when you want to go beyond very basic HTTP commands.
Good to know, I think the original issue might be just this: "the HTTP protocol with all it’s versions, flavors and vendorisms"
@avogadro5 Did you try using the LabVIEW TCP Vis?
As @Jay14159265 wrote, I can't readily use the HTTP API using TCP VIs. The instrument doesn't provide a lower-level TCP API.
After playing "spot the difference" with Wireshark for a bit I found the important one: for some reason the LabVIEW client is stripping off the ? at the end of my request URL:
Adding an extra one made the instrument understand the request:
Playing around further showed apparently adding any character after the '?' fixes the issue. So I think I have a valid workaround.
Given my past experience with web APIs, I do now see why the '?' at the end is strange and might cause confusion at various points in the transaction. Based on the documentation/examples for this instrument I believe this used to work on a prior LabVIEW release with trailing '?' so I suspect some implementation changed in the underlying curl library, or maybe the OS is doing something different.
I guess the overall lesson is that tacking a SCPI API to a REST API can have unexpected behavior.
The ? starts a query parameter in the REST protocol (and variants of it). There a single ? makes no sense. Most likely the NI HTTP wrapper does some URL sanitation before passing the URL to libcurl. This is actually a good thing as it can prevent some potential problems and URLs with a question mark at the end are really strange.
Except of course if someone has the "brilliant" idea to try to marry SCPI and URL together, as you write. It's not really REST because for REST it is not really valid to have a single ? at the end.
This is related although for Python: https://github.com/psf/requests/issues/2912
