Re: CGI scripts

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Tue, 18 Oct 2011 08:53:51 +0300
Jukka Ruohonen <jruohonen%iki.fi@localhost> wrote:

> On Sun, May 08, 2011 at 03:55:23PM +0200, Peter Bex wrote:
> > > Embedding lua into bozohttpd is an enhancement to that program- also
> > > not an example.
> > 
> > Indeed.  It's an alternative to using CGI.  The system would still
> > provide example embedded lua scripts, and possibly some CGI ones
> > (or maybe just some shell CGI scripts)
> 
> Returning to this old thread. The goal of "bozohttp" is: "to be simple and
> relatively featureless, hopefully increasing its security". So why not rewrite
> the whole thing in Lua?

That wouldn't be bozohttpd anymore, would it? :)

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:

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

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

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

If an application server, an API should probably also be available for
application scripts to easily deal with details such as simple database
access and/or shared memory objects access (ideally without needing to
care about the mutexes), and dynamic resource handler functions should
have easy access to the current request's session/cookie/post/get tables
(with ideally some support to ease dealing with the odd multipart POST
form, which is needed to upload binary files).  With an easy way to
send HTTP replies with custom headers, some buffering for the custom
content output, and maybe a simple template system to avoid the
xml/html in strings mess...  Decisions have to be taken on how to deal
with the scripts (load them all at application startup, reload/update
at SIGHUP; or check if a file was modified since the last load, in
which case it's reloaded; should dynamic handlers be files (i.e. ap-php
style) or functions in an already loaded program, with htdocs only
containing static files and a table for resource/function mapping, etc).

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

Thanks,
-- 
Matt