LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

HTTP PUT error 417

Solved!
Go to solution

Problem: I can "PUT" a JSON string to an instrument (on a local network) hosting a remote web service using an Internet Explorer 11 web browser (using application/json) and everything works as expected but when I send the same JSON string using the LabVIEW HTTP PUT vi it doesn't work correctly and returns in the header -> HTTP/1.1 417 Expectation Failed, Content-Type: text/html.

 

All of my GETs work when using the HTTP GET vi and all have the return Header Content-Type: application/json (with the body in JSON).

 

I did try to add to the PUT Header "Content-Type: application/json" (using the AddHeader.vi) but did not correct the error.

 

Looks like there may be an issue with the header or some other unwanted information being inserted into the message to the instrument web service api when using the LabVIEW (2016) HTTP VIs.

 

Has anyone observed this behavior or can offer some ideas on possible fixes or workarounds? Thanks

0 Kudos
Message 1 of 6
(5,486 Views)

Using the following example where Add Header is used with the header "Content-Type" and value "application/json" I used the service httpbin.org/put which echoes the response back.

 

The block diagram is as follows:

AddContentTypeHeader.png

 

And the result was the following:

AddContentTypeHeaderResult.PNG

 

From the result you can exactly what headers were received. Is this the same approach you used to add a header?


Milan
0 Kudos
Message 2 of 6
(5,468 Views)

MilanR,

 

Yes, that was the approach I used to add the "Content-Type" and value "application/json". I have also added the other header entries that I see when using a web browser to my program. No change with the reply from the Web Host api.

0 Kudos
Message 3 of 6
(5,409 Views)
Solution
Accepted by topic author ETTC-SWE

Doing a search for the 417 Expectation Failed error I landed on this article on the MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/417

 

Which links to this article on the Expect header: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect

 

In that article it states that a client could have the header `Expect: 100-continue`. And if you look at the body in the screenshot above you can see that the `headers` property of the JSON object does contain the key-value pair: "Expect": "100-continue"

 

The article also states "No common browsers send the Expect header, but some other clients such as cURL do so by default.". As the HTTP Client Palette for LabVIEW 2016 is based on curl that seems to explain why the header is present in the LabVIEW requests and not from the browser request.

 

There is a Knowledgebase article titled Why Am I Getting Error 417: Expectation Failed When Using HTTP Methods? that includes a workaround.

 

Out of interest I also tried adding a header with the same name and with a value as an empty string and at least for the server I was sending messages to it seems to reject the Expect header (you no longer see it in the body showing request headers).

 

ExpectWorkaroundBad.png

 

ExpectWorkaroundBadFrontPanel.PNG

 

I would probably recommend using the workaround approach from the KnowledgeBase article over attempting to manipulate the HTTP Client to behave differently than expected.


Milan
Message 4 of 6
(5,404 Views)

Milan,

 

I reviewed your previous reply and added the Expect: <empty string> to the PUT header as shown in your snippet and this fixed the problem! 

 

Note: When creating the Combo Box Constant to the 'Header' input of the AddHeader.vi you will see that the 'Expect' entry is not present and will need to be added using Edit items...

 

Using this technique overwrites the existing and unwanted Expect: 100-continue with Expect: <empty string> causing the Web Server to reject the Expect header entry and not return the 417 Expectation Failed error. The PUT request is processed correctly now.

 

Thanks for researching and posting the links concerning my issue and the HTTP Client Palette for LabVIEW 2016 being based on cURL.

 

Ron

 

 

 

 

Message 5 of 6
(5,387 Views)

I just ran into something similar in LV 2022 but with the endpoint responding with 408. I am having to generate my own HTTP request with direct TCP writes which is silly because the built-in LV PUT method does not work correctly, nor does the Advanced HTTP library that Darren published to VIPM.

 

Interestingly, Wireshark is also not identifying the payload as a HTTP payload which makes me suspect something is malformed in it. If I do my manual write with TCP, wireshark sees the request as a proper HTTP payload.

 

Now that I've looked a bit more, it appears as if the PUT isn't ever actually sending the payload portion? Looks like the endpoint times out after ~500mS of the header portion of the request being transmitted.

~ The wizard formerly known as DerrickB ~
Gradatim Ferociter
0 Kudos
Message 6 of 6
(419 Views)