[Icecast-dev] 206 response for Chrome Mobile

[Byron Young]

On Thu, 2015-12-10 at 14:50 -0800, Andrew Akers wrote:

> I agree it’s a weird hack. They’re probably checking to see if the server supports range.

Seeing as you are probably digging through the client code; if for
whatever reason (not sure what that would be), to support it, would the
proper response (as far as what the client is expecting) be a 206,
Accept-Ranges:, and 1 byte? Then expect to continue the connection? And
a return of 200, no Accept-Ranges:, and 0 end the connection (whichever
side) means not supported so resubmit?

Regarding bandwidth issues. Classifying control traffic as a priority at
the bottle neck network interface that owns the queue helps, although,
increasing bandwidth is the only solution to stop the whining. At least
until customer / user growth / demand resumes the cycle, which is a good
thing I guess.

Cheers!