vlc does not consistently handle http timeouts

reposting from forum: http timeouts

i believe i am running into the same problem mentioned in this issue: #27661 (closed)

This happens in the standalone VLC player and when attempting to play media with the libraries.

Did a quick look through the code flow, and wanted to verify if what i am seeing is correct.

The problem i am seeing relates to the different paths taken between HTTP and HTTPS connections when opening a stream i believe.

HTTPS connections eventually call vlc_tls_ClientSessionCreate which does indeed attempt to retrieve the ipv4-timeout setting in order to timeout.

HTTP connections eventually call vlc_tls_Write instead though, which does not retrieve the timeout setting and thus ends up waiting indefinitely.

The last http debug log message below echoes the "outgoing request:" present in vlc_h1_stream_open right before it calls vlc_tls_Write.

Am i understanding the connection flow properly, or could there be something else going on that is causing this behavior?

HTTPS: https://code.videolan.org/videolan/vlc/-/blob/master/modules/access/http/connmgr.c#L184 https://code.videolan.org/videolan/vlc/-/blob/master/modules/access/http/connmgr.c#L69 https://code.videolan.org/videolan/vlc/-/blob/master/src/network/tls.c#L247 https://code.videolan.org/videolan/vlc/-/blob/master/src/network/tls.c#L166 https://code.videolan.org/videolan/vlc/-/blob/master/src/network/tls.c#L193

HTTP: https://code.videolan.org/videolan/vlc/-/blob/master/modules/access/http/connmgr.c#L253 https://code.videolan.org/videolan/vlc/-/blob/master/modules/access/http/h1conn.c#L405 https://code.videolan.org/videolan/vlc/-/blob/master/modules/access/http/h1conn.c#L157 https://code.videolan.org/videolan/vlc/-/blob/master/src/network/stream.c#L129

Looks like it actually gets past the call to vlc_tls_Write, but since it has the same issue within vlc_tls_Read and others, it eventually ends up waiting nonetheless.

vlc_https_headers_recv eventually calls that and wait indefinitely: https://code.videolan.org/videolan/vlc/-/blob/3.0.x/modules/access/http/h1conn.c#L57 called from the [b]vlc_h1_stream_wait[/b] callback method: https://code.videolan.org/videolan/vlc/-/blob/3.0.x/modules/access/http/h1conn.c#L183

https://code.videolan.org/videolan/vlc/-/blob/3.0.x/src/network/tls.c#L228

readv fails, but errno is typically EAGAIN (WSAEWOULDBLOCK from recvmsg on Windows)) constantly so it never errors out, and there is nothing else to cause it to timeout or stop until stopped from the player.

Unfortunately i do not understand the vlc object model enough to know what method would even be available at this point in these methods in order to gain access to the timeout variable values.

Looks like neither the HTTP nor the HTTPS access plugins handle the timeout option consistently in all cases.

The information presented so far appears to be related to the way the HTTPS access plugin attempts to handle accessing an HTTP connection. Currently it will not properly timeout in some cases. i hardcoded the timeout check in a manner similar to that used elsewhere and this allowed it to eventually timeout.

But then the HTTP access module makes an attempt next.

On connect it initially makes an attempt to use the timeout: https://code.videolan.org/videolan/vlc/-/blob/3.0.x/src/network/tcp.c#L141

Called from here: https://code.videolan.org/videolan/vlc/-/blob/3.0.x/modules/access/http.c#L711

The problem technically is that it appears it is not the initial write/connect that is the issue, but the attempt to read/gets afterwards. As stated above the vlc_tls_* methods do not attempt to make use of the configured timeouts, but outside of the net_ConnectTCP method, similar to the tls methods, the net_Read, net_Write, and net_Gets do not make any use of the configured timeouts either.

The call here also ends up blocking: https://code.videolan.org/videolan/vlc/-/blob/3.0.x/modules/access/http.c#L732

But luckily i believe the default timeouts take effect and it eventually exits the net_Gets method after about 30 seconds instead of getting stuck indefinitely.

i have not tracked back to see if any attempt is ever made to configure the timeouts on the socket itself.