[Icecast-dev] 206 response for Chrome Mobile

[Andrew Akers]

> On Dec 9, 2015, at 19:19, Byron Young <bky at bkyoung.com> wrote:
> 
> Doesn't the missing "Accept-Ranges" in response inform the client to
> resend the request without Range:?


No, because all responses for a get request with range request where the server supports it should return 206 and the additional header codes. In this case, Icecast returned partial content while telling the client it returned all the content. The client won’t make another request because it thinks it got all the content.

> I think only the file server would serve partial content in this way, as
> the streaming server implies partial content as part of its protocol.
> 
> Anyway, the response seems as requested. 0 (empty) or 1 bytes partial
> content was requested, and empty response returned.

The browser in this case doesn’t know that it’s getting a stream, it could be just downloading an mp3.

Returning partial content while notifying the browser it got full content is the root of the issue here.
______________
Andrew Akers
andrew at akrs.me



> On Dec 9, 2015, at 19:19, Byron Young <bky at bkyoung.com> wrote:
> 
> Doesn't the missing "Accept-Ranges" in response inform the client to
> resend the request without Range:?
> 
> I think only the file server would serve partial content in this way, as
> the streaming server implies partial content as part of its protocol.
> 
> Anyway, the response seems as requested. 0 (empty) or 1 bytes partial
> content was requested, and empty response returned.
> 
> 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
>> 
>> 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/
>> 
>> 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?
>> ______
>> Andrew Akers
>> _______________________________________________
>> Icecast-dev mailing list
>> Icecast-dev at xiph.org
>> http://lists.xiph.org/mailman/listinfo/icecast-dev
> 
> 
> _______________________________________________
> Icecast-dev mailing list
> Icecast-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast-dev