Announcement

**DrO** · 14 September 2012, 01:34

v1 client connections (as that is) should have content-type in the header response (i've put it in the same case as from the code) along with all of the icy-xxx headers that are also provided to the client (based on looking at the source code in front of me and knowing i've not made any changes to what is returned for that client type).

you can verify what is being sent by the DNAS on the client connection by setting shoutcast1clientdebug=1 in the configuration file. as it's gone 2:30am here, i'm not going to try it out myself with the curl connection you're shown until i've had some sleep

-daz

**prestonconnors** · 14 September 2012, 01:34

I did some more analyzing comparing SHOUTcast to Icecast2...

SHOUTcast does send something resembling Content-Type but it does not conform to HTTP specification and sc_serv never responds with any real HTTP headers even though almost everything uses http to access SHOUTcast streams; it looks like:

ICY 200 OK
icy-notice1: This stream requires <a href="http://www.winamp.com/">Winamp</a> 
icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8 
icy-name:Test
icy-genre:Test
icy-url:http://www.example.com
content-type:audio/aacp
icy-pub:1
icy-br:48

...so is SHOUTcast supposed to be HTTP? Or is it something like "ICY tunneled in HTTP"?

Icecast2 is HTTP compliant sending normal headers.

[email protected] ~ $ curl -vvvs http://streaming207.radionomy.com:80/ABC-Lounge > /dev/null
* About to connect() to streaming207.radionomy.com port 80 (#0)
* Trying 31.12.68.207... connected
> GET /ABC-Lounge HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: streaming207.radionomy.com
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Content-Type: audio/mpeg
< icy-br:128
< ice-audio-info: bitrate=128;samplerate=44100;channels=2
< icy-br:128
< icy-description:ABC LOUNGE invites you to laze in the sun of the French Riviera.
< icy-genre:lounge
< icy-name:ABCLounge
< icy-pub:1
< icy-url:http://abc-lounge.weebly.com
< Server: Icecast 2.3.2-kh33-advert-1
< Cache-Control: no-cache
< Expires: Mon, 26 Jul 1997 05:00:00 GMT
< Pragma: no-cache

So, I will re-factor the question a bit:

Is it possible to make sc_serv more http compliant and send proper HTTP 1.0 responses, namely proper Content-Type headers so players can properly parse the content type being sent from sc_serv?

**jaromanda** · 14 September 2012, 01:41

shoutcast sends response headers like the following

ICY 200 OK
icy-notice1: This stream requires <a href="http://www.winamp.com/">Winamp</a> 
icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8 
icy-name:DEFJAY.COM - 100% R&B! (USA/Europe)
icy-genre:Pop R&B Urban Rap Hip Hop
icy-url:http://www.defjay.com
content-type:audio/aacp
icy-pub:1
icy-metaint:32768
icy-br:48

Hope that helps

edit: did not see replies until I hit post

**jaromanda** · 14 September 2012, 01:47

Originally Posted by prestonconnors View Post

Is it possible to make sc_serv more http compliant and send proper HTTP 1.0 responses, namely proper Content-Type headers

It is not a HTTP server, so why should it return HTTP 1.0 responses

Originally Posted by prestonconnors View Post

so players can properly parse the content type being sent from sc_serv?

all my players properly parse the content type from the repsonse headers coming from shoutcast servers, as they properly parse the ICY protocol, which is the protocol to use to connenct to shoutcast servers

what you are asking would be similar to asking someone to use HTTP protocol for their FTP server ...

**DrO** · 14 September 2012, 10:22

the only thing i can think is that maybe what is being used is not liking that the DNAS sends content-type instead of Content-Type (case shouldn't matter but anything is possible).

this isn't the first time i've seen requests for making the DNAS and the ICY protocol more HTTP-like but then doing that makes it less SHOUTcast-like and i'm not sure of the benefit (plus it then has the potential to cause issues for players which handle SHOUTcast properly).

-daz

**jaromanda** · 14 September 2012, 12:03

1) shoutcast streams using ICY protocol
2) every single player out there that streams shoutcast handles ICY protocol

therefore, it's not DNAS that is broken, it's the "player" "written" by preston that does not handle icy protocol correctly

please don't break 99.9999% of players to make a stream rippers life easier

**DrO** · 14 September 2012, 12:16

i never said i'm going to change ICY to be native HTTP (i've already fought this idea internally as what's the point of SHOUTcast if it's not SHOUTcast + ICY).

i can see some benefit to having HTTP/1.0 200 OK on the response instead of ICY 200 OK as it makes things like Chrome's native player load the stream or the VLC plug-in in Firefox and Opera to work. but then it's going to mess up other players and i don't want that shit.

-daz

**jaromanda** · 14 September 2012, 12:17

I know you didn't ... I was getting in a subtle dig ...

**prestonconnors** · 15 September 2012, 01:27

SHOUTcast is accessed using the HTTP protocol. There is no standardardized application protocol named ICY. Also, the player I am talking about I did not write. The application trying to access the SHOUTcast stream is the stock web browser in Android 4.0.4 which is quite a widely used application (about 500 million users).

DrO it would be great for sc_serv to conform to a standardized application protocol that is universally accepted, which is just my opinion, but I wanted to voice it. It is sad that players can't parse out non-usable header data pertaining to their application (in this case HTTP/1.0 200 OK breaking things). Those players are also stopping their users from accessing a lot of content that is compliant and HTTP based.

Until sc_serv is more standardized I will use another option that is more compliant to the protocol it is using for transport because I desire to appeal to Android users without having them install additional applications and the Android browser doesn't seem to know how to handle data that isn't application protocol compliant.

Originally Posted by jaromanda View Post

1) shoutcast streams using ICY protocol
2) every single player out there that streams shoutcast handles ICY protocol

therefore, it's not DNAS that is broken, it's the "player" "written" by preston that does not handle icy protocol correctly

please don't break 99.9999% of players to make a stream rippers life easier

**jaromanda** · 15 September 2012, 05:11

Does the android BROWSER (whatever that means) natively stream MMS, RTMP or RTSP to name just 3 other streaming protocols off the top of my head?

**DrO** · 15 September 2012, 07:12

/me bangs head on the desk

Originally Posted by prestonconnors View Post

SHOUTcast is accessed using the HTTP protocol. There is no standardardized application protocol named ICY. Also, the player I am talking about I did not write. The application trying to access the SHOUTcast stream is the stock web browser in Android 4.0.4 which is quite a widely used application (about 500 million users).

you've not read what has been said. ICY IS the SHOUTcast protocol and has been for what 13years now. it is HTTP-like and as mentioned above, breaking 13+ years of expected behaviour is not something i want to do. so it isn't an IEEE or IETC or whatever body standard, SHOUTcast is a proprietary standard and that is ICY.

Originally Posted by prestonconnors View Post

DrO it would be great for sc_serv to conform to a standardized application protocol that is universally accepted, which is just my opinion, but I wanted to voice it. It is sad that players can't parse out non-usable header data pertaining to their application (in this case HTTP/1.0 200 OK breaking things). Those players are also stopping their users from accessing a lot of content that is compliant and HTTP based.

it is conform to a standard protocol as has been said mutliple times now. changing it would make the behaviour non-standard!. there is only one way that i would considering implementing your request and that would require you to append an additional parameter to the client url as something like icy=http e.g. <server>/stream/2/?icy=http or <server>/mobile?icy=http but it is not and i repeat not going to be a default change if it were to be implemented.

Originally Posted by prestonconnors View Post

Until sc_serv is more standardized I will use another option that is more compliant to the protocol it is using for transport because I desire to appeal to Android users without having them install additional applications and the Android browser doesn't seem to know how to handle data that isn't application protocol compliant.

most browsers cannot do what you're asking for without additional plug-ins or doing it in a separate app anyway so why does Android have to be so special? it is just an OS and ecosystem like every other platform that has been before and will come. i've said my only concession on the standard SHOUTcast functionality and if that is not viable then i'm sorry but that's all that i'm going to consider. SHOUTcast not provided on ICY as default is just not SHOUTcast.

-daz

**prestonconnors** · 15 September 2012, 12:19

Originally Posted by jaromanda View Post

Does the android BROWSER (whatever that means) natively stream MMS, RTMP or RTSP to name just 3 other streaming protocols off the top of my head?

Android supports the following network protocols "out of the box":

RTSP (RTP, SDP)
HTTP/HTTPS progressive streaming
HTTP/HTTPS live streaming draft protocol:
MPEG-2 TS media files only
Protocol version 3 (Android 4.0 and above)
Protocol version 2 (Android 3.x)

Taken from:

Supported media formats | Android Developers

http://developer.android.com/guide/appendix/media-formats.html

**prestonconnors** · 15 September 2012, 12:52

Originally Posted by DrO View Post

/me bangs head on the desk

it is conform to a standard protocol as has been said mutliple times now. changing it would make the behaviour non-standard!. there is only one way that i would considering implementing your request and that would require you to append an additional parameter to the client url as something like icy=http e.g. <server>/stream/2/?icy=http or <server>/mobile?icy=http but it is not and i repeat not going to be a default change if it were to be implemented.

-daz

DrO,

Appending that parameter to the URL would work! What about parsing the GET / POST request from clients for 'HTTP' or the Accept header from clients? Theoritically only HTTP clients should be sending HTTP in their GET / POST and Accept headers and if sc_serv sees either or both of these in the initial transmission then sc_serv will send HTTP/1.0 200 OK before the ICY headers?

Even if most browsers cannot do what I'm asking by default, if they have received an HTTP/1.0 200 OK response, they should parse the Content-Type header and then prompt the user to open the file with an application that can support the Content-Type versus when they do not receive an HTTP/1.0 200 OK and the browser thinks the response is pure binary and should only be saved to a file.

I'm going to do some tests with a simple proxy with sc_serv behind that proxy that will add HTTP/1.0 200 OK responses to a request and see what the results are.

**prestonconnors** · 15 September 2012, 14:24

DrO,

I set up a simple proxy with sc_serv behine it that sends HTTP/1.0 200 OK when a new connection is opened and this allowed Firefox 15.0.1 to recognize the file as audio/aacp versus BIN
. I could not test it on Android yet. I will make some improvements to see if this will work out for me. I am already proxying sc_serv traffic anyway so this would not be a big change for my implementation.

Test link if you are interested:

http://107.20.250.243:80/test

What it looks like:

[email protected] ~ $ curl -vvvv http://107.20.250.243:80/test > /dev/null
* About to connect() to 107.20.250.243 port 80 (#0)
* Trying 107.20.250.243... % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0connected
> GET /test HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: 107.20.250.243
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.1.19
< Date: Sat, 15 Sep 2012 14:24:22 GMT
< Content-Type: audio/aacp
< Transfer-Encoding: chunked
< Connection: keep-alive
< ICY 200 OK:
< icy-notice1: This stream requires <a href="http://www.winamp.com/">Winamp</a> 
< icy-notice2: SHOUTcast Distributed Network Audio Server/posix(linux x64) v2.0.0.29 
< icy-name: Pure Party
< icy-genre: Top40,Rap,Hip-Hop
< icy-url: http://pureparty.org
< icy-pub: 0
< icy-br: 48
<
{ [data not shown]

Announcement

sc_serv Not Sending Content-Type Header

sc_serv Not Sending Content-Type Header

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment