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
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
> 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
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-1Asking 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
> 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