Roku Developer Program

[tzroberts]

Did something break with the latest firmware (v 6.2 build 3332) I can no longer send an HTTP request via a web browser.
When I enter http://192.168.10.201:8060/keypress/Right or any similar into my web browser I get back a "Bad Request" from my Roku 3.
Has anyone had this type of issue?

[belltown]

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-30ExternalControl...

[tzroberts]

Strange...this was working 5 days ago.

[belltown]

"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.)

[TheEndless]

"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.