Re: CGI scripts

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

On Tue, Oct 18, 2011 at 04:00:14AM -0400, Matthew Mondor wrote:
> That wouldn't be bozohttpd anymore, would it? :)

Sure it would be; AFAIR, "bozohttpd" was originally written in Perl.

> Since I implemented various daemons in various languages (including
> HTTPDs), a few questions to establish what is really wanted/needed,
> before one decides to write another one:

This is nice write-up about general, high-peformance, HTTP servers --
nothing that httpd(8) is even trying to be, as far as I understand it.

> - Is bozohttpd currently unsuitable for the future base-system use
>   cases that are being planned?  Could a Lua-written HTTPd more
>   gracefully deal with the needs and justify the writing of an HTTPd
>   with it?  Would a C daemon still be needed anyway to deal with Lua's
>   lack of longjmp or other needed control features?

httpd(8) does not use longjmp(3) nor is it needed for it.

> - In terms of goals, should it be a front-end static+proxying HTTPd
>   (i.e. akin to nginx or lighttpd), or an application server (i.e.
>   apache, tomcat, etc)?  If the former, non-blocking sockets with
>   libevent or kqueue should probably be used, with mmap usable to serve
>   static content, and the model would probably be single-threaded,
>   single-process; and nginx is already a mature BSD-licensed solution
>   for this.

httpd(8) is not a proxying HTTPd nor is it an application server. It uses
poll(2) and inetd(8), which are both fine for what it is trying to be.

> - If an application server, should it use a processes pool sharing the
>   least possible, or should every application launch a multithreaded
>   lua instance using a pool of threads?  Can Lua handle a long-running
>   multithreaded instance?  Will a C daemon be needed anyway to manage
>   the pool and ensure to restart any potentially crashing component?
>   Would using Apache with a mod_lua, or bozohttpd with a fast-cgi style
>   feature to which lua can connect be best anyway?

httpd(8) is not multi-threaded nor should it be.

> Despite being written in an interpreted language, care should be taken
> to observe input timeouts, and
> application-specific/vhost-specific/global limits such as number of
> requests to serve concurrently, input query buffer size, POST maximum
> size, etc, gracefully; security is of course not a general guarantee
> because an interpreted language is used instead of C...  The language's
> reliability is also important if using a long-lived multithreaded
> model, and it must not leak (the processes pool model is more resilient
> here, but less efficient with shared resources).

I think Lua would achieve better the two stated goals: simple and secure.

- Jukka.

PS. I like httpd(8) and also use it. But if I'd need a full-blown HTTPd,
    I can get one from pkgsrc.