BUG: SmartThings hub rejecting valid incoming HTTP POST requests. Content-Length header issue

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:\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"+
"Connection: keep-alive\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.

1 Like

@Tyler looks like its worth investigating

1 Like

Tagging @jody.albritton and @slagle as well.

CAn you submit a ticket so we can track and ask engineerig to look into it.

1 Like

Clarification: Do I need to submit the ticket? If so, point the way.

In the meantime I spoke with the manufacturer of the ISY device. They are concerned that changing their messages to put the space in could regress existing integrations (which makes sense). Given having no space is still RFC compliant I can understand their position. So to make this integration work properly I need a fix here.

I’ve never seen a header without a space, so I guessed that the spec required it. I dug it up, and sure enough, the spec says that LWS is “common” but “optional”: https://tools.ietf.org/html/rfc2616#section-4.2

Might want to include that in your support ticket.

1 Like

Support@smartthings.com to open a ticket :smile:

Thanks Tim. Support request entered.

Request #183588

1 Like

Very much looking into this - I’ve got a bit of code that, regardless of how I call it, returns “groovyx.net.http.ResponseParseException: OK”.