Alan said:
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 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).
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.