Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2020-10-02T13:37:21Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2343Add API endpoint to sets a mark in the log files2020-10-02T13:37:21ZPhilipp SchafftAdd API endpoint to sets a mark in the log filesThis is for debugging. The endpoint would write marker into the log file. This can be helpful to find things in busy logfiles more easily.
The marker could optionally include a user provided string and username+role of the user who requ...This is for debugging. The endpoint would write marker into the log file. This can be helpful to find things in busy logfiles more easily.
The marker could optionally include a user provided string and username+role of the user who requested the mark.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2342Security vulnerability: buffer overflow in URL authentication allows remote c...2018-11-05T08:00:08ZNick RolfeSecurity vulnerability: buffer overflow in URL authentication allows remote code executionHello,
I would like to report a security vulnerability in the Icecast server.
## The bug
`url_add_client` in `auth_url.c` contains this call inside a loop:
```
post_offset += snprintf(post + post_offset,
sizeo...Hello,
I would like to report a security vulnerability in the Icecast server.
## The bug
`url_add_client` in `auth_url.c` contains this call inside a loop:
```
post_offset += snprintf(post + post_offset,
sizeof(post) - post_offset,
"&%s%s=%s",
url->prefix_headers ? url->prefix_headers : "",
cur_header, header_valesc);
```
If the string to be written is longer than `sizeof(post) - post_offset`, `snprintf` will truncate the string, but will return *the number of bytes it would have written if the buffer were large enough*. This means that `post_offset` is incremented to be larger than `sizeof(post)`, and any subsequent iteration of the loop will write beyond the end of the buffer.
## Proof of concept
I configured a mount using URL authentication that forwards two headers:
```
<mount type="normal">
<mount-name>/auth_url.ogg</mount-name>
<authentication type="url">
<option name="headers" value="x-foo,x-bar"/>
...
</authentication>
</mount>
```
My Icecast server was running on localhost, port 8000, and then I ran the following Bash script:
```
foo=$(python -c "print('a' * 3950)")
bar=123456789123456789
curl -H "x-foo: $foo" -H "x-bar: $bar" http://localhost:8000/auth_url.ogg
```
The `x-foo` header was truncated, but it caused `postoffset` to be incremented beyond the size of the buffer, as described above. The subsequent handling of the `x-bar` header overwrote other stack contents, causing my Icecast server to crash:
```
*** stack smashing detected ***: <unknown> terminated
Aborted (core dumped)
```
By controlling the length of the `x-foo` header, and the contents of the `x-bar` header, it seems likely that remote code execution would be possible.
## Related bug
Our automated analysis highlighted this bug, and another similar misuse of `snprintf` in `format_prepare_headers` in `format.c`, but I did not investigate whether that one would be exploitable.
Those analysis results are visible here: https://lgtm.com/projects/g/xiph/Icecast-Server/alerts/?mode=tree&ruleFocus=1505913226124
## Disclosure
Please let me know when you have fixed the vulnerability, so that we can coordinate our disclosure with yours. For reference, here is a link to our vulnerability disclosure policy: https://lgtm.com/security
Thanks!
--Nick Rolfe, Semmle Security Research TeamThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2341Improvements to auth_result and it's usage (more and better results)2018-10-27T17:00:55ZPhilipp SchafftImprovements to auth_result and it's usage (more and better results)The enum auth_result currently implements:
* "undefined": The code comments this as "XXX: ???",
* "ok": client passed the auth backend successfully,
* "failed": client did not pass (because of invalid credentials or because of backend ma...The enum auth_result currently implements:
* "undefined": The code comments this as "XXX: ???",
* "ok": client passed the auth backend successfully,
* "failed": client did not pass (because of invalid credentials or because of backend malfunction),
* "released": used internally for on-disconnect handlers,
* "forbidden": unused,
* "no match": client is unknown to this backend,
* "user added", "user exists", "user deleted": used by management functions.
I suggest to change this the following way:
* Make "forbidden" settable by auth backends for permanent no-passes. This would terminate any auth retry. It could be useful for when the client *IS* identified (credentials match) but the backend forbids access (user has been banned, access has been terminated, ...).
* Add "backend failed" that indicates a problem with the backend, not the credentials. Such failures would include non-responsive backend servers (e.g. with URL auth) or misconfiguration (e.g. invalid file for htpasswd auth).
* Add a "user modified" for management functions as the current set does not allow updating users (only delete-then-add-again patterns).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2340authentication subsystem should allow the user to send a custom error2018-10-16T06:39:31ZPhilipp Schafftauthentication subsystem should allow the user to send a custom errorThe authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="a...The authentication subsystem should to send a custom error in case of negative match (deny).
The error to return should be selected by it's report XML UUID.
Example config would look like this:
```xml
<authentication>
<role type="anonymous" deny-all="*" reject-with="f955b6c6-aaca-4734-aacc-67d86bf83c3b" />
</authentication>
```
This would also be in-line with `AUTH_ALTER_SEND_ERROR`.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2339After logrotate Icecast not using new access.log and error.log files2018-09-28T13:24:06ZDoug TinklenbergAfter logrotate Icecast not using new access.log and error.log filesThe logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.p...The logrotate postrotate command is this for Icecast: */bin/kill -HUP `cat /var/run/icecast/icecast.pid 2>/dev/null` 2> /dev/null || true*
The Icecast installation doesn't create the icecast folder in /var/run so there is no icecast.pid file.
So what's happening is that after a logrotate the Icecast service continues to use the access.log-date file rather then the new access.log file that is created during the logrotate. The only way to get it to use the new log files is to restart the icecast service.
Why is the logrotate command trying to kill a pid file that doesn't exist and is there another postrotate command that should be used instead.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2338SSL support on Ubuntu 18.042019-01-26T10:42:02ZSimon CechacekSSL support on Ubuntu 18.04Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get I...Hello,
I am trying to run Icecast on my Ubuntu 18.04 with SSL enabled. When I add the official repository to the system and then use `apt-get install icecast2`, everything will work except that when I will turn the SSL on, I will `get INFO connection/get_ssl_certificate No SSL capability` message, I pre-installed OpenSSL befory icecast installation."
any Idea how to fix this?
I also tried to build by Icecast from the source with the custom path ovf openssl pramater enabled (just put there the default openssl path) and it worked, but this icecast is installed as an app and not as a service, so don't how to reload config without dropping listeners (i need to add relays withour restarting the server as it will server as a proxy).
Thanks for all your time!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2337RFE: Please add a possibility for a relay to transcode the stream2020-11-09T19:35:07Zpetr tomasekRFE: Please add a possibility for a relay to transcode the streamWith Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
...With Icecast I'm missing the possibility to create transcoding relays in a simple manner. I'd suggest there could be a new configuration option which would specify a binary/script which the stream would go through.
Something like this:
```xml
<relay>
<server>127.0.0.1</server>
<port>8001</port>
<mount>/example.ogg</mount>
<local-mount>/different.ogg</local-mount>
<on-demand>1</on-demand>
<retry-delay>30</retry-delay>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
<transcode-bin>/usr/local/bin/transcodestreamXYZ</transcode-bin>
</relay>
```
Thanks!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2336Icecast 2.5.x relays not working2018-07-26T10:19:39ZPhilipp SchafftIcecast 2.5.x relays not workingRelays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Relays do not work.
In master since 4a10d7e74422b7c3a31d4677e12f5aa3ce52474f.
client->request_body_length is not correctly set up leading to body read limit (client->request_body_length=0). client generally may not be in correct state.Philipp SchafftPhilipp Schaffthttps://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/2334Icecast 2.5 Beta binaries for Windows (Request)2022-03-21T09:31:42ZRoger HågensenIcecast 2.5 Beta binaries for Windows (Request)The last binary for Windows was beta1 in 2015. Sure I could setup a build environment, but I doubt most Windows users of Icecast build their own Icecast server (myself included).
A windows binary was also desired by Rick Keniuk on the m...The last binary for Windows was beta1 in 2015. Sure I could setup a build environment, but I doubt most Windows users of Icecast build their own Icecast server (myself included).
A windows binary was also desired by Rick Keniuk on the mailing list.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2333Make playlist generation consistent2020-10-11T16:28:01ZMarvin ScholzMake playlist generation consistentCurrently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!Currently all playlist formats are generated using XSLT, but m3u is generated in C code. This should be done consistent, either all as XSLT or all in C code.
Opinions which way will be better welcome!https://gitlab.xiph.org/xiph/icecast-server/-/issues/2332Change playlist_new default from 4 to 102018-07-09T11:30:46ZRoger HågensenChange playlist_new default from 4 to 10Change `src->history = playlist_new(4 /* DOCUMENT: default is max_tracks=4. */);`
To `src->history = playlist_new(10 /* DOCUMENT: default is max_tracks=10. */);`
Other servers like Shoutcast has 10, various players and webplayers has 10...Change `src->history = playlist_new(4 /* DOCUMENT: default is max_tracks=4. */);`
To `src->history = playlist_new(10 /* DOCUMENT: default is max_tracks=10. */);`
Other servers like Shoutcast has 10, various players and webplayers has 10.
Most service providers do minimal configuration changes so a default of 10 is beneficial as that is most likely what users want anyway.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2331Add history to status-json.xsl2018-07-07T19:19:02ZRoger HågensenAdd history to status-json.xslSince history is now implemented in https://gitlab.xiph.org/xiph/icecast-server/commit/3dd8bdbf40e0988d331724f2a2b5c2bf774584b4 it is hopefully trivial to add this to status-json.xsl as well?Since history is now implemented in https://gitlab.xiph.org/xiph/icecast-server/commit/3dd8bdbf40e0988d331724f2a2b5c2bf774584b4 it is hopefully trivial to add this to status-json.xsl as well?https://gitlab.xiph.org/xiph/icecast-server/-/issues/2330Segmentation Fault in auth.c2018-04-18T00:14:17ZMarvin ScholzSegmentation Fault in auth.cReported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server...Reported by hopejr on Github:
There is a seg fault on unlocking the thread on line 189 of auth.c in the function auth_release() under certain circumstances:
1. Configure a mount point with a fallback that is a relay from another server that is actually running (the stream must have parameter hidden=0 and fallback-override=1)
2. Start Icecast
3. Stream to Icecast, and then stop the stream after an arbitrary amount of time
4. Load the status page in the browser
At that point, there will be a seg fault as described above. It does not happen when the mount point is hidden for some reason.
Test system is running Debian 9.3. Icecast version 2.4.99.2https://gitlab.xiph.org/xiph/icecast-server/-/issues/2329Config file using url auth causes SIGILL on SIGHUP2018-09-28T13:17:37ZMarvin ScholzConfig file using url auth causes SIGILL on SIGHUPReported by spr0cketeer on 21 Nov 2017 (Github):
Hello icecasters!
Using icecast master cd0a3f9
getting a SIGILL when sending a SIGHUP to reread config file.
Only happens when using url auth:
```
<mount> ...Reported by spr0cketeer on 21 Nov 2017 (Github):
Hello icecasters!
Using icecast master cd0a3f9
getting a SIGILL when sending a SIGHUP to reread config file.
Only happens when using url auth:
```
<mount>
<mount-name>/test</mount-name>
<authentication type="url">
<option name="listener_add" value="http://example.com/auth"/>
</authentication>
</mount>
```
Server is running on haswell architecture - related: karlheyes/icecast-kh#157
```
Thread 1 "icecast" received signal SIGHUP, Hangup.
[2017-11-20 23:02:55] INFO sighandler/_sig_hup Caught signal 1, scheduling config re-read...
[2017-11-20 23:02:55] INFO auth_url/auth_get_url_auth URL based authentication setup
[New Thread 0x7fffeebd4700 (LWP 9495)]
[2017-11-20 23:02:55] INFO auth/auth_run_thread Authentication thread started
[2017-11-20 23:02:55] WARN CONFIG/__check_hostname Warning, <hostname> not configured, using default value "localhost". This will cause problems, e.g. this breaks YP directory listings. YP directory listing support will be disabled.
[2017-11-20 23:02:55] WARN CONFIG/_parse_root Warning, <location> not configured, using default value "Earth".
[2017-11-20 23:02:55] WARN CONFIG/_parse_root Warning, <admin> contact not configured, using default value "icemaster@localhost". This breaks YP directory listings. YP directory support will be disabled.
[2017-11-20 23:02:55] INFO auth/auth_run_thread Authentication thread shutting down
[2017-11-20 23:02:55] INFO auth_url/auth_url_clear Doing auth URL cleanup
[2017-11-20 23:02:55] INFO connection/get_tls_certificate No TLS capability on any configured ports
[Thread 0x7ffff7fba700 (LWP 8767) exited]
Thread 5 "icecast" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffeecd6700 (LWP 8770)]
__GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
38 pthread_rwlock_unlock.c: No such file or directory.
(gdb) bt
#0 __GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
#1 0x000000000042ac25 in thread_rwlock_unlock_c (rwlock=rwlock@entry=0x642800 <_locks>, line=line@entry=754, file=file@entry=0x42fe9f "cfgfile.c") at thread.c:568
#2 0x000000000040b66c in config_release_config () at cfgfile.c:754
#3 config_reread_config () at cfgfile.c:701
#4 0x0000000000411025 in _slave_thread (arg=arg@entry=0x0) at slave.c:751
#5 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#6 0x00007ffff68546ba in start_thread (arg=0x7fffeecd6700) at pthread_create.c:333
#7 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb) thread apply all bt
Thread 7 (Thread 0x7fffeebd4700 (LWP 9495)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=150000) at thread.c:626
#2 0x000000000042304a in auth_run_thread (arg=arg@entry=0x7fffd800b490) at auth.c:359
#3 0x000000000042a6cd in _start_routine (arg=0x7fffd800bce0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7fffeebd4700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 6 (Thread 0x7fffeec55700 (LWP 8771)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=150000) at thread.c:626
#2 0x0000000000421183 in event_run_thread (arg=arg@entry=0x0) at event.c:174
#3 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7fffeec55700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 5 (Thread 0x7fffeecd6700 (LWP 8770)):
#0 __GI___pthread_rwlock_unlock (rwlock=rwlock@entry=0x642800 <_locks>) at pthread_rwlock_unlock.c:38
#1 0x000000000042ac25 in thread_rwlock_unlock_c (rwlock=rwlock@entry=0x642800 <_locks>, line=line@entry=754, file=file@entry=0x42fe9f "cfgfile.c") at thread.c:568
#2 0x000000000040b66c in config_release_config () at cfgfile.c:754
#3 config_reread_config () at cfgfile.c:701
#4 0x0000000000411025 in _slave_thread (arg=arg@entry=0x0) at slave.c:751
#5 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#6 0x00007ffff68546ba in start_thread (arg=0x7fffeecd6700) at pthread_create.c:333
#7 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4 (Thread 0x7ffff7eb8700 (LWP 8769)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=200000) at thread.c:626
#2 0x0000000000428afd in yp_update_thread (arg=arg@entry=0x0) at yp.c:732
#3 0x000000000042a6cd in _start_routine (arg=0x68d2b0) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7ffff7eb8700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3 (Thread 0x7ffff7f39700 (LWP 8768)):
#0 0x00007ffff685dc1d in nanosleep () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000042ac86 in thread_sleep (len=len@entry=300000) at thread.c:626
#2 0x000000000041556e in _stats_thread (arg=arg@entry=0x0) at stats.c:737
#3 0x000000000042a6cd in _start_routine (arg=0x68f160) at thread.c:669
#4 0x00007ffff68546ba in start_thread (arg=0x7ffff7f39700) at pthread_create.c:333
#5 0x00007ffff658a3dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 1 (Thread 0x7ffff7fbc740 (LWP 8763)):
#0 0x00007ffff657e70d in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x000000000040c6ee in poll (__timeout=300, __nfds=<optimised out>, __fds=0x7fffffffa450) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 wait_for_serversock (timeout=300) at connection.c:302
#3 _accept_connection (duration=300) at connection.c:371
#4 connection_accept_loop () at connection.c:616
#5 0x000000000040685a in _server_proc () at main.c:356
#6 main (argc=<optimised out>, argv=<optimised out>) at main.c:601
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2328When configuration file is invalid, icecast hangs indefinitely2018-06-16T20:30:29ZMarcin LewandowskiWhen configuration file is invalid, icecast hangs indefinitelyI am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to chec...I am running icecast 2.4.3 on ubuntu 16.04, compiled from sources.
I have found out that if given XML config has invalid syntax, it outputs error but do not terminate the process. It is quite painful as it is not easily possible to check if service is running or not, as process exists.
```
/usr/bin/icecast -c /etc/icecast/icecast.xml
/etc/icecast/icecast.xml:1: parser error : Document is empty
FATAL: error parsing config file (/etc/icecast/icecast.xml)
XML config parsing error
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/23272.4.99.1 leaks filedescriptors?2020-02-25T08:58:43ZHugo2.4.99.1 leaks filedescriptors?Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak"....Hi,
We've upgraded some of our production icecast servers to 2.4.99.1 this morning (from 2.4.2, because of the better TLS support). 1 one the 8 upgraded servers is expierencing problems which seem to be known as a "filedescriptor leak". The server does not respond to new connections anymore, but seems to handle a lot of existing connections still fine. With netstat and lsof a lot of CLOSE_WAIT connections show up:
$ sudo lsof -np 28035 | wc -l
12895
$ sudo lsof -np 28035 | grep CLOSE_WAIT | wc -l
5973
The other 7 servers do not experience this problem (yet). The maximum amount of listeners today was about 6500 per server (on a number of channels).
Could it be that icecast is leaking filedescriptors somehow in situations that are not always triggered (since not all servers encounter this problem)?
All servers are running the same kernel; 4.1.39 and the installation is identical on all systems.
Any suggestions what could be done to debug this problem? It would be nice if we could reproduce this, but I have no clue what could cause this.
Regards,
Hugohttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2326Icecast- 2.4.3 Do not publish directory yp2017-10-05T10:40:40ZGitlab BotIcecast- 2.4.3 Do not publish directory ypI run icecast 2.4.3 with correct configuration and it does not publish in YP directory.
With the same configuration, version 2.4.1 publishes correctly in directory YPI run icecast 2.4.3 with correct configuration and it does not publish in YP directory.
With the same configuration, version 2.4.1 publishes correctly in directory YPThomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2323m3u/xspf/vclt files do not support SSL2019-07-04T20:20:25ZGitlab Botm3u/xspf/vclt files do not support SSLRegardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if ...Regardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if (host == NULL)
{
config = config_get_config();
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s:%d%s\r\n",
config->hostname, config->port,
sourceuri
);
config_release_config();
}
else
{
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s%s\r\n",
host,
sourceuri
);
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2322gzip http compression for server pages.2019-01-09T11:59:13ZRoger Hågensengzip http compression for server pages.With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity lik...With Icecast 2.4.x there is no gzip compression used for served pages.
While most served pages are not that large, gzip may be the difference between a page being served in one TCP packet vs multiple.
And then there are monstrosity like this http://relay.sonixcast.com/ that would clearly benefit from gzip.
gzip could even be applied to xml stats pages as PHP and other serverside scripting languages also support gzip.
While technical it may be possible to apply gzip to the actual stream I would not advise that, the benefit would be minimal in most cases and the compatibility issues with older players could be high (they may support gzip pages but not gzip audiostreams for example).
gzip should probably be enabled by default so that the "optimal" settings are enabled "out of the box".
Thomas B. RückerThomas B. Rücker