Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2020-10-15T13:51:17Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/738Errorcode when client wants to connect to "full" mountpoint should be changed2020-10-15T13:51:17ZrobeErrorcode when client wants to connect to "full" mountpoint should be changedHi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same error...Hi,
the errorcode that clients receive when they want to connect to a mountpoint which has reached its maxlisteners limit should be changed from the current "404 File Not Found" to something more meaningful, since this is the same errorcode that gets returned when the requested mountpoint doesn't exist.
A possible solution to this would be returning 403 with a customized reason phrase like "Mountpoint full" (or similar) in the header (since this is the only thing (if any) that gets forwarded to the user with most clients). The HTTP 1.1 RFC (#2616) allows this:
6.1.1:
[..]
The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol.
[..]Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1860[PATCH] Send credentials when doing master-relay2018-11-10T13:05:22Zcato[PATCH] Send credentials when doing master-relayWhen using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentia...When using a configuration with a hidden master and some relays using master-relay it should be possible to enable password protection on streams in the master icecast. Therefore it is necessary for the relaying-icecast to send credentials to the master-icecast. The natural choice would be to send the `<master-username>` and `<master-password>`.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1877Binding to IPv6 broken on win32 Icecast?2020-02-14T13:01:05ZThomas B. RückerBinding to IPv6 broken on win32 Icecast?This was reported first by mharris on IRC.
He's running WinXP SP3.
I then tried to reproduce it on Win7 64bit with both Icecast 2.3.2 and Icecast 2.3.2-kh33.
On the official build icecast2console.exe will fail to start when given an IPv6...This was reported first by mharris on IRC.
He's running WinXP SP3.
I then tried to reproduce it on Win7 64bit with both Icecast 2.3.2 and Icecast 2.3.2-kh33.
On the official build icecast2console.exe will fail to start when given an IPv6 bind-address (both :: and [::] and also explicit address in both forms). On the KH build it starts but doesn't bind to a port.
I didn't manage to get useful logs out on the official build.
The KH build though complains in the form:
EROR connection/connection_setup_sockets Could not create listener socket on port 8000 bind ::
PS: Unless there is an instant fix, this will miss the window for 2.3.3.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/1959Icecast to accept custom REMOTE IP headers for reverse proxy compatibility.2022-11-10T18:58:16ZYahavIcecast to accept custom REMOTE IP headers for reverse proxy compatibility.Would be nice to be able to set a custom header name in the config in which Icecast will check for the remote ip address.
(<IP-HEADER>X-Forwarded-For</IP-HEADER>)
will be useful with reverse proxying and such.
(Implemented in KH-2.3.3-kh...Would be nice to be able to set a custom header name in the config in which Icecast will check for the remote ip address.
(<IP-HEADER>X-Forwarded-For</IP-HEADER>)
will be useful with reverse proxying and such.
(Implemented in KH-2.3.3-kh1: http://karlheyes.github.io ) Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2008A hang in send_ogg_headers()2020-02-14T13:10:21ZartemA hang in send_ogg_headers()I've recently had the following hang of icecast2 server. Not sure if it's the first time, but it's pretty rare anyway, so i can't reliably reproduce, but this time i managed to debug a little.
I'm running on ubuntu 12.04 vps with defaul...I've recently had the following hang of icecast2 server. Not sure if it's the first time, but it's pretty rare anyway, so i can't reliably reproduce, but this time i managed to debug a little.
I'm running on ubuntu 12.04 vps with default package (icecast2-2.3.2-9ubuntu1), didn't try to pull the latest svn version yet.
```
$ tail /var/log/icecast2
...
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
[2014-02-16 08:27:40] DBUG client/client_send_bytes Client connection died
...
```
```
$ strace -p `pidof icecast2` -f 2>&1 | grep send
...
[pid 26113] send(14, 0x5ff8e559, 2406954578, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e558, 2406954579, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e557, 2406954580, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e556, 2406954581, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e555, 2406954582, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e554, 2406954583, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e553, 2406954584, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e552, 2406954585, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e551, 2406954586, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e550, 2406954587, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54f, 2406954588, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54e, 2406954589, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54d, 2406954590, 0) = -1 EPIPE (Broken pipe)
[pid 26113] send(14, 0x5ff8e54c, 2406954591, 0) = -1 EPIPE (Broken pipe)
...
```
You may notice how buffer address decreases by 1 and buffer length increases by 1 on every line; no other `send()` calls happen, so i could easily backtrace them:
```
$ gdb -p `pidof icecast`
...
Breakpoint 1, 0xb7461e40 in send () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
(gdb) bt
#0 0xb7461e40 in send () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
#1 0x08067c40 in sock_write_bytes (sock=14, buff=0x5f08fe9d, len=2422676750) at sock.c:360
#2 0x0804f9aa in connection_send (con=0x9748ac8, buf=0x5f08fe9d, len=2422676750) at connection.c:303
#3 0x08058d20 in client_send_bytes (client=0x9740a38, buf=0x5f08fe9d, len=2422676750) at client.c:202
#4 0x0805e6c2 in send_ogg_headers (headers=0xb666e848, client=0x9740a38) at format_ogg.c:500
#5 write_buf_to_client (client=0x9740a38) at format_ogg.c:534
#6 0x08054f57 in send_to_listener (deletion_expected=0, client=0x9740a38, source=0xb647c7d8) at source.c:544
#7 source_main (source=0xb647c7d8) at source.c:716
#8 0x0805564f in source_client_thread (arg=0xb647c7d8) at source.c:1225
#9 0x08068b2f in _start_routine (arg=0xb6674970) at thread.c:655
#10 0xb745ad4c in start_thread () from /lib/i386-linux-gnu/tls/i686/nosegneg/libpthread.so.0
#11 0xb7398ace in clone () from /lib/i386-linux-gnu/tls/i686/nosegneg/libc.so.6
...
```
Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2061Investigate: Relay not recovering2021-10-30T09:42:21ZMarvin ScholzInvestigate: Relay not recoveringAs reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source...As reported in IRC by AAA_awright, a relay doesn't seem to reconnect if the source mount times out, see attached log. This happened with Icecast 2.3.3, we should check that this does not happen with 2.4.0, it should recover if the source mountpoint is back.
> I had a problem where one of my relays has stopped relaying, and I couldn't bring it back up without a restart. It's only playing the fallback. It reloads the relay data from the master server, but ignores it somehow. It honors me changing the refresh interval in the config file and everything.
> The event seems to happen at 2014-10-12 05:41:13, and it never recovers or mentions the stream again
> If it helps, I don't see another "checking master stream list" for another 15 minutes: [2014-10-12 06:09:20] DBUG slave/_slave_thread checking master stream list
> Before 05:41, it occurs reliably every 120 secondsThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2107Provide a way for YP Dirs to check streams2020-10-15T11:58:06ZMarvin ScholzProvide a way for YP Dirs to check streams>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should b...>directory server GUID checks
>
>directory server does GET /GUID-asldjfasldfjalsdkfjasldkfj HTTP/1.0
>and either gets a 404 if it's wrong, or a 200 if it's correct.
As suggested already in early drafts of the YP Protocol, there should be a proper way to check if a stream is still reachable and running (and even maybe fetch updated metadata while at it).
This could be solved by implementing HTTP 1.1 HEAD and setting some headers, or as the TODO suggest, making a dedicated endpoint for it.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2112Locks on avl client_trees needed?2020-10-11T11:18:30ZMarvin ScholzLocks on avl client_trees needed?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?>do we need to use locks on the avl client_trees in source.c and fserv.c?
Found in TODO, still relevant?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2150check if we need to forward port a possible win32 security fix from kh2020-10-15T11:20:19ZThomas B. Rückercheck if we need to forward port a possible win32 security fix from khhttps://github.com/karlheyes/icecast-kh/commit/b50c6374234154ad94b3c3a3e76545601e997739
```
do not use SO_REUSEADDR on windows, breaks the reload handling
MS defined SO_REUSEADDR differently to BSD and linux and have allowed some stupi...https://github.com/karlheyes/icecast-kh/commit/b50c6374234154ad94b3c3a3e76545601e997739
```
do not use SO_REUSEADDR on windows, breaks the reload handling
MS defined SO_REUSEADDR differently to BSD and linux and have allowed some stupid
security issue on it for port stealing. They messed it up, added another option
which doesn't help here and advise not using this option. Luckily the default
behaviour is acceptable. I've also avoided the abort case which should not trigger
but if it does, it reports an error and skips the rest.
```
Needs checking against Windows documentation. There might be some differences in how kh and we use things.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2158No metadata for the listenerer when sourcing with Mixxx on Windows2020-02-14T12:59:17ZSebastianNo metadata for the listenerer when sourcing with Mixxx on Windows2.4.99.1 aka 2.5 beta1 on windows with Mixxx as source client.
Unfortunately the metadata (title and artist) is not visible on iTunes anymore.
In 2.4.1 this was no problem. I tried to use the charset UTF-8 in Mixxx and in Icecast but i...2.4.99.1 aka 2.5 beta1 on windows with Mixxx as source client.
Unfortunately the metadata (title and artist) is not visible on iTunes anymore.
In 2.4.1 this was no problem. I tried to use the charset UTF-8 in Mixxx and in Icecast but it didn't work either.
Maybe someone could have a look at it.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2188Fowarding of headers to authentication system not working2019-06-26T17:17:19ZSebastianFowarding of headers to authentication system not workingHey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<...Hey everyone,
i tried to forward some cookies or other headers to my authentication sytem. Unfortunately this does not work. The doc says the headers would be part of a POST but they don't appear. Can anyone confirm that?
```
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
```
```
<mount>
<mount-name>/example.ogg</mount-name>
<authentication type="url">
<option name="mount_add" value="http://auth.example.org/stream_start.php"/>
<option name="mount_remove" value="http://auth.example.org/stream_end.php"/>
<option name="listener_add" value="http://auth.example.org/listener_joined.php"/>
<option name="listener_remove" value="http://auth.example.org/listener_left.php"/>
<option name="username" value="user"/>
<option name="password" value="pass"/>
<option name="auth_header" value="icecast-auth-user: 1"/>
<option name="timelimit_header" value="icecast-auth-timelimit:"/>
<option name="headers" value="x-pragma,x-token"/>
<option name="header_prefix" value="ClientHeader."/>
<option name="stream_auth" value="http://auth.example.org/source.php"/>
</authentication>
</mount>
```
Best Regards
SebastianThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2200icecast stats addition (per mount cumulative listener counter)2018-07-07T09:19:54Zddndukkicecast stats addition (per mount cumulative listener counter)Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
s...Currently in icecast statistics available counter like 'hit count' only globally in <icecasts/> node. I mean 'listener_connections'
It will be very good to add per-mount counter like that (accumulated counter of listener connections).
so it appears in /icecasts/source/ node with name like 'listener_connections'.
<icestats>
<listener_connections>3</listener_connections>
<source mount="/test">
<listener_connections>2</listener_connections>
...
</source>
</icecasts>
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2225Make listen backlog customizable2018-09-28T14:05:00ZMarvin ScholzMake listen backlog customizableExcerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instanc...Excerpt from a mail we got on the list:
On 02/19/2015 03:07 PM, Stephan Leemburg wrote:
> I am working for the NPO, the Dutch Public Broadcasting agency.
>
> We do a lot of icecast streaming. We run at least 20 icecast server
> instances on our media streaming cluster. [...]
>
> We ran into an issue that clients which where connecting to our streams
> seemed to be 'hanging' on the connection setup frequently. The client
> 'thinks' it is connected, but no data.
>
> People suggested that it probably had to do with the poll() call. So, I
> looked into that.
>
> I found that the issue was actually caused by the very low listen
> backlog (5).
> On our clusters, we typically set this to 8192. Yes it is high, but we
> do a _lot_ of streaming and host very high volume websites.
Attached are the submitted patches for 2.4, 2.5 and 2.3.3
Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2270If relay with on-demand's source goes down, on_demand is no longer reported i...2020-10-11T11:40:22ZdonicsIf relay with on-demand's source goes down, on_demand is no longer reported in status-json.xsl when source returns.If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the so...If you set up a relay with on-demand=1 in the relay settings, status-json.xsl will report the setting as on_demand=1. This is great, and helps with calculating total viewers on a source.
One thing I have found, though, is that if the source goes down, the relay will stop reporting on_demand status-json.xsl. This continues even when the source comes back up. The only way to get on_demand reporting back is to restart the service.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2302Password extends into headers with BUTT shoutcast compatible source2020-02-14T13:26:12ZGary TunstallPassword extends into headers with BUTT shoutcast compatible sourceHi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup a...Hi, I've found a bug in 2.4.3 (which if I understand correctly is the same as 2.4.2 for Linux).
Its a fairly minor one and is in part caused by the Source.
If you use BUTT (https://sourceforge.net/projects/butt/) to broadcast and setup an Icecast connection it works find. However if you set it up as a shoutcast connection and send to a shoutcast compatible port on icecast it fails.
Now the obvious question is why we'd use the "old" way of doing things. The answer is we are moving from shoutcast to icecast and a lot of our broadcasters still have the shoutcast settings and I'll like it to "just work" for them.
The problem is BUTT mixes its line endings, after the password there is just a /n but in the header lines it uses /r/n
In _handle_shoutcast_compatible in connection.c there is some code
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\r\r\n");
if (ptr)
headers = ptr+3;
else
{
ptr = strstr (client->refbuf->data, "\r\n");
if (ptr)
headers = ptr+2;
else
{
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
headers = ptr+1;
}
}
```
Which unfortunately matches on the \r\n on the header, and misses the \n on the end of the password. So it uses the password a \n and the first line of the headers as the password, which fails and it rejects the connection.
For my purposes I've fix it by changing the code to:
```
/* Get rid of trailing \r\n or \n after password */
ptr = strstr (client->refbuf->data, "\n");
if (ptr)
{
headers = ptr+1;
while ( ( ptr > client->refbuf->data ) && ( ptr[-1]=='\r' ) )
{
ptr--;
}
}
```
So it finds the first \n and backtracks to remove any \r's
Obviously this is an edge case, in general people using BUTT will use icecast native connections, and most source client don't use mixed line endings. But I think my fixed version is probably more efficient on average anyway, so I think it should be safe to add.
I was going to try and submit a patch, but it looks like the code has moved on since the last version released, though even that didn't seem to use the latest changes at the time. So I'm not sure what is happening in that area. I'll leave this here and if its of any use then please include it. If you can shed more light on the evolution of the file and its worth it I can clone the latest version and test and if necessary make a patch for it.
Regards
GaryThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2335`<no-mount>` (`<mount>`'s child) is noop in 2.5.x2021-04-14T10:51:43ZPhilipp Schafft`<no-mount>` (`<mount>`'s child) is noop in 2.5.xThe tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.The tag `<no-mount>` (which is a child element of `<mount>`) doesn't seem to do anything in 2.5.x. However according to source code comment it should disallow direct access to the mount.
This may interact with the ACL system.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2364https stream play 1 second and stop2019-05-13T11:56:47ZMichelhttps stream play 1 second and stopWe have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bul...We have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bult a new RPM for Icecast 2.4.4 on the last version of CentOS Linux release 7.6.1810 (Core) include the openssl update. (OpenSSL 1.0.2k-fips 26 Jan 2017)
I run it on the debug mode (4). Tonight i have the same problem on https on mount /live a mp3 192k stream. It play 2 seconds and stop. (when i try to use include .m3u so https.../live.m3u he go to http in the software player)
Here is the debug error log. I hope you find them useful (see /live) :
```
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52301)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (16)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52302)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_read (18373627904)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_sent (82768157916)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50480)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (1)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (12)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listener_connections (11687)
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source max on /live is 400 (cur 0)
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source Added client to /live
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (11)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (0)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50481)
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
```
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2365Discussion on the handling of portless Host:-headers2020-10-11T15:59:37ZPhilipp SchafftDiscussion on the handling of portless Host:-headersKarl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port eve...Karl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port even if non-default ports are used. When this header is used this results in invalid playlists to be generated. (Other (future) uses such as vhosting may also be affected).
foobar2000 seems to have fixed this. This was the result of a quick test with @laama. Thanks to him.
Winamp 5.53 1898 Beta from 2008 as well as Winamp 5.8 as downloaded today are still affected.
The following solution and workarounds come to mind:
* Nullsoft fixes their software. (Judge yourself if this is going to happen.) This is the only solution. It is the only correct way to do this.
* Keep ignoring Host:-headers that do not include a port. This may break legitimate clients.
* Try to match Host:-headers against listen sockets. This may break vhosting.
* Implement a way to list valid vhosts and set default vhosts per listen socket.
* Ignore Host:-headers without a port but implement a per listen socket default vhost setting.
Note that we can not accept/reject Host:-headers without port based on if we listen on a default port socket or not without type="virtual" listen sockets. This will otherwise break all kinds of redirects.
This ticket is mostly for discussion.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2373Incorrect status code2020-10-15T16:20:55ZPhilipp SchafftIncorrect status codeIn case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.In case of 'mountpoint will not accept URL updates' and other admin errors Icecast might send incorrect HTTP status headers.
This happens at least in branch ph3-mdoule-client-tests.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2375Cross-Origin Preflight OPTIONS sends 4012023-03-06T15:12:48ZBradley HiltonCross-Origin Preflight OPTIONS sends 401When a browser does a cross-origin request with preflight, icecast server fails with `401 Authentication Required` when there is no way to include the user credentials.
https://www.w3.org/TR/cors/#preflight-requestWhen a browser does a cross-origin request with preflight, icecast server fails with `401 Authentication Required` when there is no way to include the user credentials.
https://www.w3.org/TR/cors/#preflight-request