[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection

[Rémi Denis-Courmont]

Le keskiviikkona 28. lokakuuta 2020, 11.37.14 EET Thomas Guillem a écrit :
> On Wed, Oct 28, 2020, at 10:03, Rémi Denis-Courmont wrote:
> > Le keskiviikkona 28. lokakuuta 2020, 10.32.07 EET Thomas Guillem a écrit :
> > The HTTPd timeout has not changed in many years either. I don't know if it
> > even ever changed from the current 10 seconds value.
> 
> You just changed timeout handling with
> 67cdaeea58641d6d515728596f8b194f52538e2b.

No?

> I don't understand why you are not updating the activity date just after
> httpd_Client*() like it was done before (that is what Francois tried to fix
> in the first time)

"I" update the activity timestamp after processing non-blocking I/O *and* 
after processing timeout expiration, exactly as was done before, and as seems 
logical.

The order of polling and non-blocking I/O is reversed for reasons explained in 
the commit message, and has no meaningful effects on the timeouts.

> The Chromecast client will fill its internal buffer to the maximum when
> opening/seeking a file. This result on many read requests.

> Then, it will wait quite a long time before doing another read request.

You are making as little sense to me as the previous two times. There's no 
such things as "read requests" in TCP or HTTP 1.x.

If you mean [time between] consecutive HTTP messages, then that would cause a 
time-out already in previous versions. And removing that time-out is not an 
option. The 10 seconds inactivity timeout is very much intended there to save 
resources. That's the only DoS mitigation. Practicaly all webservers have an 
aggressive timeout between requests also, for the same reasons.

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