[vlc-devel] [PATCH] access/http: Inherit cookies from a parent HTTP access

[Antti Ajanki]

On 03.08.2014 12:21, Rémi Denis-Courmont wrote:
> Le dimanche 3 août 2014, 11:13:16 Antti Ajanki a écrit :
>> This allows stream filters such as HDS and HLS to share cookies between
>> HTTP requests. Enables playing streams that set a cookie when the
>> manifest is read and expect it to be sent back on fragment requests.
> There are other situations than HLS and HDS where an access object may be
> parented to another access object now (e.g. via the vobsub demux), and there
> may be other in the future. Basically, this breaks encapsulation unless we are
> certain that it is always acceptable and safe to inherit cookies.

It is safe. Cookies sent by the server in response to any request during 
a "session" (the life of the parent access) will accumulate in the jar 
and they will be submitted as part of all subsequent HTTP requests. This 
is what the cookie RFC expects a user agent to do.

> Also life cycle management of an object with VLC_VAR_ADDRESS may be hazardous
> - regardless of the mutex to protect internal state. This would at the very
> least need a clear set of access and ownership rules.

The rule is that the first HTTP access creates the cookie jar and is 
responsible for destroying it. All descendant accesses only have a weak 
pointer to the jar. Reading the pointer in the http-cookies variable is 
safe because it will never changes after it is created.

I am assuming that the parent access will only be destroyed after the 
child accesses have been destroyed (so that there will never be a 
dangling http-cookies pointer in a child access). Is this true?

Another option I was considering, was to put the cookie jar in the 
libvlc object and free the jar only when the libvlc instance is freed 
(cookies would be persisted for the life of the libvlc instance), but 
handling the jar life-cycle seems more complicated in this case.

Antti