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

[Thomas Guillem]

> 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.

I meant 10seconds between 2 consecutive httpd_ClientSend() that succeed.

> That would timeout with previous versions just the same. Not like the timeout 
> changed in recent years.

And yet, this bug is appeared with your recent changes, however I do think your changes are correct.

I think I understand the reason. By default, delay is -1, that mean an infinite timeout from poll.
Once the chromecast is ready to read, poll returns (in the current situation with delay = -1 it can return after 20sec for example), then httpd_ClientSend() succeed and then, 2 choices:
 - activitiy_date is updated before checking the timeout (before your patches): OK, we didn't kill a client that timeouted for more than 10secs. I think it's a bug
 - activitiy_date is updated after checking the timeout (after your patches); KO, but we could have killed this client after 10seconds instead of waiting to a socket event from poll.


> That's the only DoS mitigation. Practicaly all webservers have an 
> aggressive timeout between requests also, for the same reasons.

I understand the need for such protection.

My patch set is only touching the chromecast.
I guess Laurant Aimar encountered this issue with RTSP some long time ago, cf. bb309602fb6d77be0650a4bcfc4c80270352d780

I'm proposing a new patch set fixing the timeout handling from poll.

On Wed, Oct 28, 2020, at 11:59, Rémi Denis-Courmont wrote:
> Le keskiviikkona 28. lokakuuta 2020, 12.51.52 EET Alexandre Janniaux a écrit :
> > > 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.
> > 
> > Isn't chromecast single-client only?
> 
> I don't know. What does it matter here anyway? The HTTPd instance is shared by 
> all HTTP clients. So, for instance, Chromecast and the HTTP interface are 
> handled in the same instance and thread.
> 
> -- 
> レミ・デニ-クールモン
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel