CGI - The Common Gateway Interface

People use the internet everyday and they don't usually care how it works Under the Hood, nor should they. If you are in fact interested in internet technology, communications, computer programming or you are a software developer, web designer, IT manager or support person, then you might be interested in this article.

Free for developers and students:  SageAPI v1.0 API - Contains complete source code containing CGI tools for Linux and Win32 as well as Win32 binaries. Change i01_target.pp DEFINE compiler directive to your operating system type before attempting to compile the projects. You can use this library to experiment with writing your own CGI applications in FreePascal. The samples are pretty easy to make out - hopefully you don't need docs. Maybe you do what I did - study what it's doing - and write your own - it's really not that awful and forcing yourself to do it makes you understand the "protocol" alot better IMHO... without further adeiu...

Common Gateway Interface + Compiled FreePascal = FAST
-=- Benefits of CGI -=-
•Portable - Most Webservers Support CGI and you don't need to write a separate interface for each webserver you want your application to be compatible with.
•EZ Secure Sockets Layer - If the web server is using SSL, your CGI application does too!
•Secures Your Source Code - CGI mandates compiled binary code. (CGI PHP - is a compiled PHP program that is fired up, and THEN loads and runs your script)
•Secure - With proper configuration, CGI is not itself a security risk to your server(s).

-=- Drawbacks of CGI -=-
•Each Request Needs a Process - Creating processes takes Precious cpu cycles - however we are talking micro seconds on todays machines.
•Loading Time - It's not the Process creation that kills ya - its that the bigger your application, the slower your CGI application is!

-=- Workable Solution -=-
A workable solution would be one that...

•LOADS FAST!
•Retains Webserver Portability
•Retains SSL Piggy Back Ability
•Uses executable binaries - for execution speed far faster than scripts
•Allows making connections to databases and loading information prior to processing requests
Security Note
Though many say the fact that CGI SHELL's out is a security risk. I agree, however if you configure the webserver to only allow running CGI applications in directories that users of your webserver can not upload to, than there IS NOT a security issue with CGI. Your CGI application should also be written responsibly. (Research Validating fields from posted data, limiting data transfer size of http form posts and.or file uploads, SQL Injection Attacks)

Process Loading Time
Some complain about cgi because of the time it takes to fire up a PROCESS each request. Valid concern? Perhaps. But invoking a process seems to happen pretty quick these days IMHO.

The real trouble is, if you have a BIG CGI application to load in addition to creating the PROCESS/Shell... than yeah - the bigger they are the more they CRAWL! It gets worse when you consider most CGI applications that are use ful connect to a database(s) and you have to wait for all that communication in addition the the process and the execuable loading... oh and lest not forget the configuration files that may be needed as well as other tidbits that make CGI look awful from a loading standpoint.

DUDE - Make your POINT!
So what do you do about this? One attempt to get around the loading problem is/was a project named FASTCGI which in my opinion has the right ideas but it very difficult to code to and to implement on the webserver its modules. Frankly, the concept is DEAD ON and many have had success with it. The idea is/was to eliminate the time required to shell out a process by having your application preloaded and resident in memory all the time and the WebServer module/piece invokes your application's services via interprocess communication. I personally believe many more bruised their heads trying to figure it all out and get all the pieces working correctly etc. just to abandon it as WAY to cumbersome. For those who did get it working - they say its BLAZING fast! Compiled code, no scripting, no loading time for the executable - WOOHOO... No Brainer - except the getting it working part - Nightmare!

Will the Real Slim Shady Please Stand up already?
The Workable Solution in Practice
The solution that really works I call "Little Boy - Big Boy"because I needed an analogy to describe this whole thing to my wife when I was building it.

The Big Boy is your main application. This is where you load your configuration information, make your database connections, perform your applications duties each request etc. Note - this application should be multi-threaded to be able to recycle code, memory, data connections etc. and be able to simultaneously handle multiple requests.

The Little Boy application is actually the CGI application - and its job is to start, load the cgi environment and pass it to Big Boy, wait for a response and simple send the response back out to the webserver through the stdout pipe like all CGI applications do - handling timeouts appropriately in case the Big Boy isn't running or whatever - users eventually should get a timeout message.

I have already implemented such a system and it's pretty darn fast. It does not suffer from EXE SIZE DEMISE at ALL!

The first go around I used a home brew file paradigm for inter-process communication (IPC) and I eventually utilized Michael Van Canneyt's IPC unit which made things faster on Linux. In English? I have implemented two different ways the Little Boy and the Big Boy communicate and have plans for others; its fast now, and will only get faster!

I've been using this paradigm for a very long time and it has hosted 10's of thousands of serves through the years. Using this method I created a Real Estate Multiple Listing Service online service/database for my home state in Connecticut, USA - it worked faster than the http://www.realtor.com website which was/is run by the same people we were getting our property data from.

I've also used this same system to serve as a simple web page templating system with the ability to access native MySQL and ODBC data sources and using Search and Replace functionality that when all glued together - is like having true executable binary PHP, .Net, or ASP scripts or something... In English? It performs the same or faster than most mainstream software normally used to create web applications.

Allow me to digress... The system code has matured over the years and is well tested, solid, and fast. It it now the engine that drives the Jegas Application Server. It can run in either CGI mode using the Little Boy - Big Boy approach described above or it can be run as a standalone web server capable of running PHP, Perl and of course... drumroll please... CGI!

To wrap up:

•CGI is not Dead - Its been around a long time and almost every webserver software supports it.
•CGI is not Slow - You just have to design your CGI "system" thoughtfully.
•FreePascal and CGI are a PERFECT FIT! - CGI gives you webserver portability, FreePascal gives you binary execution speed over script and platform independance easier to maintain than C/C++ alternatives.
 

Jegas, LLC- Virtually Everything IT! _TM

• < Prev