I’ve discovered behavior which I think is a bug, or at least too aggressive validation on incoming POST messages to the SmartThings hub.
SmartThings is rejecting incoming POST requests without a space between the colon and content-length length in the content-length header. I suspect it is because it thinks the request is malformed. I can replicate the issue consistently.
This message will be accepted and passed onto a smartapp:
var textToSend = ""+ "POST / HTTP/1.1\r\n"+ "HOST:10.0.1.4:39500\r\n"+ "CONTENT-TYPE:text/xml\r\n"+ "CONTENT-LENGTH: 147\r\n"+ "Connection: keep-alive\r\n"+ "\r\n"+ '<?xml version="1.0"?><Event seqnum="1" side="uuid:47"><control>ST</control><action>0</action><node>14 47 41 1</node><eventInfo></eventInfo></Event>'
This message will be rejected:
` var textToSend = ""+
"POST / HTTP/1.1\r\n"+
"HOST:10.0.1.4:39500\r\n"+
"CONTENT-TYPE:text/xml\r\n"+
"CONTENT-LENGTH:147\r\n"+
"Connection: keep-alive\r\n"+
"\r\n"+
'<?xml version="1.0"?><Event seqnum="1" side="uuid:47"><control>ST</control><action>0</action><node>14 47 41 1</node><eventInfo></eventInfo></Event>'`
The only difference between the two is in the CONTENT-LENGTH header, in the broken case, does not put a space after the ‘:’ and before the length specified.
This unfortunately breaks my ability to integrate ISY 994i from Universal Devices into SmartThings with callbacks. Callbacks from the ISY hub do not put a space between the ‘:’ and the length. And I of course can’t change the device itself. So I will need to build a piece of proxy software which essentially just adds a space in the request to make it work. Which means folks who want to use the SmartApp + DeviceTypes will need to run yet another server.
The only other option is to have an integration which polls meaning devices will be out of date when their status changes independent of SmartThings. Even with pollster at maximum polling rate this means devices out of synch for a minute or more. My opinion this makes the smartapp much less useful.
