From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

HTTP and LabVIEW

Solved!
Go to solution

Hi All,

I had an HTTP VIs that use to work in LabVIEW.  Recently, permissions changed on the APIs on the server that I was connecting to. The permissions has now been fix. But still my code does not work.  I have used postman to send the same commands and they work fine.  See my attached picture.

 

It shows error 400.

 

thanks

Jose

 

Download All
0 Kudos
Message 1 of 16
(8,384 Views)

Can you provide a little more context into your application? A brief overview along with the following questions should be a good start.

 

Are you running this program as an executable?

Do you have any hardware interfacing with this application?

Can you post the full error message?

Do you have any firewalls that may be causing permission issues?

Can you provide an event log? It would help put some context on the error.

 

A 400 or 404 error is unlikely to be caused by the LabVIEW HTTP client and more probable on the windows or server side. This link has helped me in the past troubleshoot these kind of errors

Clint T.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 16
(8,337 Views)

I think your problem may be something like I had a while back.

 

If you are using an https address, I think you need to specify a path to create a client-side cookie file in order to persist the secure connection info received from the server. Use "Generate Temporary File Path VI" to create a random file name in an OS specific standard location.

 

The temporary file does not get deleted when you close the session, so keep track of the file and delete it in your own code.

 

LabVIEW HTTPS.jpg

 

 

 


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

Message 3 of 16
(8,318 Views)

Hi Clint,

Sorry I haven't replied sooner, but I was working on another project.

To answer some of your questions. See below.

Are you running this program as an executable? No

Do you have any hardware interfacing with this application? Nope

Can you post the full error message? - The full error message is on the .png file I attached on my first post. See the "body".

Do you have any firewalls that may be causing permission issues?  Not sure if firewalls are causing the issue. But would it also create an issue on postman?

Can you provide an event log? It would help put some context on the error. -- Not sure, I will check. My first response would be no.

0 Kudos
Message 4 of 16
(8,282 Views)

Hi Phillip,

I tried your suggestion in adding a cookie. It did not work.  Also, why would it work before without a cookie?

Please let me know if you have other suggestions.

Oh and yes, it is an https.

 

thanks,

Jose

0 Kudos
Message 5 of 16
(8,279 Views)

Hi Jose,

 

As discussed on this page, the issue is likely on the client side or as a result or data corruption on the network. Does the data look fine from the server side in LabVIEW?

0 Kudos
Message 6 of 16
(8,250 Views)

Sorry, just saw your reply.  Did your server change from http: to https:? 


I didn't point out that I also added the ConfigSSL.vi call. http://zone.ni.com/reference/en-XX/help/371361N-01/lvcomm/http_client_configssl/

 

 

If your server changed from http to https, there are session variables that need to be persisted for libcurl. These aren't (to my knowledge) contained in the LabVIEW client handle, but do seem to be persisted in the temp file associated with the client handle. I tried using the ConfigSSL function without a temp file and I could not log into my DUT (host). Only the combination of a temp file and ConfigSSL allowed me to communicate with the DUT.

 

In my use case, I'm testing a newly booted UUT on a private network with no certificate requirements for security, so I change the Verify Server from the default of TRUE to FALSE.

 

Try the temp file with ConfigSSL.vi and set Verify Server to FALSE and see if that works.


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

0 Kudos
Message 7 of 16
(8,229 Views)
Solution
Accepted by topic author Jose_LabVIEW

Your 'headers' you are sending are malformed.

 

The 'add header' VI adds a key/value pair to the HTTP header. You are building the key value pairs yourself instead of letting the VI do them for you. You should call the 'add header' VI for each key/value header pair you want to send.

 

 

To do the authorisation, you just need to put 'Authorization' into the 'header' control and then your 'Basic **password**' as the value. That will add a line "Authorization: Basic **password" to the headers. The HTTP Client VI handles the other headers automatically itself (e.g. the timestamp).

 

You should check what is actually being received by the server (e.g. by checking server logs / logging the request / using a 3rd party checking service etc.).


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 8 of 16
(8,218 Views)

FYI, your solution in separating headers to "Add Header vi" worked.

Now I am curious as to why it worked before and now I have to code it as you suggested?

 

thanks again!!

0 Kudos
Message 9 of 16
(8,201 Views)

Thanks for the reply Philip. Sam's solution worked.

0 Kudos
Message 10 of 16
(8,200 Views)