The authstr memory allocations make it annoying to error in the middle
of the header setup code, so apply the usual C error handling idiom to
make it easier to error at any point.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If a domain has some cookies set, but matching the cookie fails due to
the port being different, get_cookies() succeeds, but sets cookies to
NULL. The caller of get_cookies() didn't check for the NULL value.
This also avoids passing NULL to libc string functions, which is
undefined behavior
Fixes Ticket2180
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'e77a2ea9505863e50bf013706f66bf8b7325e524':
http: Declare more parameters as const where possible
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The icy_metadata_headers string never gets initialized, so,
during the first call to av_strlcatf() in parse_icy(),
strlen() will be called on a pointer to uninitialized memory.
At best this causes some garbage data to be left at the
start of the string.
By initializing icy_metadata_headers to the empty string, the
first call to strlen() will always return 0, so that data is
appended from the start of the string.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
* qatar/master:
http: Allow setting a Content-Type for POST requests
Conflicts:
libavformat/http.c
See: c01d1d4ddf
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '2ec33d27127251bbc45e1f88e60691ad59cf2319':
http: Add support for selecting a request range
Conflicts:
doc/protocols.texi
libavformat/http.c
See: d52882faef
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Export the metadata as a icy_metadata_packet avoption.
Based on the work of wm4 and Alessandro Ghedini.
Bug-Id: https://bugs.debian.org/739936
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some http servers send an ICY stream in combination with chunked
transfer encoding. This case was handled incorrectly by the ICY code:
instead of handling chunked encoding before anything ICY related, both
were mixed.
Fix this by separating the ICY code from normal http reading. Move the
normal http reading to a new function http_read_stream(), while
http_read() handles ICY on top of http_read_stream().
The server identified itself as: cloudflare-nginx
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Add AVOptions for setting the initial offset and the ending offset, so
they can be used for setting an appropriate Range header.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
* commit 'be4edda6731a341d3fdeaa0e57753dc396790362':
http: Expose the content location via an AVOption
Conflicts:
libavformat/http.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '76267ecc82e3018e1913a2483d5fc47d0949cbd8':
http: Remove an unrelated and mistakenly set AVOption unit name
Merged-by: Michael Niedermayer <michaelni@gmx.at>
These streams are reported as seekable, but all tests show they are not,
and the server merely pretends the streams are seekable. The server
responds with:
content-range: bytes 0-1999999999/2000000000
Range requests seem to be correctly answered, but the actual data
returned at the same offset is different. Assume this is a bug in the
server software. The server identifies itself as:
Server: MediaGateway 3.5.2-001
Add a hack that checks the server name, and disables seeking in this
case.
Test URL: http://8283.live.streamtheworld.com:80/CBC_R1_VCR_H_SC
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
http: Check the auth string contents and not only the pointer
Conflicts:
libavformat/http.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This makes sure we don't send the Except: 100-continue header
if no authentication credentials have been provided.
Signed-off-by: Martin Storsjö <martin@martin.st>
It appears this bug originates from a "work in progress" patch from
ffmpeg-devel that was heavily redesigned by and integrated in libav
And that patch even had a reply and review on the mailing list pointing
out that it had a bug.
This fixes a deadlock with ffserver
See: [FFmpeg-devel] [PATCH] Fix HTTP authentication problem for POST actions.
[FFmpeg-devel] [PATCH 1/3] Introduce auth_phase flag, which will be true if authorization needs to be sent, but the type of authorization is not known yet Partial fix#3036
[FFmpeg-devel] [PATCH 2/3] Only add Transfer-Encoding header when not in authorization phase, because server will wait (indefinitely) for data when receiving this header Partial fix#3036
[FFmpeg-devel] [PATCH 3/3] Only allow posting data and/or forcing a 200 code, enabling posting isml chunks, -after- we did a possible first request to get a 403 from the server telling us which type of authentication to apply Final part fix#3036
See: 71549a857b
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '71549a857b13edf4c4f95037de6ed5bb4c4bd4af':
http: Support auth method detection for POST
Conflicts:
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
