[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection
thomas at gllm.fr
Wed Oct 28 13:35:33 CET 2020
> 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.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel