The current code would use any unknown attribute-value pair
as the cookie value.
RFC 6265 states that the first key-value pair is the actual
cookie, and the attribute-value pairs only start after.
With the current code:
Set-Cookie: test=good_value; path=/; dummy=42
gives this:
Cookie: dummy=42
instead of this with the new code:
Cookie: test=good_value
The cur_*auth_type variables were set before the http_connect call
prior to 6a463e7fb - their sole purpose is to record the
authentication type used to do the latest request, since parsing
the http response sets the new type in the auth state.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously this logic was only used if the server didn't
respond with Connection: close, but use it even for that case,
if the server response is non-chunked.
Originally the http code has relied on Connection: close to close
the socket when the file/stream is received - the http protocol
code just kept reading from the socket until the socket was closed.
In f240ed18 we added a check for the file size, because some
http servers didn't respond with Connection: close (and wouldn't
close the socket) even though we requested it, which meant that the
http protocol blocked for a long time at the end of files, waiting
for a socket level timeout.
When reading over tls, trying to read at the end of the connection,
when the peer has closed the connection, can produce spurious (but
harmless) warnings. Therefore always voluntarily stop reading when
the specified file size has been received, if not using a chunked
transfer encoding. (For chunked transfers, we already return 0
as soon as we get the chunk header indicating end of stream.)
Signed-off-by: Martin Storsjö <martin@martin.st>
Split return value handling from the actual opening.
Incidentally fixes the https -> http redirect issue reported by
Compn on behalf of rcombs.
CC: libav-stable@libav.org
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>
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>
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>
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>
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>
Inspired by a patch by Jakob van Bethlehem. But instead of doing
an empty POST first to trigger the WWW-Authenticate header (which
would succeed if no auth actually was required), add an Expect:
100-continue header, which is meant to be used exactly for
cases like this.
The header is added if doing a post, and the user has specified
authentication but we don't know the auth method yet.
Not all common HTTP servers support the Expect: 100-continue header,
though, so we only try to use it when it really is needed. The user
can request it to be added for other POST requests as well via
an option - which would allow the caller to know immediately that
the POST has failed (e.g. if no auth was provided but the server
required it, or if the target URL simply doesn't exist).
This is only done for write mode posts (e.g. posts without pre-set
post_data) - for posts with pre-set data, we can just redo the post
if it failed due to 401.
Signed-off-by: Martin Storsjö <martin@martin.st>
The default is to autodetect the auth method. This does require one
extra request (and also closing and reopening the http connection).
For some cases such as HTTP POST, the autodetection is not handled
properly (yet).
No option is added for digest, since this method requires getting
nonce parameters from the server first and can't be used straight
away like Basic.
Signed-off-by: Martin Storsjö <martin@martin.st>
When passing a dict to the nested protocol, it will consume
the used options from it, so a separate copy needs to be used
when reopening the connection multiple times.
Signed-off-by: Martin Storsjö <martin@martin.st>
Derived from VLC's http module.
Original authors:
Antoine Cellerier <dionoea@videolan.org>
Sébastien Escudier <sebastien-devel@celeos.eu>
Rémi Duraffort <ivoire@videolan.org>
Rémi Denis-Courmont <remi@remlab.net>
Francois Cartegnie <fcvlcdev@free.fr>
Normally, http servers shouldn't send this to us since we
don't advertise it with an Accept-Encoding header, but some
servers still do it anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>
Nicolas George
Gabriel Dume
Diego Biurrun
Martin Storsjö
Andrew Stone
Rodger Combs
Luca Barbato
Michael Niedermayer
wm4
Alessandro Ghedini
Clément Bœsch
Anssi Hannula
Lukasz Marek
Eli Kara
Zhang Rui