HTTP PUT error 417

[ETTC-SWE]

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

[MilanR]

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:

And the result was the following:

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

[ETTC-SWE]

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.

[MilanR · Accepted solution]

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).

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

[ETTC-SWE]

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

[IlluminatedG]

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.