CGI Programming / Scripts Interview Preparation Guide

CGI stands for Common Gateway Interface, and is a mechanism through which a browser is allowed to communicate with programs running on a server. If you look at each word in turn it makes more sense -

► Common - something that is available to many people, regardless of what software they are using.
► Gateway - a portal through which two things communicate. In this case, the browser communicates to the server.
► Interface - this implies that we are providing a "front end" for the application running on the server, which is exactly what it is. You enter information in the form, for example, and this is submitted to the program, just like a windows-style program.

Perl is an interpreted language (not compiled, like Java) which is ideally suited for CGI programming. It has its roots in Unix system administration and offers several features like regular expressions and file manipulation which make it extremely powerful. It is learning curve has been described as long and shallow. It is very easy to pick up at first, especially if you are at all familiar with Unix. However, it does take quite a bit of time to become familiar with all the little nuances of the language. For most CGI work, however, these little nuances are not really necessary.

APIs are proprietary programming interfaces supported by particular
platforms. By using an API, you lose all portability. If you know
your application will only ever run on one platform (OS and HTTPD),
and it has a suitable API, go ahead and use it. Otherwise stick to CGI.

A compiled language is written and then run through a compiler which checks its syntax and compresses it into a binary executable. Since an interpreted language is not compiled, it must be checked for errors at run-time, which makes it quite a bit slower than a compiled language (like C or Java). Perl is an example of an interpreted language. Remember, though, that just because a language is interpreted does not necessarily mean it is not full-featured, or simplistic. Perl can get very complex and very cryptic, very quickly.

CGI and JAVA are fundamentally different, and for most applications are NOT interchangable.

CGI is a protocol for running programs on a WWW server. Whilst JAVA can also be used for that, and even has a standardised API (the servlet,
which is indeed an alternative to CGI), the major role of JAVA on the Web is for clientside programming (the applet).

In certain instances the two may be combined in a single application:
for example a JAVA applet to define a region of interest from a geographical map, together with a CGI script to process a query for the area defined.

CGI is important whenever you want to retain state information about a user, or run an application which communicates with the server. Things like guestbooks, Chat clients, database applications, and counters all rely on CGI. CGi opens up a world of possibility and enables you to do things that just are not possible with a totally client-side approach like JavaScript.

It depends on which version of the question you asked.

Yes, we can use CGI to trigger the browser's standard Username/Password dialogue. Send a response code 401, together with a "WWW-authenticate"
header including details of the the authentication scheme and realm:
e.g. (in a non-NPH script)

Status: 401 Unauthorized to access the document
WWW-authenticate: Basic realm="foobar"
Content-type: text/plain
Unauthorised to access this document
The use you can make of this is server-dependent, and harder,since most servers expect to deal with authentication before ever reaching the CGI (eg through .www_acl or .htaccess).
Thus it cannot usefully replace the standard login sequence, although it can be applied to other situations, such as re-validating a user -
e.g after a certain timeout period or if the same person may need to login under more than one userid.

What you can never get in CGI is the credentials returned by the user.
The HTTPD takes care of this, and simply sets REMOTE_USER to the username if the correct password was entered.

This question has been asked a few times so I felt it was time to include it in the FAQ. The only way to pass information from the client-side (in the JavaScript variable) to the server-side (the Perl program) is through the CGI. Since a CGI application is stateless, it does not remember anything about how it was last called between invocations. Once it stops running, all its variables are forgotten. In order to submit information to a CGI script from a JavaScript variable, you must dynamically create a URL pointing to the CGI program which submits your JavaScript variable. Your CGI script must be set up to respond to submissions using the GET method, since this is the only one you can use when submitting a variable as part of a URL. Take a look at the following bit of code:

var firstname = 'Smith'; // JavaScript variable containing firstname

var URL = eval('http://www.server.com/cgi-bin/script.pl?firstname=' + firstname);

document.location.href = URL;

and when your script is run (because of the document.location.href statement), your script will have access to the firstname variable.

Yes, but think carefully first: How are your readers going to know
that their "submit" has succeeded? They may hit 'submit' many times!

The correct solution according to the HTTP specification is to
return HTTP status code 204. As an NPH script, this would be:

#!/bin/sh
# do processing (or launch it as background job)
echo "HTTP/1.0 204 No Change"
echo

A CGI bin directory is a special directory on the server where CGI scripts are allowed to be executed. Most servers are configured to only allow CGI scripts to be executed from one location, in order to minimize security holes. Poorly written scripts can wreak havoc on a server if allowed to run unchecked - most system admins will want to verify that the script is not doing anything malicious before letting you run it.