To allow souphttpsrc to be use HTTP methods other than GET
(e.g. HEAD), add a "method" property that is a string. If this
property is not set, GET is used.
https://bugzilla.gnome.org/show_bug.cgi?id=752413
1) If the system http_proxy environment variable is not set
or set to an empty string, we must not set proxy to avoid
http connection error.
2) In case of proxy property setting, if user want to clear
the proxy setting, they should be able to set it to NULL or
an empty string again, so this is fixed too.
3) Check if the proxy string was parsed correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=752866
basesrc assumes that we don't return a buffer if
something else than OK is returned. It will just
leak any buffer we might accidentially provide
here.
This can potentially happen during flushing.
Maybe fixes https://bugzilla.gnome.org/show_bug.cgi?id=741993
When we cancel connection attempts and similar things, there are still
some operations pending on our main context from the GCancellables. We
should let them all run before unreffing our context, otherwise we leak
file descriptors.
Unfortunately this requires libsoup 2.47.0 or newer as earlier versions
steal our main context from us and we can't use it for cleanup later
without assertions and funny crashes.
Based on a patch by Dmitry Shatrov <shatrov@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=663944
If nothing happens after 15 seconds, chances are good that
our connection will never will work. Stop after 15 seconds
instead of waiting until the system's default timeout, which
can be > 1 minute.
Only return EOS the next time create() is called, if at all. basesrc
should already take care of not calling it again.
Also always return immediately if the previous flow return was
not OK. This indicates an error somewhere.
Commit 46fd12ae5e introduced connection
recovery. But when server does not specify content-size,
souphttpsrc tries to reconnect even after regular end of stream.
Http server replies with SOUP_STATUS_REQUESTED_RANGE_NOT_SATISFIABLE
but souphttpsrc still emits error instead of EOS.
https://bugzilla.gnome.org/show_bug.cgi?id=724717
Signed-off-by: Branislav Katreniak <bkatreniak@nuvotechnologies.com>
We want to notice ourselves that we're EOS. Otherwise we will
always cancel requests in the very end and confuse the server...
and also make it impossible to use persistent connections.
If the pipeline is stalled for too long, souphttpsrc will block and
stop fetching data from the network. This can cause the connection to
drop and souphttpsrc would handle it as an EOS. This patch makes it
persist and try to fetch more data until the end of the content length
or until receiving an error that it is beyong limits in case the content
is unknown.
https://bugzilla.gnome.org/show_bug.cgi?id=683536
The HTTP server could give wrong information, e.g. if the HTTP stream is
chunk-encoded or compressed, or if the server does not know the complete size
at the time when the file is requested by the client.
Also see
https://bugs.webkit.org/show_bug.cgi?id=115354
Answer to scheduling queries with default parameters and the new
_BANDWIDTH_LIMITED_FLAG so that downstream is advised to minimize seek
operations and perform on-disk buffering if possible.
Bug 693484
In 1.0 we now always send the icecast request headers by default, which
makes the server send icecasts metadata inserted into the stream if it
supports that. However, there are some use cases where this is not
desirable, like when just saving a radio stream to disk, so add back
the "iradio-mode" property to allow people to disable this.
https://bugzilla.gnome.org/show_bug.cgi?id=697984
Apparently there's no reason to use it any longer. Drop libsoup-gnome
dependency while at it, now that we don't need anything from it any
more (it only consists entirely of deprecated API now anyways).
https://bugzilla.gnome.org/show_bug.cgi?id=693911
When receiving an error code from the http server, such as 404,
data might be sent along with it, like a web page. We don't want
to output that data in this case, and we also want to pass the
FLOW_ERROR return back to the base class, so it can stop properly.
https://bugzilla.gnome.org/show_bug.cgi?id=678429
Leave it to the application to decide on the header. No header at all
is better than having the wrong header as DLNA mandates that a missing
header has to be tolerated while a wrong header is an error.
https://bugzilla.gnome.org/show_bug.cgi?id=676020
Consider a downstream element that may issue seeks in very short
succession (e.g. queue2), depending on the access pattern of
the downstream element (e.g. qtdemux with audio/video chunks
interleaved so that there's always a sizeable gap between the
current chunks for each stream). In this case, queue2 will maintain
two ranges, and even when it serves a chunk from memory, it will
switch ranges and make souphttpsrc seek to the end of the available
data for that range, assuming that that's where we'll want to
continue reading from next.
This may lead to the following seek request pattern:
- source reading position A
- seek to B
- now reading position still A, requested_postion is B
- streaming thread to be restarted to continue from B
- seek to A, before streaming thread had time to do the seek
- do_seek() now sees reading position == seek position and
returns early.
- however, requested position is still B from the earlier
seek request
- streaming thread starts up, sees that a seek to B is pending
and requests data from B from the server, while the GstBaseSrc
segment has of course been updated/reset to position A, which
was the last seek request.
- we will now send data for position B and pretend that's the
data from position A (via the newsegment event, etc.)
- this causes data corruption
Reproducible doing seek-emulated fast-forward/backward on 006648.
Error messages should be translated. URIs and filenames should not
be part of the error message string that's shown to the user.
soup_message->reason_phrase is not translated and not suitable as
error message for users (see libsoup documentation). Also fix up
error codes a bit, as far as possible with the existing codes.
Before they contained the URL before the actual failure. The other
way around makes more sense and we do the same in other elements
like filesrc.
Fixes bug #627289.
Previously seekability way always assumed until the first seek actually
failed. Now we assume that all servers are not seekable unless they provide
a Content-Length header. If a seek fails after that we continue to
assume no seekability. Fixes bug #585576.
When "Content-Type" header is "audio/L16", we need to set the caps on the
outgoing buffers so that downstream elements can have means to detect the
stream type and handle it appropriately. Tested with HTTP stream provided
by pulse-audio's http module (git master).
This allows to set the Referer header among other things by
adding a "extra-headers" property that takes a GstStructure
with field=string pairs.
Fixes bug #581806.
