Web Request POST with no return content causes "Error executing external web request: java.lang.IllegalArgumentException: Response does not contain data"

#1

1) Give a description of the problem
I have a WebCoRE Piston that makes a web request using POST and passes some JSON to the web server. The web server processes the POST request correctly and does what I expect. However, because the server returns no reponse content, it seems that WebCoRE treats this as an exception (“Error executing external web request: java.lang.IllegalArgumentException: Response does not contain data”). When I make the same call using postman eveything works, but the status shows “204 No Content”. I have no control over the API on the server as it’s a 3rd party. Is there anyway to supress this exception? Isn’t it a legitimate scenario that an http POST is made without expecting any data to be returned? Please note that the server also insists the web call is made using POST, so I can’t (for example) use a PUT or anything instead.

2) What is the expected behaviour?
I expect the web request to execute, the web server to not return any data and for WebCoRE to handle the lack of response content without throwing an exception.

3) What is happening/not happening?
WebCoRE thows exception “Error executing external web request: java.lang.IllegalArgumentException: Response does not contain data”

4) Post a Green Snapshot of the piston!

image
image.png828×241 5.91 KB

5) Attach logs after turning logging level to Full

image
image.png1137×700 70.7 KB

webCoRE Optional Update v0.3.111.20210130
#2

I sometimes use this method to catch errors:

Define string {response} = (no value set)
Define boolean {error} = (no value set)

Web request
Set variable {response} = $response
Set variable {error} = (contains(response,'StringIndexOutOfBounds') ? 'true' : 'false')

IF {error} is false
    Then do cool stuff
    Else Notify me
END IF

Line 5 may need to be tweaked for your error, but this is the code that catches my occasional errors.

#3

Thanks for reporting, I’ll check whether this is something we can fix. Confirmed the error described above with piston bo083

#4

There is a simple improvement to be made here. The exception is thrown when attempting to get the content type of the response, but the response status can be retrieved safely. Unfortunately webCoRE is retrieving the $httpContentType value before the $httpStatusCode, so the exception kills the normal response variables.

The response code from the server when there is no body should be 204. It is reasonable to make webCoRE not throw that exception if the server returns a 204 status code. If it’s a regular 200 status code then Java will still throw the exception, but simply reordering the code at least allows the piston to get back a correct value for $httpStatusOk and $httpStatusCode even if the exception is thrown.

#5

There does not seem to be a fix for local web requests; if a local server returns a 204 the hub does not provide any event back to the smart app so it is indistinguishable from a timeout. Many have reported timeouts for local requests; seems like a 204 empty response could be an additional cause.

#6

Thanks for confirming this is a bug in webCoRE. Yes checking the status code, before the body seems like a sensible change to the webCoRE code, as currently the httpStatusCode variable doesn’t get set to anything usable in the Piston when this error occurs. It would be good for webCoRE to check for 204 and not bother checking the for body content (and not throwing an exception) so that the piston runs cleanly.

How do changes actually get made in webCoRE? I’m assuming it’s open source and anyone can submit pull requests through git? If you have any info/links on how the webCoRE code gets updated I’d appreciate it. Also, is it common for people change their own webCoRE code on their hub to test changes first?

Thanks!

#7

The fix for 204 responses is in the dev branch, but pull requests for any other improvements can be submitted against the dev branch here. Since SmartThings is likely to discontinue the Groovy platform eventually and core contributors are working on something new, small fixes and improvements are much more likely to be accepted here than larger changes that require extensive testing.

This is how I test my own work, but I don’t have a particularly mission-critical automation setup so it is unlikely for what I test to break anything; a separate Samsung account would be wise to completely separate testing from live code.

PM me if you have programming experience and are interested in contributing to future webCoRE versions :grinning: