Re: Perl 5 Classes for the Web (CGI and libwww)

Tim Bunce (Tim.Bunce@ig.co.uk)
Wed, 15 Mar 1995 11:47:04 +0000 

> From: Jack Shirazi - BIU <js@bison.lif.icnet.uk>
> 
> > The Mini-Server Concept:
> 
> > The job of the CGI::MiniSvr class is to allow a CGI application to
> > fork a new process, sit on a new socket and act as a basic server.
> > This allows a mini-server to be dedicated to a particular client.
> > The form returned by the CGI application prior to forking will contain
> > some links (generally form actions) that refer back to the specific
> > (private) mini-server socket port number. Others, such as images,
> > could still refer to the main server.
> >  
> > This approach avoids the need to implement complicated state
> > save/restore code and simplifies application coding. It also allows
> > database transactions to span multiple pages/forms. The CGI::MiniSvr
> > class validates the client host and has a built-in timeout mechanism.
> 
> My instant reaction is 'oh dear, I hope this does not take off'.
> As I'm sure you know, state information can be kept in hidden fields -
> and the 'complicated state save/restore code' should be extremely simple
> for the CGI developer if someone does a class for it.
> 
Care to tell me how hidden fields or external state servers will allow you
to rollback an Oracle database change made on a previous form ?

> The troubles with MiniSvr are that:
> 1. It scales very badly. One process hanging around per initial query
>    means that batches of queries will bring the server machine to its knees.

On the contrary, the process startup overheads of the traditional
approach have a much greater impact. The per-transaction cost of the
mini-server approach is very low. The first thing a collegue said when
I showed her the first prototype was "wow, that's fast!".

> 2. Many's the time I've sent off a www query, got the result and left it
>    for a long time before responding to it (sometimes overnight). How long
>    is the MiniSvr going to wait for?

That's an application choice. The default will probably be around 5 minutes.
Some applications may set it higher, some lower. Some may change it from
dynamically.

>    The longer it waits, the worse it gets
>    for the server machine. The shorter it waits, the more annoyed I (and
>    all its other clients) are going to get when we post back the form
>    only to get a 'Server not responding' message.

That's a tradeoff you have to make. It would be possible to have a field
on the form to allow a user settable timeout (within application limits).

> 3. Security of CGI bin scripts has a bad enough reputation at the moment.
>    This will make it worse.
> 
Why? Please explain in detail. Remember that the mini-server is started
by a full server which can deal with the 'big' authentication issues
and 'set the scene' before it starts the cgi script. I'm very happy to
add any checks as required but I need hard facts. The mini-server
already always re-validates the client ip address.

> If you are going to do this sort of thing, you might consider having a
> server process dedicated to a CGI script so that each time the script
> gets started up it connects to the server (which is on the same machine
> - validation is easy, you should use Unix sockets) and stores/retreives
> state with the server (the server can default to a disk file if you
> write the class nicely).  The server can be started uniquely (only one
> server existing), can timeout and dump its state to disk if needed, and
> restore on startup.
> 
That sounds fine and I look forward to the implementation. I'd probably
use it for some applications.

I have never said that the mini-server is a panacea. Quite the
opposite.  It's horses for courses. This is a horse that has some
mileage for me and my collegues right now. It may not be perfect but
it's simple, effective and here now. I'm releasing it to others in the
hopes that it might be useful to some people.

Other people will prefer other mechanisms.

Regards,
Tim.