Emulating HTTP request through TCP raw port communication?

[Carsten Kurz]

I recently came across some devices that do not support raw port communication over UDP or TCP as common DCI servers allow it. Instead, they react on very basic HTTP requests. Now I'm wondering wether one could put together these simple HTTP oneliners with the RAW TCP communication to port 8080 that all DCI servers allow to setup in ASCII or binary. I find little information on the net over the 'raw' message composition that creates a HTTP request, though. Or, probably, I am looking at the wrong places or using useless search terms.

An example would be:

http://192.168.1.xxx/relay/0?turn=on

[Kevin Cloutier]

Carsten,

I believe the JNIOR can do what you are asking about. The JNIOR can form the http request and send it over port 8080. In case i misunderstood and you are asking if a device can receive those commands, then the JNIOR can do that too.

Attached is a picture of the Tasker setup that will enable sending the request you showed above over port 8080

Is this what you are looking to do?

[Harold Hallikainen]

You might try a minimal HTTP header and see if the device likes it. Something like:

GET /relay/0?turn=on HTTP/1.1\r\n\r\n

[Kevin Cloutier]

Also, Tasker and the JNIOR will handle basic HTTP authorization via the formatted URL.

[Marcel Birgelen]

You might try a minimal HTTP header and see if the device likes it. Something like:

GET /relay/0?turn=on HTTP/1.1\r\n\r\n

Since you're claiming to be doing HTTP 1.1, you should add a host header, as that's required by the specs. Stuff may break without it.

host: <hostname>[:<port>]\r\n\r\nGET /relay/0?turn=on HTTP/1.1\r\n\r\n

Most devices that expose an api will probably not host multiple site on the same IP, so the hostname can be the IP address to in that case. The <port> part should only be used if the port is not a default port (80 or 443).

You could also try to do a HTTP 1.0 request, but you could run into compatibility issues there.

[Harold Hallikainen]

I think it's just one \r\n at the end of each header line and \r\n\r\n at the end of the headers (and the beginning of POST data if this were a post).

I was not aware that the host header was required. I remember in the mid-1990s, the place where my wife worked got their new web site. But when they tried to look at it, they got a page from the ISP. Their browser was not sending the host header.

Harold

[James Gardiner]

see this ************ video where I go over exactly how to do what you are looking at with an IMS2000.
https://www.youtube.com/watch?v=kN1BQM7UMps

[James Gardiner]

See the ****** that is suppose to be C-i-n-e-T-e-c-h-G-e-e-k, my youtube channel. Considering its videos are specifically of interest to members of this site.. Bad form to block it on this site. Bad form.

[Harold Hallikainen]

Very good James! It looks like the command supports multiple lines and puts in a CRLF between lines. In the post request, either a blank line or an extra CRLF is needed between the headers and the post data. And the Wait on the Dolby server is \W . I was not aware of the \w for the shorter wait (according to the video, \W is a 1 second wait, and \w is a 100ms wait).

Thanks for the video!

[James Gardiner]

Yes Harold, the WAIT special character was not documented anywhere. I had a long discussion with the Dolby developers before this popped out in an Email. I must say, Dolby has been amazing with their support and sending the hard tech questions to the right people in the development team.

This video demonstrates how easy it is to send a RAW HTTP request over a socket but the application in question MUST NOT send and immediately disconnect, otherwise the web request will fail. Meaning, just because you can send directly into a RAW socket, it will not always work (That delay must exist).

The main reason I wanted to make this video was to indicate how HTTP based messaging is becoming SO prevalent now. And we need to move on from binary-based protocols that are a devil to implement and understand. When HTTP and JSON are so pervasive in all internet technology these days.

For example, Barco has moved away from their legacy protocols and S4 onwards is a good old REST over HTTP. You can easily send a command to the equipment with an easy-to-read curl command. the way it should be.

[Harold Hallikainen]

I first heard of the \W many years ago when trying to get a Dolby server to properly drive a JSD-100. It is nice that they include that!

I like the simplicity of a TCP command string. Sending a simple command over HTTP is a bit "verbose" (like COBOL). I had to deal with SOAP commands to the CP850 so the LSS-200 could get the CP850 to send pink noise to selected speakers. A simple command string over TCP would have been much simpler.

Harold

[Carsten Kurz]

Why would I need to include the server address within the string when the device I am talking to through socket communication already has been set up with a target IP address and port, ready to receive just the command + escape characters?

Does the IMS2000 have specific communication capabilities here? The video does not show the device setup.

[Harold Hallikainen]

As Marcel pointed out, HTTP 1.1 requires the Host header. Prior to the host header being introduced, each web site had its own IP address. Now a server at a single address can host a lot of web sites as virtual hosts. The server looks at the Host header to determine which content to serve. For example, I have a half dozen or so domain names all pointing to a single virtual private server at Contabo. The browser includes the Host header so the server knows what content to send. If there are no domain names being used (just IP addresses), the IP address can be in the Host header.

Servers are supposed to return an error if the Host header is not present, so we need to include it even if we are not using virtual hosting.

[James Gardiner]

My recommendation to Dolby was to make a new type of RAW message sender that specifically understands HTTP requests and brings up an interface to better implement the messages.
ie, GET request with URL encoded variables or a POST with the body holding a JSON message etc. stuff like that.

Basic RAW commands, I agree are easy, but they don't have the error handling around them that HTTP does. Of which can be useful in identifying problems etc. Especially in the totally autonomous world we live in now.

The other feature request I had with Dolby was the implementation of $VARIABLES in the command definition. So, for example, you could send a message to a device that also included certain data. the Cinema, playlist, CPL etc. ($PLAYLIST_NAME, $CURRENT_CPL, $CURRENT_TC) This could be used to trigger different devices with contextual awareness. The device can then make decisions based on the message sent..

For example, get IP cameras to take a picture of the audience at a specific timecode for a specific CPL (Movie/ad). stuff like that.
I am sure you guys could think of a lot of cool ideas with such a feature.