Posted by Toby Inkster on 08/28/05 21:44

Alan J. Flavell wrote:
> On Sat, 27 Aug 2005, Toby Inkster wrote:
>
>> CGI is a rather outdated mechanism for server-side programming.
>
> CGI specifies an application programming interface between a web
> server and a server-side process.
> The server-side process can be programmed in any language which is
> capable of supporting the interface specification.

I never claimed that the process couldn't be programmed in any language.

I was saying that the whole concept of the server dumping a bunch of data
into environment variable, spawning a new application (which may be
/usr/bin/perl or /usr/bin/sh or some other binary somewhere else on the
system), waiting for it to complete and then passing back the output is
inefficient. There are better ways of doing things.

> There's a wide range of choices (I'm told that there exist CGI
> processes programmed in COBOL, though I've never seen one myself).

Indeed. One of the first CGI programmes I wrote was in BASIC (classic, not
Visual).

All you really need is the ability to read environment variables and print
to STDOUT. Reading from STDIN is also handy if you want to accept POST
data.

>> It's inefficient. It spawns a whole new process for each page request.
>
> It's often implemented in that way, but where does the specification
> require that?

From your own reference (RFC 3875):

The server acts as an application gateway. It receives the request
from the client, selects a CGI script to handle the request, converts
the client request to a CGI request, *executes the script* and converts
the CGI response into a response for the client.

(my emphasis). The RFC specifies that the server should run an external
application (which it regretably refers to as a "script" even though this
application may be a compiled binary).

>> mod_php on the other hand is run in-process by the web server.
>
> Comparing chalk with cheese. PHP is a lot more than just a programming
> interface specification, and a lot less than a complete implementation
> which can support server-side code in any programming language.

True -- mod_php is, but the concept of having modules at all -- of
building the script interpreter (and in some cases the script logic
itself) right into the web server is a valuable one.

Example: if a web server accepts a large amount of POST data, under CGI it
must spawn another application (spawning a new process is generally an
CPU-expensive process in most operating systems) and feed all this
information to the other application via its STDIN. If the data
interpreter is *part* of the web server instead of an external
application, the server just does a function call (less expensive
operation) and passes the POST data by reference (uses less memory,
takes less time) rather than by value.

> CGI is very portable, on the other hand. This can be an overwhelming
> reason for choosing it, when other considerations aren't dominant.

I'll give you that. Backwards-compatible too.

But if one wrote an application for processing data in, say, C, and wrote
it with care, it could just be a matter of changing a few line in the code
before compilation time to choose to compile an Apache module or a
standalone binary that interfaces to Apache with CGI.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Now Playing ~ ./toad_the_wet_sprocket/ps/07_come_back_down.ogg

[Back to original message]