sc_serv Not Sending Content-Type Header

[prestonconnors]

Hello,

Using sc_serv 2.0.0.29 on x86_64 and noticed that sc_serv does not send any Content-Type header. Is there a way to configure sc_serv to send a Content-Type header so clients can properly determine what type of content is coming from sc_serv (audio/aacplus, audio/mpeg, etc)? I am trying to get the stock Android media player / web browser to properly play audio from a stream from sc_serv by visiting http://<server>/stream but it is just parsing the data as plain text because there is no Content-Type header.

The listen.pls?sid=1 URI is sending Content-Type of audio/x-scpls but that is just for a playlist metafile. I am looking to send Content-Type of the actual stream data (e.g. http://<server>/stream).

I spot checked a few stations listed in the Shoutcast YP and noticed they aren't sending any Content-Type headers either.

Example of the lack of Content-Type header I am seeing for one sc_serv instance:

preston@preston ~ $ curl -vvvs http://83.169.60.44:8000 > /dev/null
* About to connect() to 83.169.60.44 port 8000 (#0)
* Trying 83.169.60.44... connected
> GET / 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: 83.169.60.44:8000
> Accept: */*
>
{ [data not shown]

Thanks in advance for any help!
Preston

[DrO]

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]

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:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR>
icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR>
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.

preston@preston ~ $ 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]

shoutcast sends response headers like the following

ICY 200 OK
icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR>
icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR>
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]

Originally Posted by prestonconnors

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

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]

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]

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]

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]

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

[prestonconnors]

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

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]

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]

/me bangs head on the desk

Originally Posted by prestonconnors

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

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

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]

Originally Posted by jaromanda

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:
http://developer.android.com/guide/a...a-formats.html

[prestonconnors]

Originally Posted by DrO

/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]

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:

preston@preston ~ $ 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: <BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR>
< icy-notice2: SHOUTcast Distributed Network Audio Server/posix(linux x64) v2.0.0.29<BR>
< icy-name: Pure Party
< icy-genre: Top40,Rap,Hip-Hop
< icy-url: http://pureparty.org
< icy-pub: 0
< icy-br: 48
<
{ [data not shown]

[jaromanda]

Originally Posted by prestonconnors

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

that's nice, but let's not move the goal posts half way through the game

what about the "stock web BROWSER". What protocols does it support?

[DrO]

Originally Posted by prestonconnors

Appending that parameter to the URL would work!

i know that will work as i tried it already - i had mentioned my results earlier in this same thread here (dunno why i bother to write things at times).

Originally Posted by prestonconnors

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?

wrong, all of the clients i know off send HTTP in the request so that isn't an option to detect it based on that. the only way is to have things _explicitly_ set for what is wanted and the default is going to remain using ICY in the responses.

Originally Posted by prestonconnors

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.

not our issue, that's down to how things are or rather are not handled and is just the general mess that comes to anything between any of the browsers.


now i have to decide do i add this in and delay the next release (even more than it's already been from wasting time adding in people's requests) or do i let you sit it out for an indefinite amount of time...

-daz

[DrO]

Originally Posted by DrO

now i have to decide do i add this in and delay the next release (even more than it's already been from wasting time adding in people's requests) or do i let you sit it out for an indefinite amount of time...

the clock is ticking on this and i suggest you look at the pm i sent a few days ago as i'm about at the point of reverting the changes i made and just dropping the whole idea as you'll find when you look at the pm which was sent....

-daz

[prestonconnors]

Originally Posted by DrO

the clock is ticking on this and i suggest you look at the pm i sent a few days ago as i'm about at the point of reverting the changes i made and just dropping the whole idea as you'll find when you look at the pm which was sent....

-daz

I'll test out the change now and let you know if a couple of hours.

[DrO]

make sure to check the updated pm i sent through.

-daz

[prestonconnors]

DrO,

For version sc_serv2_l64_22_09_2 the change looks good and when using ?icy=http both Android 4.0.3 and Mozilla Firefox 15.0.1 recognize the content as audio/mpeg or audio/aacp and either start playing the stream or prompt the user how to proceed (open with/save as dialog) versus not using ?icy=http where both Android 4.0.3 and Mozilla Firefox 15.0.1 just display the binary stream contents as text/plain.

It would be great to have this change commited, documented, and released with the next sc_serv iteration!

[DrO]

ok, will leave it in for the next release as it's working ok. thanks for testing and confirming things.

-daz