Intent to implement and Ship: Shoutcast support

[Matt Menke]

Contact emails

mme...@chromium.org

Spec

There is no spec for Shoutcast. In practice, Shoutcast just returns HTTP/1.x 200 response with "HTTP/1.x" replaced with "ICY".

Summary

We removed support for HTTP/0.9 on non-default HTTP ports in M55 to address a security issue.  This has caused more problems than expected.  0.4% of our users encounter HTTP/0.9 subresource responses each week, which is larger than anticipated.  Some of these may be due to server errors, but we believe most of these responses are from Shoutcast servers.

I propose we add it back to M56 for a revision and in M57 remove it again, but add an exception so that Shoutcast responses over non-default ports are still treated as HTTP/0.9 responses.

Motivation

I tried to remove HTTP/0.9 support in https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/OdKnpLlvVUo to address a security issue, but due to widespread use of HTTP/0.9, we backed off, and instead removed HTTP/0.9 support on default ports.  It turns out that 0.4% of users run into such servers each week, which is much more than expected.  We feel that we should do something to improve this, but don't want to bring back HTTP/0.9 support on non-standard ports indefinitely.

We believe the primary cause of this is Shoutcast servers.  Shoutcast is a proprietary 18-year-old protocol for streaming media.  The primary Shoutcast server in use is an unmaintained 13-year-old Windows binary that typically listens on HTTP ports other than port 80 and respond to HTTP requests with an HTTP-like response, starting with "ICY 200 OK".  These responses were previously detected as HTTP/0.9, and media decoders are flexible enough to handle those responses, even with the extra stuff at the start.  Newer Shoutcast servers from other vendors apparently have some issues that make users reluctant to upgrade.  Shoutcast servers are typically run by individuals and then advertised on aggregation sites, so there aren't just a couple sites to convince to upgrade.

I propose Chrome be modified to only allow HTTP/0.9 responses over ports other than 80 when the response starts with "ICY".

Interoperability and Compatibility Risk

The main problem is this makes Shoutcast a de facto web standard, and we'd basically never be able to remove support for it. This is quite unfortunate and I'd rather not do it, but unless we work in concert with other browser vendors to get rid of HTTP/0.9 support, at least on ports other than 80, I think this is the best option for our users, given its widespread use.

Other browsers:

FireFox already has explicit handling of Shoutcast responses (And treats them as HTTP/1.x responses, parsing headers as HTTP headers, which is not what I'm proposing we do). See https://bugzilla.mozilla.org/show_bug.cgi?id=869725

Edge:  No explicit Shoutcast support, but it does still support HTTP/0.9 on ports other than 80.

Safari removed support for HTTP/0.9 over non-standard ports and is not, to the extent of my knowledge, going back on that.

Ongoing technical constraints

HTTP/0.9 support doesn't require much code, and I don't think we'll be able to remove it in the foreseeable future, so the amount of code for this is negligible.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

The current bug is https://crbug.com/669800 (Which is more of a "You broke shoutcast" bug. Does this warrant another bug?)

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5703452101443584

Requesting approval to ship?

Yes

[Jochen Eisinger]

lgtm1

[Chris Harrelson]

LGTM2

lgtm1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Eric Mill]

> This is quite unfortunate and I'd rather not do it, but unless we work in concert with other browser vendors to get rid of HTTP/0.9 support, at least on ports other than 80...

Has there been any attempt to do that?

-- Eric

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAOMQ%2Bw907-HfrFzjYYpvXHKgcGkdF9Gr73MAKFWS7RCWpsReGQ%40mail.gmail.com.

--

konklone.com | @konklone

[Matt Menke]

Not to the extent of my knowledge.

[Boris Zbarsky]

On 1/20/17 1:08 PM, 'Matt Menke' via blink-dev wrote:
> FireFox already has explicit handling of Shoutcast responses (And treats
> them as HTTP/1.x responses, parsing headers as HTTP headers, which is
> not what I'm proposing we do). See
> https://bugzilla.mozilla.org/show_bug.cgi?id=869725

> <https://bugzilla.mozilla.org/show_bug.cgi?id=869725>

Note that per discussion in that bug the "parse the headers" bit is
needed because otherwise Firefox forces HTTP/0.9 responses on
non-default ports to be treated as text/plain in general, to avoid XSS
problems. We've done that since
https://bugzilla.mozilla.org/show_bug.cgi?id=667907 was fixed in 2010 or
so... I assume this is also the problem you're trying to solve, right?

It really would be a good idea if we (browser vendors) could all
coordinated how we handle this stuff instead of each solving it in a
different way.

-Boris

[Rick Byers]

LGTM3 - thanks for addressing the web compat issues here Matt.

+1 to Boris's suggestion that we talk with the Mozilla folks to see if we can converge our behaviors.  But since we've got a lot of upset users who are impacted now by our change in Chrome 55, I don't think that should block your plans.

Rick

[Matthew Menke]

No, it's not related to that, actually.  We want to remove HTTP/0.9 support on ports other than 80 because of https://crbug.com/600352 (Safari did the same thing).  We currently do full mime sniffing on HTTP/0.9 responses, I believe.

[Michael[tm] Smith]

Boris Zbarsky <bzba...@mit.edu>, 2017-01-20 16:20 -0500:

https://wiki.whatwg.org/wiki/HTTP is a page at the WHATWG Wiki for tracking
discrepancies between browsers and the HTTP specs. I’ve gone ahead and added
https://wiki.whatwg.org/wiki/HTTP#HTTP_0.9_.28and_Legacy_Shoutcast_support.29
there for this.

—Mike

--
Michael[tm] Smith https://sideshowbarker.net/

[Rick Byers]

Oh that's perfect, I had no idea that existed.  Thanks Mike!

It's sad to hear it's necessary, but glad we've got something.  Perhaps we should even make an attempt at expanding that list into a rough monkey-patch spec like the compat spec does in other areas of spec-fiction?

[Michael[tm] Smith]

Rick Byers <rby...@chromium.org>, 2017-01-21 10:17 -0500:

> On Sat, Jan 21, 2017 at 8:02 AM, Michael[tm] Smith <mi...@w3.org> wrote:

> >...

> > https://wiki.whatwg.org/wiki/HTTP is a page at the WHATWG Wiki for
> > tracking discrepancies between browsers and the HTTP specs. I’ve gone
> > ahead and added
> > https://wiki.whatwg.org/wiki/HTTP#HTTP_0.9_.28and_Legacy_ Shoutcast_support.29
> > there for this.
>
> Oh that's perfect, I had no idea that existed. Thanks Mike!
>
> It's sad to hear it's necessary, but glad we've got something. Perhaps we
> should even make an attempt at expanding that list into a rough

> monkey-patch spec like the compat spec <https://compat.spec.whatwg.org>

> does in other areas of spec-fiction?

Yes, would be great to have an actual spec. I can’t volunteer to drive it
but can help otherwise if somebody steps forward who could (especially
would be good to have an implementor who works on network code).