Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 669800 Shoutcast streams on non-standard port would no longer play
Starred by 55 users Reported by, Nov 30 Back to list
Status: Assigned
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression

Blocked on:
issue 624462

Sign in to add a comment
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.3 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Open a shoutcast stream broadcasting from a non-standard port, i.e.;7094720172667444stream.nsv - the only thing you get is ERR_INVALID_HTTP_RESPONSE
2. Open the attached html file with several shoutcast streams embedded as HTML5 audio - none would play

What is the expected behavior?
1. In Chrome 54, the stream would start a download (it would play in Firefox)
2. In Chrome 54, all radios embedded in the attached HTML would play fine

What went wrong?
This seems to be related to changes mentioned in and the same issue reported for WebKit here: 

Internet Exploder and Firefox would still play old shoutcast streams on non-standard ports fine.

Did this work before? Yes Chrome 54

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? No
 WebKit Nightly/ Safari 10.0.1 on Sierra

Chrome version: 56.0.2924.3  Channel: n/a
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 24.0 r0

This is not a bug and the problem seems to be on the broadcasting side,  but the recent changes regarding limited/canceled support for HTTP/0.9 will make thousands of internet radio stations unplayable in Chromium based browsers.
Added missing attachment with embedded radios.
797 bytes View Download
I can also confirm the issue happening on Windows 7 as well as Windows 10 on Chrome 55.0.2883.59 beta (64-bit).

According to our records on a majority of Shoutcast Radio Broadcasters will be affected by this issue.

It would be good if this issue is resolved before the final release of Chrome 55.

Anton Tandiono
Product Manager Website by GmbH
Labels: -Pri-2 M-55 Pri-1
As per the description, this looks a regression in M55. Lopping to folks involved.
cc'ing mmenke@ for more insights on the issue.
Components: -Internals>Media Internals>Network
Status: ExternalDependency
Viktor:  As you say, we're removing support for HTTP/0.9 over non-default ports, due to a security issue (See issue 600352 for a description of the actual security issue).  Safari has done this as well, as you say, and I expect Edge and FireFox will do the same as well.

To fix this, the servers just need to send valid HTTP/1.x headers before the response body, or they can use port 80, though we'd really like to work towards removing HTTP/0.9 support entirely.

It is unfortunate that this change break existing Shoutcast servers, but our metrics indicate that HTTP/0.9 usage remains fairly low, and I don't think this is a widespread enough problem to warrant bringing back HTTP/0.9 support, potentially indefinitely.
Labels: -Pri-1 Pri-2
This shouldn't block M55, and given that Safari's already shipped this, I don't think we're going to want to rush out a revert (Or revert at all).
Comment 7 Deleted
In version 55 you removed the flash player, and support for http0.9. It is impossible to listen to all radio stations using shoutcast server v1! Please fix it!
As a website developer for our radio station, this indeed affects as badly. 
Our Shoutcast live stream no longer works in Chrome. Please fix.

Firefox appears to treat all streams beginning with "ICY " as if they were HTTP/1.0, would that be an acceptable workaround?

For ref this was added in
That looks like a hack around an issue with mime sniffing.  I don't think we want to add a permanent hack to the web platform for this case - it just doesn't seem a widespread enough issue, and given that there's apparently only one software package with the problem, it seems more reasonable to update that, rather than impose a feature on all web browsers in perpetuity.
I understand. The issue is widespread. Most internet radios use the shoutcast v1.
Shoutcast uses HTTP 0.9. I have a company Internet radio. Thousands of customers have lost the ability to listen to music through the fault of chrome.
I can not force my customers to upgrade shoutcast server. Internet radio stations is too much.
Your actions are too aggressive.
Please restore support http 0.9 :(
The change was made due to a security issue with HTTP/0.9.  The fact of the matter is we (And other browsers) are basically stuck either supporting HTTP/0.9 over arbitrary ports forever, or we have to have some path to removal.  Given the security issue, and the low usage of HTTP/0.9, removal seems the way to go.

Fact of the matter is that if we keep HTTP/0.9, the situation is unlikely yo changed in one year, and quite likely it won't have changed in 10 years, given that shouldcast v1 hasn't been updated in 10 (?) years.  And even if that does change, new servers will sprout up relying on HTTP/0.9 support.  We have a responsibility to our users to close the security issue.
Can't you really make such hack as Firefox and treat ICY header as HTTP 1.0? I know that you want Chrome to be as small and fast as possible, do it on mobile version but not on desktops. It is only 4 lines of code, remove support for other services, but not for Shoutcast v1, that won't be updated by and is crucial for thousands of radio stations that also can't easily update to v2 (you must upgrade your links to stream on any site, directory or app). It can be compared to force stop using DOS in Windows.
My website has this code:
<audio src=";" controls preload="none"></audio>

The audio server sends a valid status line (ICY 200 OK) and valid key-value pairs:
icy-notice1: <BR>This stream requires <a href="">Winamp</a><BR>
icy-notice2: SHOUTcast Distributed Network Audio Server/win32 v1.9.8<BR>
icy-name: Hitradio OE3
icy-genre: Pop
content-type: audio/mpeg
icy-pub: 1
icy-br: 128

but because of some bug Chrome ignores these headers and assumes that the entire response is an HTTP/0.9 body, with no headers.

"ICY 200 OK" isn't a valid HTTP/1.x response to an HTTP/1.x request.  Previous versions of Chrome treated it at HTTP/0.9 response (And new versions still will, but only on port 80 for HTTP, and port 443 for HTTPS).
Just to give an idea of the magnitude of the issue: 
At we know of around 4000 broadcasters affected. 
The number of broadcasters affected worldwide is very likely much higher.

Shoutcast only gave information that official builds of Shoutcasts DNAS v2.4 and newer should not be affected. It doesn't look like they will provide a patch for v1.9.x

We at are very concerned about this issue and are forced to inform our users to use Firefox, Internet Explorer, Edge or our mobile app, if they wish to continue listening to their (affected) stations.

Anton Tandiono
Product Manager Website by GmbH

This is a serious issue affecting thousands of our streaming servers.
Please consider a Shoutcast specific hack, looking for the "ICY" result code and assume it's http/1.0.

This is a VERY serious issue that could effectively put us out of business. I am needing more time to create a work around/fix for this. However, we need Chome to revert back for a few months longer to give us a chance to fix.  This update came with no warning to us. We need time to create a work around.
Google, please fix!!!
all my shoutcast_V1 stream are DOWN with google chrome 55.
Comment 22 Deleted
Comment 23 Deleted
Google, it is mandatory that you revert this. Just look, over an half of the top listeners streams aren't working anymore.

YOU have broken it :(
No promises, but we're talking about rolling the change back for a couple months.  The concern is we'd just break a bunch of shoutcast streams then, instead of breaking them now, with no significant improvement in the situation.
How about include:  Shoutcast specific hack, looking for the "ICY" result code and assume it's http/1.0. - Hence, you would never have to break them at ANY date!
For folks running shoutcast servers on non-port-80: Are there specific issues which prevent moving to newer versions of the server (like DNAS 2.4)?
> Are there specific issues..
The main issues I know about are:
- The sheer number of installed v1 servers. Can be hundreds on a single node. Need time to migrate
- Many servers are managed and monitored by automation systems that assume shoutcast v1. This can also be fixed given enough time (months)

> The sheer number of installed v1 servers. Can be hundreds on a single node. Need time to migrate

I patched DNAS version 1.9.8 to send radio streams back with an "HTTP/1.0" response line instead of "ICY": . 

I'm not familiar enough with SHOUTCast clients to know if that's kosher or not, but it seems to unbreak playing in Chrome 55 and might be an OK stopgap between DNAS 1.9.8 and 2.x. The protocols seem to have the exact same semantics.
I have checked @jordanmilnes patched linux binary. Thank you!!
It's safe to use: it changes only 2 bytes, a HTTP string and the version string. Displayed version is "v1.9.9 (Dec 10 2016)"
I did not test run it.

For chromium, a temporary rollback may still be the best option.

Could anyone verify to me if only the Shoutcast daemon is the only affected or IceCast is too?
IceCast does not appear to be affected. It uses either HTTP/1.0 or HTTP/1.1 chunked for streams.
can you do a linux version?
YES!!!the jordanmilne's patch WORK GREAT!!!!!!! Thanks 

The Patches Version has a Problem:

<12/15/16@14:39:13> [yp_add] gave error (nak)
<12/15/16@14:39:13> [yp_add] gave extended error (Using an unsupported DNAS server, use the SHOUTcast DNAS server instead to be listed.)
Hello to everyone. The Jordanmilne's patch works for chrome 55 issue but with this patch the server stop to publish the stream in the shoutcast directory.
That really a seriously problem, I believe that could ultil generate processes to Google, beucause that update and action is affecting many stream companyes and radios around the world, and who will pay the bill of that problems? You seems amateurs and not studies previously the result of your actions! I see suggestions above to solve that and stop to block that streams, so please make some thinhg to help! I 
I found a workaround: The problem is that chrome blocks HTTP/0.9 on non-standard ports per default; but this behaviour can be disabled using group policies.
Just follow these guidelines:

The policy "Http09OnNonDefaultPortsEnabled" has to be set to "enabled"/"active" (I don't know the english label, in german it's called "Aktiviert").
Restart Chrome and it works!

That's true.  That group policy will be removed sometime next year - it's to allow people time to migrate their servers (Really targeted at enterprises, but end users can take advantage of it, too).  The real solution is for server to migrate to HTTP/1.x or later.
We do need to remove support for HTTP/0.9 on non-standard ports in Chrome, for the aforementioned security reason, and we are not going to hack in support for Shoutcast streams.  The question is whether if we delayed the non-standard-port HTTP/0.9 removal, is is likely that a significant majority of Shoutcast servers could be migrated in the meantime, so we don't just run into this problem again, when we re-remove it.

Given the distributed nature of Shoutcast servers, I'm not really seeing a potential delay getting us much.
This is unfortunate but understandable given the security reasons. We're getting plenty of email complaints about this and more to come as the 55 update rolls out to more people.

Our DB of 91,218 radio servers show that 60,384 are still running Shoutcast v1. This is the vast majority of radio servers that will have any HTML5 players stop working from now on.

As this change is going to persist then more time is needed to upgrade users to Icecast or Shoutcast v2. We are going to work on an upgrade path for our users ASAP. A roll back and time frame for reimplementation would be very much appreciated in the meantime.
A roll back for at least 6 months, or maybe 12, would be great.

But Google should clearly declare this via writing it down in the changelog as significant change due security reasons.

Most newssites also publish the changelog, so there is a chance that (hopefully) many or the most server providers can upgrade to shoutcast v2.

Maybe this could be (clearly only a temporary) solution.

Quote from

"SHOUTcast versions prior to 2.0 are over 10 years old and will not be supported and will be delisted from the Website, YellowPages and API soon. Version 2.0 or better is required to retain your SHOUTcast listing. Make sure you’re on a SHOUTcast 2.0 (or newer) server to take advantage of the latest in streaming technology."

I don't think that many serverproviders are aware of this.
Hello! Not quite understand what happened and what to do!
But with online radio stations refused to broadcast 40%.
Notice that the problem only in chrome.
Are users to write, that would use alternative browsers?
Issue 674779 has been merged into this issue.
It worked and after the update it stopped. Many stations cannot stream in chrome. I have lost most my listeners. how can Google think screwing those who stream is a good idea? Why not just make youtube obsolete....oh wait, you own them!
It seems that google owns the internet and thinks it can decide what will or will not exist, and does not seem to care if there are people who still use something or not. Keep it up and soon another browser will gain space.
Comment 47 Deleted
You broke more than 187 radio stations at our company. I hate you rigth now.
Comment 50 Deleted
Could someone explain how this issue can be resolved?

@mmenke mentioned that some valid HTTP headers needs to be set on server side connection before response, could anyone point out which one?
It just needs to send a valid HTTP/1.x status line, optionally followed by valid headers.  i.e:

HTTP/1.x 200 OK

(Where "..." is either just a blank line, or HTTP/1.x headers, eventually followed by two CRLFs)
WHMSonic people have fixed this issue already. Yesterday I have received a new update from WHMSonic and my shoutcast v1 HTML5 players are working fine with chrome 55 and opera too. So, if you are using WHMSonic update your software to latest.
Comment 54 Deleted
Thanks @mmenke, this solved my issue!
Anyone got the 1.9.8 patched version? please share the download link because the one shared by @jordanmilnes is no more available on his site at

Patch by @jordanmilnes reuploaded. Allegedly this BREAKS listing on, but fixes Chrome 55 and fresh versions of Safari.

Note to mods: This issue affects all platforms, and even affects Flash on Chrome.

This will be the error after using the patched version by @jordanmilnes : 

The server wont be listed on because this hex edited/patched version does not have ICY 200 OK, it has : HTTP/1.0 200 OK, shoutcast directory will verify your server for this response : ICY 200 OK, so you have to choose either "work with Google Chrome Browser" or "Listed on SHOUTCAST Directory" you cannot have them both.

<12/17/16@13:39:13> [dest:] starting stream (UID: 3)[L: 2]{A: SHOUTcast Directory Tester}(P: 1)
<12/17/16@13:39:14> [dest:] connection closed (0 seconds) (UID: 3)[L: 1]{Bytes: 39487}(P: 1)
<12/17/16@13:39:14> [yp_add] gave error (nak)
<12/17/16@13:39:14> [yp_add] gave extended error (Using an unsupported DNAS server, use the SHOUTcast DNAS server instead to be listed.)

@ thanks! i just needed to make sure it works on google browser for my site users and listing in shoutcast directory isn't important for me.

The patch does not work! I downloaded it, stopped it, start it and it did not work, did you upload the correct patch?

I'm very worried about this, please help ...

The patched version of SHOUTcast error (publish on YP, nak error) is because this patched version do not send the Server version,

Server: SHOUTcast Distributed Network Audio Server/Linux v1.9.8

That is the only element missing from metadata send to


i found this: , seems to be another patched version of SHOUTcast DNAS v.1.9.8, know somebody where we can find that version, have included a html5 player on status page.

Hello all, 

This is so annoying. Every time Google decides to update, we, developers always suffer. This update broke hell of a lot of things in my company too. We've decided to go back to the IE11 (not joking). I had to re-code all my applications in the past 3 days. Surprisingly my collages said that its (the new apps) looks better, feels better in IE. (again, not joking). 

My major problem is, that our radio streaming website suffering of this. #knockoneffect
At we trying to find some solutions with no success. We hoped we could support the 1000's of stations, but we are nowhere compared to Google's mess. Now, we have to wait all of you guys to upgrade your patches. 

Obviously the major browser is Chrome. I really hope some other company will come along and beat them down. 

google! You are so frustrating! 

To all streamers! I feel sorry for you all!
This seriously affects 1000s of stations like myself
I hope someone can create a workaround until Chrome gets its finger out
Another frustrated radio owner here, it was bad enough killing our flash players not long ago, having to re program new players, now even those do not work it's all well and good telling listeners to use Firefox, Edge or Internet Explorer, but Google have promoted Chrome on a big scale, removing services only harms the end user, it may be a small issue to Google, with a fraction of people affected BUT that fraction is hundreds of thousands of internet users who regularly use Chrome to access web radio via Shoutcast, I know of no other (even huge company) who can happily irk so many people, these people will still access web radio they just will not use Chrome, this update has harmed the user, the companies who run radio outlets and yes Google itself.
Updating Shoutcast V1, means changing all the sockets of my IRC bots. Too many hours of missed programming!
On another occasion, I had to change the flash players, now I have to change the version of my Shoutcast?
The only solution I have found until fix it, is to recommend to my listeners that they use another browser.
If anyone knows a patch for Linux Centos 7 64 bits, thank you for sharing it.
Upgrade Shoutcast to version 2.x. It worked for us
Status: WontFix
Thanks for all the feedback on this bug. Ultimately we have decided to keep the behavior introduced in Chrome 55, where HTTP/0.9 (or HTTP/0.9-like) responses are no longer accepted on non-standard ports. 

The reasons behind this decision have been stated earlier in this bug, but to summarize:

- This change in behavior was originally introduced to address a security issue. Safari has also changed behavior for this reason.

- HTTP/0.9 usage across all servers exhibited low usage across Chrome. This included not only Shoutcast servers on non-standard ports, but also any HTTP/0.9 servers on any port.

- An upgrade path exists to Shoutcast v2 which will work with Chrome 55. It looks like this does not cost money to upgrade. According to, SHOUTcast versions prior to 2.0 are also not supported and will be delisted from their site.

For security-initiated deprecations like this we have to make a tradeoff between the majority of users who are not using HTTP/0.9 (or interpreted response), and the impact removing the feature will have on those who are using it.

The recommendation is that folks who have deployed an earlier version of SHOUTcast upgrade to a newer version of the server.

cbentzel@ we really don't care what Safari does or does not, we asked you/in here about Chrome, we don't need reasons like Safari did that, Mozilla will do that, etc.

I tell you all, forget about Chrome. Use your favorite which works.
I mean seriously cbentzel@? I guess you speak on behalf of google... Google didn't come up with an original idea. It was enough for them to read this thread through and see what the individuals come up with. 

How dare you! I already using FFox.

Looks like in USA everyone lost their mind... No we can #blameTrump and #blameGoogle
Outside of America and the UK, almost nobody uses the desktop version of Safari and most iPhone/iPad users don't care about Safari's compatibility with Shoutcast because they listen to radio stations using native iOS applications in the background.

Oh Apple #bureaucrats.
Status WontFix? Rly? Are you kidding?

Google, YOU, and ONLY YOU breaked this! What Safari does is interesting 0% (in words: ZERO!)
You are abusing your dominant position in the market. You have been completely wrong, you have left thousands of radio stations without service in your browser. Instead of thinking of a solution, your answers are superb and abusing your position. You are simply pathetic.
I am pretty sure that, Chrome will have the Internet Explorer faith, useless.
Your argument of low usage across Chrome is pathetic. Of course have low usage, because the the listener does not remain clicking all the time in the player link to listen, it is normal for the person to access the player and continue navigating the radio website by listening to the radio. The listener will access one time the shoutcast but can access hundreds of other files / pages of the radio station. Dictators!
Time to move to Opera folks. Fast and clean. with built in VPN.
To me this is a predatory move to squash open source streaming to line their own pockets with more money.
Don't be evil my ass.
I agree with what most participants think, but the solution is to use the Patch by @jordanmilnes
Some have reported that that patch removes the radio from the Shoutcast lists, but anyway versions prior to 2, will be removed from those lists soon, according to Shoutcast.
I worked this solution perfectly and my Radio is not interested in being in the Shoutcast Lists.
Blockedon: 624462
FYI I've updated the patched Linux binary to be able to publish to the SHOUTcast directory: . 

Please email me directly using the email on that page if you have any issues with the patches rather than commenting here, as to keep this thread clutter-free for the Chromium folks.

I agree with mmenke, though. It's a wonder that DNAS 1.9.8 streams ever worked correctly in Chrome, and these binaries are 10~ years old. People should upgrade to DNAS 2.x servers as soon as they're able.

Shoutcast Relay: It may be temp solution for Shoutcast V1. Most of SC V1 server use ICY 200 header ... where we need HTTP

Use Shoutcast Radio proxy or Shoutcast Re-streaming for Shoutcast old version


29.8 KB View Download
Not very good probably ditching chrome
Status: Assigned
In case people missed it in the debate above, there is a (probably temporary) work-around for these issues.  On Windows (tested on Windows 10 but earlier versions should work too):

1) Download the attached policy template (which comes from the ZIP file described here:
2) Go to Start->Run (or Windows-R) and type "gpedit.msc"
3) Select User Configuration -> Administrative Templates
4) Right Click and choose "Add/Remove Templates..."
5) Click the "Add..." button
6) Select the chrome.adm file you downloaded above
7) Close the add/remove templates window
8) Still under "Administrative Templates" open "Classic Administrative Templates (ADM)"
9) Open "Google" then click on "Google Chrome"
10) In the list of settings on the right find "Enables HTTP/0.9 support on non-default ports" (just over half way down)
11) Double click that to edit and set the policy to "Enabled"
12) Click OK and then close the group policy editor window
13) From Chrome go to the URL chrome://policy
14) Click the "Reload policies button"

You should now see an entry for Http09OnNonDefaultPortsEnabled saying the policy value is "true".  Chrome 55 will now be restored to the behavior it had in Chrome 54.

Note this was advertised here  Unfortunately we didn't hear about Shoutcast being broken from any Chrome dev/beta channel users, so by the time this issue was filed it was too late to change things for Chrome 55.

Re-opening this issue to track (in the new year) taking a closer look at the metrics and following up with the details on the original intent thread for this breaking change:

503 KB Download
Google, please fix!!!

* shoutcast v2 is not upgrade for v1, Shoutcast v2 is a new commercial product
If you'd like to register your interest in seeing this changed, please click the "star" button at the top left.  That's the signal we use to tell how many users care about the issue (and right now it's relatively small - 22).  If you have specific information to add, please feel free.  Eg. the fact that users can't simply upgrade from Shoutcast v1 to v2 is, IMHO, relevant - thank you.

But otherwise "please fix this" comments are unhelpful (just clutter the discussion and can lead to public comments being disabled).
"shoutcast v2 is not upgrade for v1, Shoutcast v2 is a new commercial product"
Where is this coming from? When I go to their website it states that SHOUTcast v2 is "Completely Free".
I just installed SHOUTcast v2.5.0.715 to check and it never asked for any payments, am I missing something here?
How to upgrade ShoutCast from version 1.9.8 to version 2.x

1) Download the latest version of SHOUTcast  from
2) Make a copy of the folder containing your existing SHOUTcast DNAS server.
3) Extract the contents of the file you downloaded which includes the latest version of version ShoutCast.
4) Temporarily stop your existing ShoutCast server.
5) Look in the folder that was just created and locate three files.
The sc_serv[.exe] file.
The cacert.pem file.
The docs folder.
Take the files and move them to the folder containing your old ShoutCast server software, overwriting the existing files (don’t worry you’ve made a copy of the original folder should anything go wrong).
Set aside the software documentation contained in #3 the docs folder so you have a local copy to refer to.
6) Start your newly upgraded  ShoutCast server.
And there you have it, you are now running the latest version of ShoutCast streaming software!
Note: The SHOUTcast D.N.A.S version 2.x includes the same functionality as version 1.98 but has many new features including increased platform stability and resource efficiency. The official word from Radionomy, the owners of the software, is that all stations are very strongly encouraged to upgrade as soon as possible. The update process as detailed above is quite straight forward and very easy, it has been achieved successfully many times and should only take about 5 minutes to complete.
"Note: The SHOUTcast D.N.A.S version 2.x includes the same functionality as version 1.98 but has many new features including increased platform stability and resource efficiency"

Sure, but if you ask the radio makers, you get the same statement!
- It's unripe
- It's anything but stable
- Not every broadcast program supports v2
- Missing metatags

To claim an update to v2 would be the better solution - no!

A tip for v1 users:
You can also use v2 as a relay for v1. Chrome users will then able to tune in.  
And regarding, Radionomy does not support v1 any more.

No one knows what Radionomy is planning for the future, but many fear since the acquisition that Radionomy will develop a business model. 
Please fix :(
You have rolled out changes that have affected millions of Internet radio users across the world. You did not think of the consequences of your actions. You hide behind the potential security risk and that Safari has already removed support to justify your unprofessional handling of this upgrade. You have done nothing more than try and pretend this issue has affected a few people. YOU ARE WRONG!!! You have rolled out an upgrade to Chrome with no due diligence in an amateur way. All I have in this forum are arrogant, weak and pathetic answers to our questions, it is plain that the 'WE ARE THE GIANT GOOGLE, WE DO WHAT WE WANT' attitude is prevalent without any commitment to fix what you have broken. I for one think it is an abuse of your dominate position in the market place and would not be surprised if a class legal action is not imminent. I would advise that you bring this issue to the attention of the management, someone that has the understanding of the word 'consequences'
"Sorry, but your Browser doesn't support our radio. We recommend to use Firefox or Opera."

Maybe we'll see this message on some websites... :(
 I'm agree with all comments.Please fix

welcome to global control of internet. time to encourage all visitors on my sites to use Internet Explorer and Safari.
Per comment #85, unless you have new information to add about the issue that has not yet been discussed (Why updating servers is hard, etc), please refrain from commenting.  Not only do "me too" comments make it harder to find the more relevant posts, they're also sent to all the other users who have starred this bug.
To all complainers: @jordanmilne has a really good fix above for this: a patched shoutcast v1 server. It appears to work very well, and is a drop-in replacement.  Also a v2.5 upgrade is not hard, and quite a good option for many.

As per commend 96 I'll add some more info why we can't easy just update our shoutcast v1.

Shoutcast v2 (the latest build) is still buggy, with our setup (I suspect meta data but haven't had time over the holiday to investigate) the v2 server doesn't work well with many client (including Chrome) it sends a small amount of data, then buffers out and drops the client after 30s.  Using a v1 server or an earlier beta v2 both work, but suffer from the header problem here.  When I get chance I'll try and diagnose the new server and post in their forums to try and get the new shoutcast v2 fixed, however that it going to take time (they don't produce new builds often).  Although v2 is the only official version my feeling (and of many others) is its still only at a beta status compared with the old v1 servers.
So for now there isn't an official version of shoutcast that works reliably with Chrome.

I've tried the patched binary above, and it does let Chrome connect, but isn't compatible with the sc_trans source we are using, it connects then drops, I've tried both the compatible and simple versions with the same result.  Again if I have time I could try and snoop the connection and see why, but I suspect sc_trans is not liking the new header, it maybe possible for compatible version patch to have a second exception to send the old header too, but as it is it doesn't work in our setup.

As a work around I've got sc_trans sending to the old beta v2 server which is then relayed to the patched v1 and it has it temporarily working, but it isn't a nice solution. Having Chrome reverted to "just work" would be a much better solution, and address the security issue (which I haven't read up on) in a more compatible way.
Google is kidding its self if it thinks only a few only a few people are affected, hundreds of thousands of stations and millions of listeners is the correct consequence of this change.

I am a station owner and my inbox is full of complaints and listener stats are down.

Using version 2 is not a short term option for us as our station uses many scripts to run tasks which don't work with Verion 2, and the station is listed on dozens of sites which all have to be updated.

Simple answer Google, 'fix it' (please)
There is at least one more oddball Shoutcast-inspired protocol affected by this - wanted to provide some details. 

The Networked Transport of RTCM via Internet Protocol (NTRIP) protocol [1] is used to transfer streaming GNSS (think: GPS) data over the internet. An example server implementation is Trimble Ntrip Caster. 

Similar to the `ICY 200 OK` header, NTRIP returns a "SOURCETABLE 200 OK" response to an HTTP/1.1 request. 

The original design doc acknowledges the deviation from the HTTP standard: "The RTCM SC-104 Committee is aware that the use of HTTP for Ntrip as described in this document differs from the HTTP standard... While the protocol described here works with many proxy servers, their use should be avoided whenever possible." Whoops. 

Apparently NTRIP v2 aims to restore full HTTP 1.1 compatibility. 


Sign in to add a comment