[Icecast-dev] 206 response for Chrome Mobile

[Philipp Schafft]

Good morning!

On Thu, 2015-12-10 at 14:50 -0800, Andrew Akers wrote:
> > On Dec 10, 2015, at 05:57, Philipp Schafft <lion at lion.leolix.org>
> wrote:
> > On Wed, 2015-12-09 at 17:39 -0800, Andrew Akers wrote:
> >> 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.

Hm, ok. Can you have a look on the packets on-wire? Which peer closes
the socket?


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

Ok. Looking forward to it!

Thank you for your work. Whatever it is it's at least useful to be aware
of it.

-- 
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/20151211/b35ec99e/attachment.pgp