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

[Luca Barbato]

On 26/09/15 20:34, Rémi Denis-Courmont wrote:
> 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.
>

The problem I'm trying to solve is as stupid as it sounds:

- Pause cause the tcp connection to timeout
- Reading from the dead tcp link returns 0 instead of a different error
- the http layer happily takes it as end of file.
- Returning from pause gets you to close vlc.

So far I hadn't tried to figure out if at the tcp level there is a way 
to send an error that let me know that http has to reconnect, an 
approximation could be something around:

diff --git a/modules/access/http.c b/modules/access/http.c
index ae0f722..1caec1c 100644
--- a/modules/access/http.c
+++ b/modules/access/http.c
@@ -686,7 +686,8 @@ static ssize_t Read( access_t *p_access, uint8_t 
*p_buffer, size_t i_len )
              p_sys->b_continuous = true;
          }
          Disconnect( p_access );
-        if( p_sys->b_reconnect )
+        if( p_sys->b_reconnect ||
+            ( p_sys->b_has_size && p_sys->p_sys->i_remaining ))
          {
              msg_Dbg( p_access, "got disconnected, trying to reconnect" );
              if( Connect( p_access, p_sys->offset ) )
@@ -695,9 +696,13 @@ static ssize_t Read( access_t *p_access, uint8_t 
*p_buffer, size_t i_len )
              }
              else
              {
+                int reconnect = p_sys->b_reconnect;
+                int has_size  = p_sys->b_has_size;
                  p_sys->b_reconnect = false;
+                p_sys->b_has_size = false;
                  i_read = Read( p_access, p_buffer, i_len );
-                p_sys->b_reconnect = true;
+                p_sys->b_reconnect = reconnect;
+                p_sys->b_has_size  = has_size;

                  return i_read;
              }

Works just if the file size is known but is better than the current 
situation and shouldn't cause problems that I can see.

lu