[Icecast-dev] 206 response for Chrome Mobile

[Philipp Schafft]

Good morning,

On Wed, 2015-12-09 at 17:39 -0800, Andrew Akers wrote:
> Hi -
> 
> I'm using Icecast to stream some audio that I embed in an <audio> tag
> on a webpage. This is working great for desktop browsers and on iOS,
> but it doesn't work on Android.
> 
> It looks like Chrome mobile sends the header "Range: bytes=0-1" and
> then doesn't try to load any more data when Icecast responds with a 0
> byte "HTTP/1.0 200 OK" response. From my reading of the HTTP spec, it
> looks like there's two options here: either ignore the range header
> entirely, or return a 206 response along with headers indicating the
> kinds of range responses we can deal with. Here, it doesn't look like
> Icecast does either.
> 
> The headers:
> Request:
> GET /mount.mp3 HTTP/1.1
> Host: host:8000
> Connection: keep-alive
> User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5X Build/MDB08L)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.76 Mobile
> Safari/537.36
> Accept: */*
> Referer: https://host/
> Accept-Encoding: gzip, deflate, sdch
> Accept-Language: en-US,en;q=0.8
> Range: bytes=0-1

Asking for bytes=0-1 is a strange thing to do anyway! Sounds like a
strange workaround to me.


> Response:
> HTTP/1.0 200 OK
> Server: Icecast 2.4.2
> Date: Thu, 10 Dec 2015 01:23:11 GMT
> Content-Type: audio/mpeg
> Cache-Control: no-cache
> Expires: Mon, 26 Jul 1997 05:00:00 GMT
> Pragma: no-cache
> Access-Control-Allow-Origin: *
> icy-br: 32
> ice-audio-info: bitrate=32;channels=1;samplerate=44100
> icy-description: Description
> icy-genre: None
> icy-name: mount
> icy-pub: 0
> icy-url: https://host/

Ok, how much data you get?

I just tried with Icecast2 2.4.2 and with *exactly* your request (using
netcat). I got a 200 OK (as expected) and got the data from the stream.
Which is in my opinion exactly what you said above and also how I
understand the specs: it ignored the the range header completely.


> Is there a quick patch to disable range support, or a place you can
> point me to in the code that might be causing this behavior?

There is no config setting here. It's all implemented in
fserve_client_create() in fserve.c. Which is not even called from the
code path for active mounts. It is only called when sending flat files
from the filesystem. And it will fall back to ignoring the range header
in case there is a problem (like a seek failed).

Please come back to me and tell me how much data you got from the server
with your request?

I more suspect your client implementation cutting the data after the
expected amount. As this request already looks like a strange workaround
for something I'm not too sure their implementation is all correct here.

Looking forward to your reply!

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20151210/4037b9ea/attachment-0001.pgp