With libsoup 2.x, it was possible to know when there was a TLS failure, as
libsoup provided the "special http status code" SOUP_STATUS_SSL_FAILED.
However these special codes were dropped with libsoup 3.x: now libsoup emits
the accept-certificate signal when there's a TLS failure.
This commit adds a signal "accept-certificate" to SoupHttpSrc, which is in fact
just about forwarding the signal from SoupMessage (which is, itself, forwarded
from GTlsConnection). Note that, in case of libsoup 2.x, the signal is never
emitted.
Fixes: #2379
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4925>
In case of per features registration such as the
customizable gstreamer-full library, each
element should check that the soup library can be loaded to
facilitate the element registration.
Initialize the debug category properly
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2349>
GLib guarantees libintl is always present, using proxy-libintl as
last resort. There is no need to mock gettex API any more.
This fix static build on Windows because G_INTL_STATIC_COMPILATION must
be defined before including libintl.h, and glib does it for us as part
as including glib.h.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2028>
Starting with libsoup3, there is no attempt to handle thread safety
inside the library, and it was never considered fully safe before
either. Therefore, move all session handling into its own thread.
The libsoup thread has its own context and main loop. When some
request is made or a response needs to be read, an idle source
is created to issue that; the gstreamer thread issuing that waits
for that to be complete. There is a per-src condition variable to
deal with that.
Since the thread/loop needs to be longer-lived than the soup
session itself, a wrapper object is provided to contain them. The
soup session only has a single reference, owned by the wrapper
object.
It is no longer possible to force an external session, since this
does not seem to be used anywhere within gstreamer and would be
tricky to implement; this is because one would not have to provide
just a session, but also the complete thread arrangement made in
the same way as the system currently does internally, in order to
be safe.
Messages are still built gstreamer-side. It is safe to do so until
the message is sent on the session. Headers are also processed on
the gstreamer side, which should likewise be safe.
All requests as well as reads on the libsoup thread are issued
asynchronously. That allows libsoup to schedule things with as
little blocking as possible, and means that concurrent access
to the session is possible, when sharing the session.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/947
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1555>
The src and sink elements no longer link against libsoup. It is now loaded at
runtime. If any version is resident already, it is used. Otherwise we first try
to load libsoup3 and if it's not found we fallback to libsoup2.
For the unit-tests, we now build one version of the test unit file per libsoup
version found. So if both libsoup2 and libsoup3 are available on the host, the
CI will cover them both.
Based on initial patch by Daniel Kolesa <dkolesa@igalia.com> and
Patrick Griffis <pgriffis@igalia.com>.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1044>
