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.com:

"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.

You broke more than 187 radio stations at our company. I hate you rigth now.

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.

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 http://saynotolinux.com/shoutcast/

Patch by @jordanmilnes reuploaded. Allegedly this BREAKS listing on shoutcast.com, but fixes Chrome 55 and fresh versions of Safari.
http://s000.tinyupload.com/index.php?file_id=83336842146235185536

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

@ p...@icode.se 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.

Hello

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 ...

@jordanmilnes

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

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

That is the only element missing from metadata send to yp.shoutcast.com

Guys,

i found this: http://onair18.xdevel.com:8042/ , 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.

Thanks

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 eRadioNow.com 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

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 https://www.shoutcast.com/BroadcastNow, 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.

FYI I've updated the patched Linux binary to be able to publish to the SHOUTcast directory: http://saynotolinux.com/shoutcast/ . 

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.

Hello,

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

http://www.radioforge.com/

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

http://www.steamcast.com/?req=dir

Thanks

   

Deleted: sc-relay.png 29.8 KB

	sc-relay.png 29.8 KB View Download

Not very good probably ditching chrome

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: https://www.chromium.org/administrators/policy-templates)
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 https://developers.google.com/web/updates/2016/09/chrome-54-deprecations#http09_deprecated.  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: https://groups.google.com/a/chromium.org/d/msg/blink-dev/OdKnpLlvVUo/1EpFGVUjAwAJ

Deleted: chrome.adm 503 KB

chrome.adm 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).

@comment84
"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 http://shoutcast.com/broadcastnow
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. 

[1] http://www.wsrn3.org/CONTENT/Reference/Reference_NTRIP-V1-Tech-paper.pdf

deseo escuchar la estacion de radio 106.1 el LOBO,ya que me gusta mucho la musica en Ingles que pasan en esa estacion de radio, asi como la informacion de los artistas y canciones mas actuales.

Any interest for a cloned (not patched) shoutcast v1 app that avoids this issue, and lists on both xiph.org and shoutcast yp?

Let me know. Its somewhat of a personal project I've been working on for ages; this is the butt-kick I needed to get it working properly. It can read sc_serv.ini files (well the important bits anyway) so its pretty much a drop-in replacement.

I don't use sc_trans, so I've no idea how it plays with that, but I do have Windows 64 & 32-bit binaries, and can build Ubuntu 64-bit binary.

If there's enough interest, I need somewhere to **__anonymously__** host it (offers?!!) and I'll give you guys the link. I don't want to end up like the poor Edcast guy...

Key notes: Drop in replacement for sc_serv in v1 mode. Possibly v2 later, though the authhash shite is a pain in the arse for most. Runs on 'doze and Linux. Its statically linked, so has no dependencies and the exe is just over a meg on 'doze.

After much discussion and looking at how many users this impacts, we plan on re-enabling HTTP/0.9 over ports other than 80 for Chrome 56.  We'll remove it again in Chrome 57, but we'll also add a hack to allow it just for responses that look to be from Shoutcast servers (Ones that start with "ICY").  So behavior should be just like it was in Chrome 54 and earlier going forward, for Shoutcast servers (Worth noting this does not quite match FireFox's current behavior).

AWESOME !!!!, thank you mmenke@.

Thank you MMenke and the Chromium Stuff

That was awesome thank u mmenke

SHOUTcast v2 is not a viable option. Thanks as you will enable back on next Chrome build. SHOUTcast v2 is still beta (in my opinion) and will be always till they don't hire a proffesional team to develop that server and to fix all old and actual bugs, 32bits linux version of last SHOUTcast v2 release have a huge bug and they don't care to fix: 

BUG: SHOUTcast DNAS/posix(linux x86) v2.5.1.723 (Sep 30 2016)

Issue: 
ERROR	[YP] Request [https://yp.shoutcast.com/yp2] failed, code: 1 [Protocol "https" not supported or disabled in libcurl]
ERROR	[YP] Internal error. Unknown cmd value in response (8)

Anyway, thank's to enable back @mmenke

no quiero recibir mas notificaciones

2017-01-21 19:28 GMT+00:00 florin.i… via monorail <
monorail+v2.3216032244@chromium.org>:

aldoguineauneca:  If you don't want emails about updates to this bug, you need to unstar it yourself.  Click the yellow star at the top right left.  Sorry for my bad spanish, but...erm...

Use la estrella al máximo izquierdo.

feliz domingo,solo espero que arreglen el sistema para oir las emisora radiales,que no puedo conectar aqui en venezuela,siendo locales,ante lo hacia,,,parece que la competencia de los servidores las bloquean,,,gracias

Saludos para escuchar radio web ko pueden hacer por fire fox o versiones anteriores a la Chrome 55, pueden probar con livetrackradio.com

confirming this new version of chrome is less helpful. would be happy to have these sites accessible again so we can enjoy them as usual

Going to go ahead and restrict comments on this, just to avoid comments inserted in the administrivia of merging.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2617c4a136497244376e1bcf11aa356afb2a1e06

commit 2617c4a136497244376e1bcf11aa356afb2a1e06
Author: mmenke <mmenke@chromium.org>
Date: Tue Jan 24 16:53:52 2017

Enable HTTP/0.9 on non-standard ports by default

This is a temporary patch to enable HTTP/0.9 on non-standard ports by
default.  After merging it with Chrome 56, it will be reverted, in favor
of specifically adding detection of Shoutcast servers on HTTP ports
other than port 80.

BUG= 669800 

Review-Url: https://codereview.chromium.org/2651753002
Cr-Commit-Position: refs/heads/master@{#445743}

[modify] https://crrev.com/2617c4a136497244376e1bcf11aa356afb2a1e06/chrome/browser/io_thread.cc
[modify] https://crrev.com/2617c4a136497244376e1bcf11aa356afb2a1e06/chrome/browser/net/errorpage_browsertest.cc
[modify] https://crrev.com/2617c4a136497244376e1bcf11aa356afb2a1e06/net/http/http_network_session.cc

Requesting merge of https://codereview.chromium.org/2651753002 to M56.  See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qS63pYso4P0 for details.  Change is low risk - setting a bool previously controlled by group policy to be true by default instead of false.

Once merged, I'll revert from trunk and land the long term solution instead (Which will need to be merged to M57 as well).

This bug requires manual review: We are only 6 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Note that https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qS63pYso4P0 also briefly mentions impact - about 0.4% of users are potentially running into an affected page each week (Some of these are undoubtedly running into things other than shoutcast, unclear what portion of them are).

Approved for merge into M56 based on comments in the thread and low risk of the CL.

Please merge your change ASAP, M56 Stable RC cut is at 4.00 PM today 1/24.

I'm having trouble applying it, unfortunately.  I'll try to make the deadline, but not promises, as I haven't had to work through this sort of thing in quite a while.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22

commit 431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22
Author: mmenke <mmenke@chromium.org>
Date: Tue Jan 24 21:06:25 2017

Merge 2617c4a136497244376e1bcf11aa356afb2a1e06
Enable HTTP/0.9 on non-standard ports by default

This is a temporary patch to enable HTTP/0.9 on non-standard ports by
default.  After merging it with Chrome 56, it will be reverted, in favor
of specifically adding detection of Shoutcast servers on HTTP ports
other than port 80.

TBR=eroman@chromium.org
NOTRY=TRUE
NOPRESUBMIT=TRUE
BUG= 669800 

Review-Url: https://codereview.chromium.org/2651753002
Cr-Original-Commit-Position: refs/heads/master@{#445743}
Review-Url: https://codereview.chromium.org/2656693003
Cr-Commit-Position: refs/branch-heads/2924@{#856}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22/chrome/browser/io_thread.cc
[modify] https://crrev.com/431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22/chrome/browser/net/errorpage_browsertest.cc
[modify] https://crrev.com/431a5e87e4eb425d0c65cf12070b4bd3a3d0ea22/net/http/http_network_session.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/82d19a580c72707597f9e3e60d9f55f271c51317

commit 82d19a580c72707597f9e3e60d9f55f271c51317
Author: mmenke <mmenke@chromium.org>
Date: Fri Jan 27 23:26:32 2017

Revert of Enable HTTP/0.9 on non-standard ports by default (patchset #2 id:20001 of https://codereview.chromium.org/2651753002/ )

Reason for revert:
Removing to apply the CL with Shoutcast detection in its place

Original issue's description:
> Enable HTTP/0.9 on non-standard ports by default
>
> This is a temporary patch to enable HTTP/0.9 on non-standard ports by
> default.  After merging it with Chrome 56, it will be reverted, in favor
> of specifically adding detection of Shoutcast servers on HTTP ports
> other than port 80.
>
> BUG= 669800 
>
> Review-Url: https://codereview.chromium.org/2651753002
> Cr-Commit-Position: refs/heads/master@{#445743}
> Committed: https://chromium.googlesource.com/chromium/src/+/2617c4a136497244376e1bcf11aa356afb2a1e06

TBR=eroman@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 669800 

Review-Url: https://codereview.chromium.org/2656373002
Cr-Commit-Position: refs/heads/master@{#446825}

[modify] https://crrev.com/82d19a580c72707597f9e3e60d9f55f271c51317/chrome/browser/io_thread.cc
[modify] https://crrev.com/82d19a580c72707597f9e3e60d9f55f271c51317/chrome/browser/net/errorpage_browsertest.cc
[modify] https://crrev.com/82d19a580c72707597f9e3e60d9f55f271c51317/net/http/http_network_session.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d78f5290a5585d318081007097b9b2ba3b1cf311

commit d78f5290a5585d318081007097b9b2ba3b1cf311
Author: mmenke <mmenke@chromium.org>
Date: Sat Jan 28 01:20:59 2017

Add detection of Shoutcast responses and accept them as valid HTTP/0.9
responses over HTTP ports other than port 80, unlike other HTTP/0.9
responses.

BUG= 669800 

Review-Url: https://codereview.chromium.org/2648253004
Cr-Commit-Position: refs/heads/master@{#446867}

[modify] https://crrev.com/d78f5290a5585d318081007097b9b2ba3b1cf311/net/http/http_stream_parser.cc
[modify] https://crrev.com/d78f5290a5585d318081007097b9b2ba3b1cf311/net/http/http_stream_parser_unittest.cc

Requesting permission to merge https://codereview.chromium.org/2648253004 to M-57.

This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Before we approve merge to M57, could you please confirm whether change listed at #126 is well baked/verified in Canary and safe to merge to M57?

It's been in Canary for a couple days without issue, and seems to fix the problem in my limited testing.  It's also a low risk CL (Basically code that was gated on a group policy is now gated on group policy and an extra check).

Approving merge to M57 branch 2987 based on comment #129. Please merge ASAP. If merge happens today before 5:00 PM PT, then we can take it for tomorrow's last M57 Dev release. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129

commit 9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129
Author: mmenke <mmenke@chromium.org>
Date: Mon Jan 30 19:58:38 2017

Add detection of Shoutcast responses and accept them as valid HTTP/0.9
responses over HTTP ports other than port 80, unlike other HTTP/0.9
responses.

BUG= 669800 

Review-Url: https://codereview.chromium.org/2648253004
Cr-Commit-Position: refs/heads/master@{#446867}
(cherry picked from commit d78f5290a5585d318081007097b9b2ba3b1cf311)

TBR=mmenke@chormium.org
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2665603003
Cr-Commit-Position: refs/branch-heads/2987@{#176}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129/net/http/http_stream_parser.cc
[modify] https://crrev.com/9c2e8faa7a7eadb232fb4f5c2a1eaccbae88c129/net/http/http_stream_parser_unittest.cc

Unrestricting this issue to comments, in case people run into further trouble.  Note that only Chrome 56 and 57 (And later) have fixes, and Chrome 56 isn't on stable channel yet.  Once people are using 56 or later, please post if you're having trouble with Shoutcast servers (If they're working fine, no need to comment).

Tested the issue on Mac 10.12.2,Win 10 and Ubuntu 14.04 using Dev # 57.0.2987.19 and Beta # 56.0.2924.84, below are the observations.

Steps followed:
1) Followed the steps from Comment #0.
2) Opened http://www.memoryradio.de:4000/;7094720172667444stream.nsv
It starts downloading where as Firefox plays it.
3) When opened radiotest.html the first stream is not playing and rest 3 are playing(same behaviour in FireFox too).

mmenke@: Attached the screen cast of Mac here with, please confirm on the same.

Deleted: 669800_Jan_31.mp4 714 KB

	669800_Jan_31.mp4 714 KB View Download

This matches behavior prior to the regression - Chrome doesn't mime sniff nsv files (Per mime sniffing spec).  It needs to be in a media element to play, I believe.

(Note that with chrome 55, you just get an error page)

Had an offline chat with  mmenke@ and performed another testcase with media with Chrome  57.0.2987.19 on Windows 7,10, Mac and Linux.

Steps followed:
1. Try to open "data:text/html,<audio controls> <source src="http://hazzardstream.de:7777/stream/1/" type="audio/mpeg">" in omnibox amd make sure audio is playing.

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!!!