On Thu, Jul 29, 2010 at 09:58:30PM -0400, Steve Vinoski wrote:
> On Thu, Jul 29, 2010 at 9:07 PM, Hans-Christian Esperer
> <hc@...> wrote:
> > On Thu, Jul 29, 2010 at 06:43:31PM -0400, Steve Vinoski wrote:
> >> On Thu, Jul 29, 2010 at 6:27 PM, Claes Wikstrom <klacke@...> wrote:
> >> > On 07/29/2010 01:12 AM, Hans-Christian Esperer wrote:
> >> >> On Mon, Jul 26, 2010 at 07:12:46PM +0200, Hans-Christian Esperer wrote:
> >> >>> IMHO it'd be nice if one could limit the number of reductions and/or
> >> >>> maximum time a request is allowed to take per<server>. This could be
> >> >>> easily done by using a monitor process that regularily checks all
> >> >>> worker processes and kills rogue ones if necessary. This would work so
> >> >>> long as worker processes do not spawn more processes. It would also
> >> >>> work for websocket processes, since their PIDs are passed back to yaws
> >> >>> when created.
> >> >>
> >> >> Ok - here is my attempt to do it. The behaviour is controlled by four
> >> >> per-<server> configuration variables:-_
> >> >
> >> >
> >> > Hmm, I ... think this is a pretty strange config variable, what
> >> > does the list think?
> >> > As long as the client socket is alive and want things, well - it
> >> > want things. Also - it's really really easy to program this IMHO
> >> > odd feature on the side.
> >>
> >> Agreed. This seems like a fairly specialized feature that doesn't
> >> really need to be inside Yaws itself.
> >
> > About that feature being 'fairly specialized', I'd like to point you
> > to http://php.net/manual/en/function.set-time-limit.php
> >
> > PHP by default limits script execution time to 30 seconds.
>
> Sure, but that's PHP. Perhaps it's built in there because there's just
> no other good way to do it.
It is built into the language because this is the right place to do
it. Assuming this feature is desired, would you have it implemented
for every .yaws code fragment?
> If I may speak for Klacke, I think he and I are basing our opinions on
> the fact that 1) nobody else has ever asked for this in Yaws, and 2)
> as Klacke said, it's just as practical to handle it outside of Yaws.
Sure - if no one needs it, it's stupid to add it, I perfectly agree
with you.
I can only try to explain my reasons for wanting it: Imagine one yaws
server serving dozens of virtual hosts that are completely independent
of each other. They do not share cookies, they do not share SSL
certificates; they are essentially entirely different websites. They
are handled by one yaws and mnesia instance, and that's fine, because
both are rock solid. But now they can get arbitrarily "tainted" by a
single .yaws script that's ill-behaving, affecting all domains. I like
the idea of limiting the possible damage of this as much ass possible.
Another point is attacks. Imaging one writes a .yaws script that
calculates, say, the faculty of a number entered on the website. If an
attacker specifies a negative number and the script is badly
implemented, it will end up in an endless reduction. If an attacker
specifies an incredibly large positive number, the script will consume
a huge amount of time. If you do not have facilities in the server to
centrally limit processing time, the author of every .yaws file would
have to think about setting reasonable limits for every individual
file. If the site is later migrated to a more powerful system, there
would be no way to easily increase limits.
Speaking limits, I had planned to also try to limit the memory usage
for each yaws script somehow.
HC
|