Edit

Page

Page title:

Page body:

[51] [CITE@en[HTTP - WHATWG Wiki]]
([TIME[2017-01-21 22:03:05 +09:00]])
<https://wiki.whatwg.org/wiki/HTTP#HTTP_0.9_.28and_Legacy_Shoutcast_support.29>

[FIG(quote)[
[FIGCAPTION[
[53] [CITE[Intent to implement and Ship: Shoutcast support - Google グループ]]
([TIME[2017-01-22 13:06:22 +09:00]])
<https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/qS63pYso4P0/FP6xymqNAwAJ>
]FIGCAPTION]

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

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

]FIG]

[1] [CITE@en[869725 – support shoutcast streams]]
([TIME[2017-01-22 13:21:46 +09:00]])
<https://bugzilla.mozilla.org/show_bug.cgi?id=869725>

[2] [CITE[android - Unexpected status line: ICY 200 OK for URL openStream() method? - Stack Overflow]]
([TIME[2017-01-22 13:38:33 +09:00]])
<http://stackoverflow.com/questions/21812483/unexpected-status-line-icy-200-ok-for-url-openstream-method>

[FIG(quote)[
[FIGCAPTION[
[3] [CITE[ICY]]
([TIME[2017-01-22 13:39:25 +09:00]])
<https://cast.readme.io/docs/icy>
]FIGCAPTION]

> The ICY name can both mean the source and client protocol. Here we assume it means the client protocol. ICY is built on HTTP but early versions might report ICY instead of HTTP. This is now deprecated and should not be used as it might break HTML5 compatibility.

]FIG]

[4] [CITE[SmackFu: Shoutcast Metadata Protocol]]
([TIME[2017-01-22 13:40:00 +09:00]])
<http://www.smackfu.com/stuff/programming/shoutcast.html>

[5] [CITE@en-US[ICY Protocol – found.devsite.pl]]
([TIME[2017-01-22 13:49:52 +09:00]])
<http://found.devsite.pl/?p=27>

[FIG(quote)[
[FIGCAPTION[
[6] [CITE@en[FFmpeg Protocols Documentation]]
([TIME[2017-01-22 02:22:36 +09:00]])
<https://ffmpeg.org/ffmpeg-protocols.html#http>
]FIGCAPTION]

> icy
> If set to 1 request ICY (SHOUTcast) metadata from the server. If the server supports this, the metadata has to be retrieved by the application by reading the icy_metadata_headers and icy_metadata_packet options. The default is 1.
> icy_metadata_headers
> If the server supports ICY metadata, this contains the ICY-specific HTTP reply headers, separated by newline characters.
> icy_metadata_packet
> If the server supports ICY metadata, and icy was set to 1, this contains the last non-empty metadata packet sent by the server. It should be polled in regular intervals by applications interested in mid-stream metadata updates.
>

]FIG]

[FIG(quote)[
[FIGCAPTION[
[7] [CITE[CURLOPT_HTTP200ALIASES]]
([TIME[2017-01-14 00:45:06 +09:00]])
<https://curl.haxx.se/libcurl/c/CURLOPT_HTTP200ALIASES.html>
]FIGCAPTION]

> Pass a pointer to a linked list of aliases to be treated as valid HTTP 200 responses. Some servers respond with a custom header response line. For example, SHOUTcast servers respond with "ICY 200 OK". Also some very old Icecast 1.3.x servers will respond like that for certain user agent headers or in absence of such. By including this string in your list of aliases, the response will be treated as a valid HTTP header line such as "HTTP/1.0 200 OK".

]FIG]

[8] [CITE@en[requests is not happy with a shoutcast stream · Issue #2322 · kennethreitz/requests]]
([TIME[2017-01-22 14:36:16 +09:00]])
<https://github.com/kennethreitz/requests/issues/2322>

[9] [CITE@en[Problem with ICY 200 OK response · Issue #95 · naudio/NAudio]]
([TIME[2017-01-22 14:37:27 +09:00]])
<https://github.com/naudio/NAudio/issues/95>

[10] [CITE@en[104789 - Add support for SHOUTcast servers that return ICY 200 responses instead of HTTP - chromium - Monorail]]
([TIME[2017-01-22 14:38:08 +09:00]])
<https://bugs.chromium.org/p/chromium/issues/detail?id=104789>

[11] [CITE[Plack::Middleware::Icecast::StatusUpdate というのを書きました - NaN days - subtech]]
([TIME[2017-01-22 14:39:55 +09:00]])
<https://subtech.g.hatena.ne.jp/motemen/20100523/1274549126>

[12] [CITE[Shoutcast Stream not working in Chrome - Google グループ]]
([TIME[2017-01-22 14:41:24 +09:00]])
<https://groups.google.com/forum/#!topic/jplayer/wfPj-3e02O8>

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)