Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2022-11-22T23:19:38Zhttps://gitlab.xiph.org/xiph/xspf-website/-/issues/25Page applications - broken note2022-11-22T23:19:38ZДолматов АлексейPage applications - broken note**Based on the structure of the text, there should be a hyperlink to the discussions.**
> Screenshot:
![2022-07-09_03_01_29](/uploads/75da8f1d12972db61b75fcc36fd2f5c9/2022-07-09_03_01_29.png)**Based on the structure of the text, there should be a hyperlink to the discussions.**
> Screenshot:
![2022-07-09_03_01_29](/uploads/75da8f1d12972db61b75fcc36fd2f5c9/2022-07-09_03_01_29.png)https://gitlab.xiph.org/xiph/speex/-/issues/2040missing release tarball for 1.2.12022-07-06T17:26:58ZXi Ruoyaomissing release tarball for 1.2.1The release tarball for 1.2.1 is not uploaded to downloads.xiph.org. And https://www.speex.org/downloads/ still shows 1.2.0 as the "latest" release.The release tarball for 1.2.1 is not uploaded to downloads.xiph.org. And https://www.speex.org/downloads/ still shows 1.2.0 as the "latest" release.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2445Finished streams are still shown as online and aren't cleared up by Icecast -...2022-11-12T17:15:38ZMole ManFinished streams are still shown as online and aren't cleared up by Icecast - have to kill the source to free up the mountpointHi guys,
I noticed that occasionally streamers end their stream but their stream is still shown as live on the server status page, you can't connect to the stream as a listener (VLC tries to connect forever) and the stream doesn't get ...Hi guys,
I noticed that occasionally streamers end their stream but their stream is still shown as live on the server status page, you can't connect to the stream as a listener (VLC tries to connect forever) and the stream doesn't get removed by Icecast after any period of time, so I have to kill the source in the admin UI to get rid of it. The source timeout in the limits section of the icecast.xml is set to 10 seconds. In the admin UI I can also see that no packets are transferred (params total_bytes_read and total_bytes_sent don't change), so Icecast should be able to see that the stream is inactive. This has happened to at least two different users/mountpoints and it happened twice this week to the same user, but it only happens sometimes. This does not seem to affect other mountpoints, other users can still start and stop streams while the zombie stream is on.
I also think that this only started to happen in the last few months, but the only change I implemented in that timespan was the addition of an SSL certificate and a mountpoint which uses SSL. The stream in the example wasn't encrypted though, so I don't think these things are related. I attached screenshots of the stuck stream in the admin console and of the access.log where the timestamps look suspicious to me, the message of the stream start looks like it was only logged when I killed the source the next day - though I might have misunderstood that part :-) better have a look for yourself, see the screenshot for more details. There was no heavy load or any other unusual events while this happened.
Impact: This leads to users not being able to reconnect to their own mountpoint in case they get disconnected until an admin manually kills the source.
Otherwise: Great software, runs smooth with minial administration overhead. Thanks in advance for checking!
Environment: Icecast 2.4.4 running on a VPS with CentOS 7
Limits:
<limits>
<clients>400</clients>
<sources>20</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>20</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>0</burst-on-connect>
<burst-size>65535</burst-size>
</limits>https://gitlab.xiph.org/xiph/icecast-server/-/issues/2444Setup pre-commit config2022-07-04T12:31:56ZJonas L.Setup pre-commit configI propose to add a https://pre-commit.com/ config to this repository to add code formatting/cleaning and few checks to keep the files in check.
Here is a config draft I propose:
```yml
---
# See https://pre-commit.com for more informati...I propose to add a https://pre-commit.com/ config to this repository to add code formatting/cleaning and few checks to keep the files in check.
Here is a config draft I propose:
```yml
---
# See https://pre-commit.com for more information
# See https://pre-commit.com/hooks.html for more hooks
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.3.0
hooks:
- id: check-added-large-files
- id: check-case-conflict
- id: check-executables-have-shebangs
- id: check-shebang-scripts-are-executable
- id: check-symlinks
- id: destroyed-symlinks
- id: check-json
- id: check-yaml
- id: check-xml
- id: check-merge-conflict
- id: end-of-file-fixer
- id: mixed-line-ending
- id: trailing-whitespace
- repo: https://github.com/pre-commit/mirrors-prettier
rev: v2.6.2
hooks:
- id: prettier
files: \.(md|yml|yaml)$
- repo: https://github.com/codespell-project/codespell
rev: v2.1.0
hooks:
- id: codespell
args:
- --builtin=clear,rare,informal
```
This would also mean to add a CI job to enforce those checks.
Personally it would make it easier for me to edit files using a IDE that automatically format and clean on save (which I consider a good practice), and prevent some spelling error to land in the code.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2442CPU churning by Body and Request Queue thread2022-11-15T12:22:44ZLászló KárolyiCPU churning by Body and Request Queue threadas discussed on IRC, here's the long awaited 'official bug report' about 2.5 beta.
Whenever I run it on a server that can at times serve 1000 clients, after restart the thread name "Request Queue" starts consuming 100% CPU instantly. Af...as discussed on IRC, here's the long awaited 'official bug report' about 2.5 beta.
Whenever I run it on a server that can at times serve 1000 clients, after restart the thread name "Request Queue" starts consuming 100% CPU instantly. After a while, "Body Queue" does the same.
This ends up in a 2.2 load (15 min average) on a 4 CPU server.
The server is a standard Ubuntu (20.04.4 LTS), nothing extra added, using UFW.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2441Icecast 2.5 beta 3 stops after 3 seconds2023-01-03T10:08:01ZMichelIcecast 2.5 beta 3 stops after 3 secondsThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
MichelThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/24402.5 Beta not adhering to master-update-interval2022-05-17T19:14:44ZUmar Dockrat2.5 Beta not adhering to master-update-intervalGood Day,
I've set master-update-interval to every 5 seconds however based on the observered stream sync behaviour and relay server log messages:
```
[2022-05-15 22:52:39] INFO slave/update_from_master Master accepted streamlist reque...Good Day,
I've set master-update-interval to every 5 seconds however based on the observered stream sync behaviour and relay server log messages:
```
[2022-05-15 22:52:39] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 22:54:39] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 22:56:39] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 22:57:02] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 22:59:02] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:00:19] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:00:34] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:00:35] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:00:50] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:05] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:20] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:21] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:36] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:01:51] INFO slave/update_from_master Master accepted streamlist request
[2022-05-15 23:02:07] INFO slave/update_from_master Master accepted streamlist request
```
We can see the update is sporadic.
Master server running 2.4.5 relay server on beta.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2439HTTP request EOF problem2022-05-07T15:37:59ZCsaba27HTTP request EOF problemHello, i have a problem with icecast 2.4.99 version, after the http response the icecast doesn't close the connection.
There is an example code from PHP:
```
<?php
// ini_set("default_socket_timeout", 5);
$start = microtime(true);
$...Hello, i have a problem with icecast 2.4.99 version, after the http response the icecast doesn't close the connection.
There is an example code from PHP:
```
<?php
// ini_set("default_socket_timeout", 5);
$start = microtime(true);
$fp = fsockopen("icecast-example-host.com", 8000, $errno, $errstr, 5);
if ($fp)
{
$out = "GET /status_json.xsl HTTP/1.1\r\n";
$out .= "Connection: Close\r\n";
$out .= "Host: icecast-example-host.com:8000\r\n";
$out .= "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36\r\n";
$out .= "\r\n";
fwrite($fp, $out);
// stream_set_timeout($fp, 5);
$line_count = 0;
while (!feof($fp))
{
$line_count++;
echo $line_count . " " . fgets($fp);
# echo fread($fp, 1024);
}
fclose($fp);
}
else
{
echo $errstr . " (" . $errno . ")" . PHP_EOL;
}
echo PHP_EOL . " " . round(microtime(true) - $start, 4);
```
Run in console and check the execution time (request time).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2438Segfault when public is "True"2022-11-09T10:21:58ZAlexey ParamonovSegfault when public is "True"[icecast_3.conf](/uploads/6b3b69fb7077a4dc5364951670846a74/icecast_3.conf)
Icecast 2.5 (Icecast 2.4.99.3) dies with a segfault if there are the following lines in the config file:
```
<public>1</public>
<stream-name>Click Yo...[icecast_3.conf](/uploads/6b3b69fb7077a4dc5364951670846a74/icecast_3.conf)
Icecast 2.5 (Icecast 2.4.99.3) dies with a segfault if there are the following lines in the config file:
```
<public>1</public>
<stream-name>Click Your Radio Dutch</stream-name>
<stream-description>The best in Dutch Music and Comedy</stream-description>
<stream-url>www.clickyourradio.com</stream-url>
<genre>Music &amp; Comedy</genre>
```
Complete config file is attachedPhilipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2335Segfault when public is "True"2022-05-03T10:46:51ZAlexey ParamonovSegfault when public is "True"[icecast_3.conf](/uploads/d60903ca7906dc7a0087674798fdb63c/icecast_3.conf)
Icecast 2.5 (Icecast 2.4.99.3) dies with a segfault if there are the following lines in the config file:
```
<public>1</public>
<stream-name>Click ...[icecast_3.conf](/uploads/d60903ca7906dc7a0087674798fdb63c/icecast_3.conf)
Icecast 2.5 (Icecast 2.4.99.3) dies with a segfault if there are the following lines in the config file:
```
<public>1</public>
<stream-name>Click Your Radio Dutch</stream-name>
<stream-description>The best in Dutch Music and Comedy</stream-description>
<stream-url>www.clickyourradio.com</stream-url>
<genre>Music &amp; Comedy</genre>
```
Complete config file is attachedhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2283Accept relative paths to m3u inside m3u2023-01-19T22:52:57ZDan SanfordAccept relative paths to m3u inside m3uIf I have m3u in the same folder as mp3s then it should be enough to give filenames without paths inside m3u, when I reference m3u outside the folder.
```
playlist.m3u (containing only: file.mp3)
file.mp3
```If I have m3u in the same folder as mp3s then it should be enough to give filenames without paths inside m3u, when I reference m3u outside the folder.
```
playlist.m3u (containing only: file.mp3)
file.mp3
```Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2282Give better error msg when xml config file is invalid.2022-08-20T01:52:48ZDan SanfordGive better error msg when xml config file is invalid.Especially since config file format changed.
passing the old format (that most tutorials on ezstream use) gives a not really useful remark (not even error):
```
<ezstream>
<url>http://localhost:8000/goodmusic</url>
<sourcepassw...Especially since config file format changed.
passing the old format (that most tutorials on ezstream use) gives a not really useful remark (not even error):
```
<ezstream>
<url>http://localhost:8000/goodmusic</url>
<sourcepassword>make-up-your-own</sourcepassword>
<format>MP3</format>
<filename>/mnt/music/goodmusic/playlist.m3u</filename>
<shuffle>1</shuffle>
<stream_once>0</stream_once>
<svrinfoname>Good Music</svrinfoname>
<svrinfourl>pihole.local</svrinfourl>
<svrinfogenre>Good Music Streaming 24x7</svrinfogenre>
<svrinfodescription>Techno Dub</svrinfodescription>
<svrinfobitrate>128</svrinfobitrate>
<svrinfochannels>2</svrinfochannels>
<svrinfosamplerate>44100</svrinfosamplerate>
<svrinfopublic>1</svrinfopublic>
</ezstream>
~$ ezstream -c test.xml
ezstream[313100]: test.xml: world readable
ezstream[313100]: stream: default: no configuration
```
No idea what to do next, wasted half a day on this.Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2281Standard --version flag is not supported2022-08-20T01:58:53ZDan SanfordStandard --version flag is not supportedMoritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/ezstream/-/issues/2280Can't install from source2022-08-20T02:11:25ZDan SanfordCan't install from sourcegit clone --depth 1 https://gitlab.xiph.org/xiph/ezstream.git
cd ezstream/
; based on readme.md
./configure
-bash: ./configure: No such file or directory
there is configure.ac but readme doesn't say anything about it.git clone --depth 1 https://gitlab.xiph.org/xiph/ezstream.git
cd ezstream/
; based on readme.md
./configure
-bash: ./configure: No such file or directory
there is configure.ac but readme doesn't say anything about it.Moritz GrimmMoritz Grimmhttps://gitlab.xiph.org/xiph/liboggz/-/issues/10support opus codec2022-04-29T00:36:54ZChristoph Anton Mitterersupport opus codecHey.
It seems the various tools have no idea about the opus codec. Would be nice if that could be supported instead of being shown as `unknown`.
Thanks,
Chris.Hey.
It seems the various tools have no idea about the opus codec. Would be nice if that could be supported instead of being shown as `unknown`.
Thanks,
Chris.https://gitlab.xiph.org/xiph/icecast-common/-/issues/8Build failure for mingw targets with latest Clang 152022-04-22T10:05:32ZMartin StorsjöBuild failure for mingw targets with latest Clang 15Building libshout for mingw targets, with the very latest (unreleased) Clang 15 fails, with this error:
```
../../../../src/common/timing/timing.c:73:5: error: call to undeclared function 'gettimeofday'; ISO C99 and later do not support...Building libshout for mingw targets, with the very latest (unreleased) Clang 15 fails, with this error:
```
../../../../src/common/timing/timing.c:73:5: error: call to undeclared function 'gettimeofday'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
gettimeofday(&mtv, NULL);
^
1 error generated.
```
With previous Clang versions, this was a nonfatal warning:
```
../../../../src/common/timing/timing.c:73:5: warning: implicit declaration of function 'gettimeofday' is invalid in C99 [-Wimplicit-function-declaration]
gettimeofday(&mtv, NULL);
^
1 warning generated.
```
Clang 15 has changed to make such implicit function declarations a hard error by default, see https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626 for details.
Key parts of the arguments for it are:
> C89 had a questionable feature where the compiler would implicitly declare a function that the user called but was never previously declared. The resulting function would be globally declared as `extern int func();` -- a function without a prototype which accepts zero or more arguments.
>
> C99 removed support for this questionable feature due to severe security concerns. However, there was no deprecation period; C89 had the feature, C99 didn't. So Clang (and GCC) both supported the functionality as an extension in C99 and later modes.
>
> [...]
>
> However, because this feature will not be supported in C2x mode, we've diagnosed it as being invalid for so long, the security concerns with the feature, and the trivial workaround for users (declare the function), we now default the extension warning to an error in C99-C17 mode.
While Clang 15 still is unreleased, this policy may still change - but nevertheless, the warning is entirely valid in any case, and should be fixed.
The issue at hand is caused by the following parts in icecast-common's `timing/timing.c`:
```
#ifdef _WIN32
#include <windows.h>
#include <mmsystem.h>
#else
#ifdef TIME_WITH_SYS_TIME
# include <sys/time.h>
# include <time.h>
#else
# ifdef HAVE_SYS_TIME_H
# include <sys/time.h>
# else
# include <time.h>
# endif
#endif
#include <unistd.h>
#endif
```
Followed by:
```
uint64_t timing_get_time(void)
{
#ifdef HAVE_GETTIMEOFDAY
struct timeval mtv;
gettimeofday(&mtv, NULL);
return (uint64_t)(mtv.tv_sec) * 1000 + (uint64_t)(mtv.tv_usec) / 1000;
#elif HAVE_FTIME
struct timeb t;
ftime(&t);
return t.time * 1000 + t.millitm;
#else
#error need time query handler
#endif
}
```
In the case of a mingw build, `HAVE_GETTIMEOFDAY` is defined, so the implementation of `timing_get_time` tries using `gettimeofday`. But the header inclusion block above only bothers to try to include `<sys/time.h>` if specifically running on a platform other than Windows.
Suggested fix:
Decouple the includes of `<sys/time.h>` and `<time.h>` from the `#ifdef _WIN32 ... #else` block. If `TIME_WITH_SYS_TIME` is defined, try to include both `<sys/time.h>` and `<time.h>`. If not, include `<time.h>` (which is a standard C header which I presume icecast can assume exists) and/or possibly `<sys/time.h>` (based on `HAVE_SYS_TIME_H` - which doesn't seem to be set by the configure script in libshout though).
```diff
diff --git a/timing/timing.c b/timing/timing.c
index 9be67d5..7efa776 100644
--- a/timing/timing.c
+++ b/timing/timing.c
@@ -35,8 +35,11 @@
#ifdef _WIN32
#include <windows.h>
#include <mmsystem.h>
#else
+#include <unistd.h>
+#endif
+
#ifdef TIME_WITH_SYS_TIME
# include <sys/time.h>
# include <time.h>
#else
@@ -46,11 +49,8 @@
# include <time.h>
# endif
#endif
-#include <unistd.h>
-#endif
-
#ifdef HAVE_SYS_SELECT_H
#include <sys/select.h>
#endif
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2437Provide systemd services (replace sysv scripts)2022-04-22T10:03:14ZJonas L.Provide systemd services (replace sysv scripts)Could you provide a systemd service and start replacing the old sysv scripts ?
A lot of distribution provided there own service files, but I was hoping to move those service files upstream.
- https://github.com/archlinux/svntogit-commu...Could you provide a systemd service and start replacing the old sysv scripts ?
A lot of distribution provided there own service files, but I was hoping to move those service files upstream.
- https://github.com/archlinux/svntogit-community/blob/5c80c74e8011a5f5ff31a4fff4769c96c7f07182/trunk/icecast.service
- https://src.fedoraproject.org/rpms/icecast/blob/rawhide/f/icecast.service
- Debian still relies on the sysv script, and I was hoping that once the service file is here, it would trickle down to Debian.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2436Icecast2 server poll infinitly2022-04-12T11:55:18ZDorianNicolasIcecast2 server poll infinitlyHello,
I tried to start a icecast2 server with the command
`icecast2 -c test.xml`
Where test.xml is an unmodified configuration file of icecast2.
Here my logs when i start the command :
```
[2022-04-12 11:34:35] WARN CONFIG/_parse...Hello,
I tried to start a icecast2 server with the command
`icecast2 -c test.xml`
Where test.xml is an unmodified configuration file of icecast2.
Here my logs when i start the command :
```
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <hostname> not configured, using default value "localhost". This will cause problems, e.g. with YP directory listings.
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <location> not configured, using default value "Earth".
[2022-04-12 11:34:35] WARN CONFIG/_parse_root Warning, <admin> contact not configured, using default value "icemaster@localhost".
```
Only warnings and nothing happens. I can access the icecast2 page (localhost:3000), I can access admin page with logs and it works. But no mountpoint are printed even if I modified the list. The list is empty.
So I looked why the icecast2 server doesn't load mountpoints. And i found this with strace command :
```
read(7, "\2\232\337wPP|spA`\226\275'Z\20\33m\337\2XkW\352~\255\5\30$\232\360D"..., 52) = 52
close(7) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2960, ...}) = 0
write(5, "[2022-04-12 11:33:01] INFO conn"..., 101) = 101
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 300) = 0 (Timeout)
```
And nothing more, except this infinite message like if it were waiting something. I'm working on WSL2 (Ubuntu) on Windows. I tried on Windows the same steps in the same way but I have exactly the same for both, so I don't think the problem comes from Windows or WSL. Moreover, I can access to the Icecast2 link server and I can connect to the admin panel, but it doesn't load my mountpoints.
Any help would be appreciate,
Thankshttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2334Mixxx build patches2022-04-12T11:07:10ZDaniel SchürmannMixxx build patchesThis is the set of patches we apply in the Mixxx project to build libshout on Linux/Windows/MacOs.
[0006-Handle-unhandled-enum-values-in-switch-statements.patch](/uploads/697b5afa3df8c0a07efd437d36b2776b/0006-Handle-unhandled-enum-valu...This is the set of patches we apply in the Mixxx project to build libshout on Linux/Windows/MacOs.
[0006-Handle-unhandled-enum-values-in-switch-statements.patch](/uploads/697b5afa3df8c0a07efd437d36b2776b/0006-Handle-unhandled-enum-values-in-switch-statements.patch)
[0005-Verify-port-number-length.patch](/uploads/89e9c67e61740c4965d9141407c14c2c/0005-Verify-port-number-length.patch)
[0004-Fix-includes.patch](/uploads/716c9fa35c186257ef1431fb87ca865d/0004-Fix-includes.patch)
[0003-replace-illegal-void-arythmetric.patch](/uploads/f6f23b2338e477af3aa5d0c43372063b/0003-replace-illegal-void-arythmetric.patch)
[0002-fix-os.h.patch](/uploads/34c49851823f285aaeae15b3decca10b/0002-fix-os.h.patch)
[0001-Remove-unsused-strings.h.patch](/uploads/519033c12062e1d0a4cd010254840e73/0001-Remove-unsused-strings.h.patch)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2435URL Auth does not post good port2022-04-07T17:32:54ZRa LawaURL Auth does not post good portHi,
URL Auth always posts the first listen-socket port configured in icecast.xml. When both http (port 80) and https (port 443) are enabled, url auth always send port=80 in the post request.
I think, it should send port=80 when the cli...Hi,
URL Auth always posts the first listen-socket port configured in icecast.xml. When both http (port 80) and https (port 443) are enabled, url auth always send port=80 in the post request.
I think, it should send port=80 when the client uses an http request and 443 when it uses an https request.
For url redirection, this would help to produce an url which depends on method used by the client. Redirection to an https url when client uses an https url and http otherwise.
Currently I use an other method to know which method is used. I patched url_add_client to send also tlsmode to the post request.Philipp SchafftPhilipp Schafft