Roku Developer Program

Developers and content creators—a complete solution for growing an audience directly.
cancel
Showing results for 
Search instead for 
Did you mean: 
greubel
Level 7

GetToString Hang

While testing yesterday with a lot of DLNA servers active (22), my Roku3 would hang on a GetToString() during discovery. My other three Roku hardware versions didn't have a problem. Checking the debug console, it was always a request to a WebDev server attached to Twonky on my Mac. It was VERY intermittent but I found that if I turned on debug logging but didn't have a telnet session connected, it failed almost every time. I ran a network trace to see what was going on.

Roku -> Mac - HEAD request for a url
Mac -> Roku - Response headers
Mac -> Roku - Response Body ( This isn't normal but who knows about webdav ! )
Roku -> Mac - GET request from GetToString()
Mac -> Roku - Response headers with body
Hang

My solution was to ignore a url with "webdav" in it, which is not a GOOD fix.
Could the response body being on the TCP stack cause the GET to fail ?
The Roku3 is running 5.5 319
0 Kudos
2 Replies
EnTerr
Level 8

Re: GetToString Hang

Hm, seems the Twonky Server behavior is flat-out wrong and in the face of the HTTP spec:
"RFC" wrote:
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.
If all-caps were not clear enough, there is even spec on that:
"rfc2119" wrote:
MUST NOT - This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
I am not excusing Roku for hanging - it shouldn't; just seems Twonky should take most of the beating*.

BTW, were both requests sent over the very same TCP session (I.e. was http keep-alive'd) or in two separate ones?

(*)The beatings will continue until morale improves
0 Kudos
greubel
Level 7

Re: GetToString Hang

Both requests were on the same session (port, no close).
I agree Twonky is wrong BUT it still shouldn't hang !
0 Kudos