addheader.vi

[aartjan]

I have an issue with the LabviewHTTPclient.lvlib:addheader.vi. It succesfully adds a header, but it doesn't clear the header value when presented an empty string (as described in the help file). I use it for interfacing with a RESTful webservice which requires custom headers. Now I have to close and reopen the "connection" to get rid of the old header value. Furthermore, I cannot overwrite the header: it will postfix new values to the old value.

[Corné_Westeneng_NINL]

Hello,

Could you send met the whole project?

Kind regards,

Corné Westeneng

Applications Engineer

NI-Netherlands

[aartjan]

Sorry Corne, I will not upload the code. Furthermore, you need a webservice or HTTP server to communicate with. I believe it is a bug in addheader.vi that should be resolved in the next releaase of Labview.

[Corné_Westeneng_NINL]

Hi,

Thanks for your response. 

Is it possible for you to post the steps to reproduce the incorrect behaviour?

When I have this information I can make a CAR(corrective action request). We use CAR's to update our software.

Thanks inadvance.

Best regards,

Corné Westeneng

Applications Engineer

NI-Netherlands

[aartjan]

Not really. I am making a user interface for the Mintouch deki webservice. It is a RESTful webservice that requires special http headers. In the image you can see you must set a header named ETag when updating a certain webservice property value. In the disabled box you see I have tried to empty the value by writing an empty string to it, which didn't work. I end up having to reset the connection to get rid of the existing ETag header value. If I don't create a new connection, the addheader.vi will just keep on concatenating old ETag values.

It has nothing much to do with my particular webservice or HTTP header name; You can try it on any http server.

[Corné_Westeneng_NINL · Accepted solution]

Hi,

According to your information I found a CAR (corrective action request) for your problem.

So, our R&D is aware about this incorrect behaviour.

A possible workaround is: Create and destroy a client handle for each request.

Do you have enough information now?

Best regards,

Corné Westeneng

Application Engineer

NI-Netherlands

[aartjan]

Great. That's all I wanted. The new release is pending, too.