[ale] Uploading to a web page

Greg runman at telocity.com
Wed Feb 6 15:15:15 EST 2002


Ummm, well, first of all, the "de facto standard for sending data from a
browser is NOT CGI ... it is http (HyperText Transfer Protocol), which came
from SGML.  CGI or Common Gateway Interface has nothing to do with clients
or browsers, it is a "common environment and a set of protocols for external
applications (ie, Perl) to use while interfacing with the Web SERVER".  It
is the first way that 3rd generation web worked (First generation - plain
text, 2nd generation - HTML, 3rd generation - make server do stuff) to
process data base interactions, calculations, logic based processes on the
server.  Now the server can do more than just serve up pages like a
glorified file server.  The web server is still responsible for getting info
to and from the browser (client).  CGI just allows the web server to use
other applications (ie run Perl scripts or compiled code).  Browser supplied
info is sent using GET (using the environment variable QUERY_STRING) is sent
by the browser and POST is sent directly from browser (via http) to the
server and there through the servers STDOUT to the script's STDIN.  Another
way of loosly looking at it is that CGI is a socket.

The problems with CGI are several and they have mainly to do with
scalability and security.
1. A web server creates a new process for each and every CGI request.  This
results in a loss of response time because the server must create and
initialize a new address space for EVERY process.  Plus you may run out of
processes.  Many servers are configured to have only  finite # of processes.
2. Perl - though common, it forces the server to start a new interpreter for
every request. This takes longer to do than compiled code and eats more
resources.
3. CGI runs in a completely separate process than a the web server.  If a
client submits a request to a CGI program that terminates before responding
to the Web server, the browser has no way of knowing what happened - it just
sits there until it times out.
4. Heaps of security problems - look at a security site and look up "CGI"

MY POINT is that using CGI is inefficient and insecure, and the language
that you use in your scripts is irelevant (though C  and C++ should be
faster).  Other API's have surpassed CGI.  New technologies only load 1
instance or a few (and use a service method to handle multiple requests -
look at MS MTS or Java for example), are more persistent, portable (except
for proprietary technologies), robust, extensible and secure.  Of course
this leads to Application Servers and multiple tier architectures, of which
leave CGI in the dust.  Of course we can always load off stuff to the client
via java applets or some such technology.

Of course if none of the above factors are relevant to the business decision
makers then one can use CGI w/ pick-a-language.  No skin off my nose - but I
would hate to deal with the repercussions and I realize IT only "proposes
and others (PHB and mis-mgmt) disposes".

Also; as far as server side Javascript... well.... I can think of a dozen
other better things.. (and no, not CGI)....  And no, no language war jihad
here or a technology war either, but I hate for misinformation to propogate
on the list.

Greg Canter
-----Original Message-----
From:	Greg Sabino Mullane [mailto:greg at turnstep.com]
Sent:	Wednesday, February 06, 2002 1:12 PM
To:	ale at ale.org
Subject:	RE: [ale] Uploading to a web page


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> CGI is not the only server side technology, in fact it seems
> pretty much dead as other technologies place a lesser load on
> the server and are more secure and feature rich.

I think you are confusing CGI with something else. CGI is the
defacto standard used to send data from a browser to a
web server. It is independent of language. Programs that use
the CGI protocol have been written in every language imaginable,
including Perl, C, Java, scheme, you name it. Even "sh"! And yes,
even server-side Javascript.

> All are in my opinion easier than Perl

Ah, now I see the problem. Remember, Perl is not CGI. CGI is not
Perl. Perl happens to be an extremely popular language of choice
for CGI applications, but other than that, there is no relation
whatsoever.

If you meant that perl is "pretty much dead" as a CGI language,
this is just not true: the majority of the web's CGI scripts are
using perl. If you use mod_perl it is just as fast, if not
faster, than any other language out there.

Greg Sabino Mullane greg at turnstep.com
PGP Key: 0x14964AC8 200202061308

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iQA/AwUBPGFx+bybkGcUlkrIEQJs7QCg0oFtHO/B9C8JMzrBmGTMXBme000An0+P
cv1L2se2lq1ghM3GM3ARQcbN
=qFKK
-----END PGP SIGNATURE-----



---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.



---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.






More information about the Ale mailing list