[FFmpeg-devel] [PATCH] Rudimentary cookie support for HTTP

[Duncan Salerno]

On Wed, Oct 10, 2012 at 4:16 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Oct 09, 2012 at 09:09:58PM +0100, Duncan Salerno wrote:
>> For comment. The aim is primarly for HLS (and I guess later HDS) where a request to an initial URL sets some cookies, which are required in later requests as authentication. There is no need for cookies to persist across runs of ffmpeg.
>>
>> However with this implementation cookies are never free'd - is this okay? Any better suggestions?
>> ---
>>  libavformat/http.c |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 62 insertions(+)
>>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index d385011..ef6f296 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -87,6 +87,18 @@ static const AVClass flavor ## _context_class = {\
>>  HTTP_CLASS(http);
>>  HTTP_CLASS(https);
>>
>> +
>> +/**
>> + * Store cookies in a linked list.
>> + */
>> +typedef struct Cookie {
>> +    const char *domain;                 ///< domain
>> +    const char *path;                   ///< path
>> +    const char *value;                  ///< cookie name value pair (ie. name=value)
>> +    struct Cookie *next;                ///< next Cookie
>> +} Cookie;
>
>> +static Cookie *cookiejar = NULL;
>
> this is not thread safe, there can be multiple independant http
> protocols open, they might in theory on a server even belong to
> different users (imaging a web app that downloads & encodes videos
> and is run from a single process with multiple threads one per user)

Could you suggest a better way? For example, in the case of HLS, I was
thinking about storing the cookie jar in that context, but it doesn't
control the original HTTP.request, so how could it get cookies set in
the initial response?