After sending or retrieving data, gstrtspconnection resets the socket's
timeout to 0 (infinite). This could cause problems if sending and
receiving at the same time. For example, if RTCP data is sent from the
streaming thread while gstrtspsrc is already retrieving data.
With this patch, timeout is only reset to 0 if there is no other
thread using the socket.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1260>
When connecting to an RTSP server in tunnled mode (HTTP) the server
usually replies with a x-server header. This contains the address
of the intended streaming server. However some servers return an
"invalid" address. Here follows two examples when it might happen.
1. A server use Apache combined with a separate RTSP process to handle
Https request on port 443. In this case Apache handle TLS and
connects to the local RTSP server, which results in a local
address 127.0.0.1 or ::1 in the x-server reply. This address is
returned to the actual RTSP client in the x-server header.
The client will receive this address and try to connect to it
and fail.
2. The client use a ipv6 link local address with a specified scope id
fe80::aaaa:bbbb:cccc:dddd%eth0 and connects via Http on port 80.
The RTSP server receives the connection and returns the address
in the x-server header. The client will receive this address and
try to connect to it "as is" without the scope id and fail.
In the case of streaming data from RTSP servers like 1. and 2. it's
useful to have the option to simply ignore the x-server header reply
and continue using the original address.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1192>
The users of this API need to be able to differentiate between EINTR
and ERROR. For example, in rtspsrc, gst_rtsp_conninfo_connect()
behaves differently when gst_rtsp_connection_connect_with_response_usec()
returns an ERROR or EINTR. The former is an element error while the
latter is simple a GST_ERROR since it was a user cancellation of the
connection attempt.
Due to this, rtspsrc was incorrectly emitting element errors while
going to NULL, which would or would not reach the application in
a racy manner.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1069>
The watch->messages_bytes is not decreased when the write operation
from the backlog is only partly successfull.
This commit decreases the watch->messages_bytes for the successfully
sent messages.
Fixes#679
Body_offset mean that so much data have been written.
Without this patch n_vectors somtimes becomes one more than it should
and then there will be an vector that have a random size causing
writev_bytes to cause a "Bad address" error.
RFC 7826 recommends (but does not require) starting at 0,
but at least one known server implementation fails to copy
request sequence numbers <1 into responses due to an
incorrect null check.
The server known to exhibit this behavior is the Parrot
Streaming Server, serving video from their UAV devices.
A fix has been submitted upstream as well:
https://github.com/Parrot-Developers/librtsp/pull/2
The Parrot developers are known to have tested with LibVLC.
In WireShark debugging, LibVLC appears to start with a CSeq
of 2, which is likely why this bug went unnoticed.
This reverts 487595a7d6, which set this to 0 citing the
RFC. The switch to 0 was thus a recent one; it's therefore
possible server implementors relied on the previous
GStreamer client behavior in their tests as well.
Fixes#624.
Add the possible to limit the Content-Length
Define an appropriate request size limit and reject requests exceeding
the limit (413 Request Entity Too Large)
Make rtspconnection a little more strict to RFC2326.
Make sure that CSeq is in every RTSP message and that CSeq is valid.
Also break the build_next loop if any parsing fails, By acting on
the builder->status code.
The former code allowed an attacker to create a heap overflow by
sending a longer than allowed session id in a response and including a
semicolon to change the maximum length. With this change, the parser
will never go beyond 512 bytes.
The function fill_bytes could sometimes return a value greater than zero
and in the same time set the GError.
Function read_bytes calls fill_bytes in a while loop. In the special
case above it would call fill_bytes with error already set.
Thus resulting in "GError set over the top of a previous GError".
Solved this by clearing GError when return value is greater than zero.
Actions are taken depending on error type by caller of read_bytes. Eg.
with EWOULDBLOCK gst_rtsp_source_dispatch_read will try to read the
missing bytes again (GST_RTSP_EINTR )
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/445
gstrtspconnection.c: In function ‘writev_bytes’:
gstrtspconnection.c:1348:10: error: ‘res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return res;
^
Otherwise we would return EOF if nothing was written in any case, even
if this was actually a case of TIMEOUT or EWOULDBLOCK for example.
Thanks to Edward Hervey for debugging and finding this issue.
Fixes 2 problems:
1) Number of unmapped memories does not always match number of mmaped ones in
dispatch_write().
2) When dispatch_write() is dispatched second time after an incomplete write,
already set offsets will not be taken into account, thus corrupt RTP data will
be sent.
gst_rtsp_connection_send() adds the Authorization header to the request.
If this function is being called multiple times with the same request
it will add one more Authorization header every time.
To fix to this issue do not append a new Authorization header on
top of an existing ones. Remove any existing Authorization headers first
and then add the new one.
Fixes gst-plugins-good#425
rtsp_connection_send takes care of adding those already,
and some reverse proxies such as nginx will reject the request
altogether if the Authorization header is present twice,
even with the same value.
https://bugzilla.gnome.org/show_bug.cgi?id=797272
When the GstRTSPConnection class sends a RTSP over HTTP tunnelling
request, the HTTP Content-Type header is missing from the HTTP POST
request.
This isn't a problem with most servers, but there are servers that
rejects the request without there also being a Content-Type header.
RFC 1945:
Any HTTP/1.0 message containing an entity body should include a
Content-Type header field defining the media type of that body.
Apple Dispatch 28:
QuickTime Streaming uses the "application/x-rtsp-tunnelled" MIME
type in both the Content-Type and Accept headers. This reflects
the data type that is expected and delivered by the client and server.
https://bugzilla.gnome.org/show_bug.cgi?id=793110
Properly handle protocol version in the connection
Add the following headers types:
* Pipelined-Request
* Media-Properties
* Seek-Style
* Accept-Ranges
https://bugzilla.gnome.org/show_bug.cgi?id=781446
Match the section 5.1.2 of the HTTP/1.0 spec by using relative URIs unless we
are using a proxy server. Also, send Host header for compatability with
HTTP/1.1 and some HTTP/1.0 servers.
https://bugzilla.gnome.org/show_bug.cgi?id=758922
gst_rtsp_connection_connect_with_response accepts a response pointer
which it fills with the response from setup_tunneling if the
connection is configured to be tunneled. The motivation for this is to
allow the caller to inspect the response header to determine if
additional authentication is required so that the connection can be
retried with the appropriate authentication headers.
The function prototype of gst_rtsp_connection_connect has been
preserved for compatability with existing code and wraps
gst_rtsp_connection_connect_with_response.
https://bugzilla.gnome.org/show_bug.cgi?id=749596
From the API documentation: "Note that it is generally not
a good idea to reuse an existing cancellable for more
operations after it has been cancelled once, as this
function might tempt you to do. The recommended practice
is to drop the reference to a cancellable after cancelling
it, and let it die with the outstanding async operations.
You should create a fresh cancellable for further async
operations."
https://bugzilla.gnome.org/show_bug.cgi?id=739132
