HTTP Request

I'm getting the same thing. It looks like the Roku will only respond to HTTP POST requests, not GET requests (browsers use GET requests):

C:\>curl -i "http://192.168.0.6:8060/keypress/Right" -X GET
HTTP/1.1 400 Bad Request
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Content-Length: 0


C:\>curl -i "http://192.168.0.6:8060/keypress/Right" -X POST
HTTP/1.1 200 OK
Server: Roku UPnP/1.0 MiniUPnPd/1.4
Content-Length: 0

However, this is consistent with the documentation: http://sdkdocs.roku.com/display/sdkdoc/External+Control+Guide#ExternalControlGuide-30ExternalControlProtocolServices

Strange...this was working 5 days ago.

"tzroberts" wrote:
Strange...this was working 5 days ago.

It's not unheard of for Roku to make changes that cause things that used to work to not work any more, even though the change may technically conform to the standards/documentation. I remember a while back they changed the way the HTTP Location header was handled because one of their partners required it to be in all upper-case (YouTube had this bug I recall). So Roku changed the header from "Location" to "LOCATION", which caused several other programs to no longer work (including Roku's own SDK example program, rokuExternalControl.c). However, since "LOCATION" was just as conformant as "Location", any of the other programs that couldn't handle that were technically at fault. Same thing if you (or your browser) uses an HTTP GET to try to fetch a resource that the documentation states should be fetched with a POST request. (If you work for YouTube, you might be able to get them to change it back the way it was.)

"tzroberts" wrote:
Strange...this was working 5 days ago.

If it ever worked as a GET, I'm sure that was a fluke/firmware bug. Keypresses have always required POST, and I'm 99% certainly they didn't work with GET through numerous firmware versions, so they may have introduced GET functionality by accident, and have since "fixed" it.