[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CGI scripts
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.
PS. I like httpd(8) and also use it. But if I'd need a full-blown HTTPd,
I can get one from pkgsrc.
Main Index |
Thread Index |