[vlc-devel] [PATCH] http: Mark the http-reconnect option as plugin-safe

Rémi Denis-Courmont remi at remlab.net
Sat Sep 26 20:34:45 CEST 2015


Le 2015-09-26 21:16, Luca Barbato a écrit :
> On 26/09/15 18:57, Rémi Denis-Courmont wrote:
>> Le 2015-09-26 19:44, Luca Barbato a écrit :
>>> On 26/09/15 12:34, Rémi Denis-Courmont wrote:
>>>> TBH, I would much prefer obsoleting the option and reconnecting
>>>> automatically when appropriate (i.e. connection broken before 
>>>> known end
>>>> of file).
>>>
>>> I might try to find some time to do that later, that would require 
>>> to:
>>>
>>> - have the fact the connection is broken reported by the lower 
>>> layer
>>> - get the expected end of file or know that the file doesn't have 
>>> an end.
>>>
>>>
>>> In the mean time I'd merge it and get some plugin users happier.
>>>
>>> Would it be ok?
>>
>> Exposing http-reconnect to playlist and then removing it later is 
>> not a
>> good idea. I am also not convinced that allowing random playlist 
>> files
>> to enable http-reconnect against third party web servers is a good 
>> idea
>> either.
>
> I think for the plugin users it makes sense to have it, no matter 
> what,

The NPAPI plugin is dead. Google killed it. Mozilla is killing it. I 
forget when it last worked with Apple, if ever. Anyone depending on the 
web plugin is running full speed toward a wall of hard concrete that is 
now getting dangerously close. So whitelisting is all about playlist 
files now. Not that it makes much difference though.

However I don't want to deal with demuxer bugs stemming from 
unvalidated HTTP resumption, or with web server operators annoyed by 
VLC's misbehaviour. The correct way to do with is with If-Match 
(possibly with fallback to If-Not-Modified-Since), not with a user 
option.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


More information about the vlc-devel mailing list