[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