[Icecast-dev] 206 response for Chrome Mobile

[Andrew Akers]

> On Dec 10, 2015, at 05:57, Philipp Schafft <lion at lion.leolix.org> wrote:
> 
> 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.

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

> 
>> 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?
> 

Weird. I definitely got 0 bytes, according to the Chrome dev tools. I might have to go raise a ticket with them.
I’ll test it out again tomorrow.

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

Yeah, it looks like a weird check to see if the server supports range. I’ll poke at it again tomorrow, and report the results.

> Looking forward to your reply!
> 
> --
> Philipp.
> (Rah of PH2)

Thanks!
______________
Andrew Akers
andrew at akrs.me



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.xiph.org/pipermail/icecast-dev/attachments/20151210/f1466d34/attachment.pgp