CGI Programming / Scripts Interview Questions And Answers

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.

At First,in the CGI code, at it is start, add "sleep(30);". This will cause the CGI to do nothing for thiry seconds (you may need to adjust this time). Compile the CGI with debuging info ("-g" in gcc) and install the CGI as normal. Next, using your web browser, activate the CGI. It will of course just sit there doing nothing. While it is sleeping, find it is PID(ps -a | grep <cgi name>). Load your debugger and attach to that PID("attach <pid>" in gdb). You will also need to tell it where to find the symbol definitions ("symbol-file <cgi>" in gdb). Then set a break point after the invocation of the sleep function and you are ready to debug. Do be aware that your browser will eventually timeout if it does not receive anything.

Generally, scripts are only several lines of code which do some useful function that would be overkill to write in a full-featured language. With Perl, you can go either way. You can write Perl scripts and Perl programs. Larry Wall (the creator of Perl) once said "You can write Perl programs, and you can write C scripts. More people talk about Perl programs than C scripts, so I guess that means Perl is more versatile".

Yes. Period.
There is a lot you can do to minimize these.

You need to configure the server to recognise .exe files as cgi, then you just point your browser to the URL as normal..

Here is the answer for Apache, the most popular server on the internet.

Edit the file [srm.conf] to contain, either:

AddHandler cgi-script .exe

or:

ScriptAlias /cgi-bin/ /some/real/path/to/your/cgi_s/

In both cases, you also need to check the [access.conf] file, to make sure that CGIs are "allowed" in those directories. eg...

<Directory /some/real/path/to/your/cgi_s>
AllowOverride None
Options ExecCGI
</Directory>

The scriptalias is the prefered and safest way to do this, as it is easier to manage the access rights on the cgi-bin. That way only trusted users can publish executables, while still allowing the static content of the site to be updated by mortals that are prone to accidents.

For permanent and simple redirection, use the HTTPD configuration file:
it is much more efficient than doing it yourself. Some servers enable
you to do this using a file in your own directory (eg Apache) whereas
others use a single configuration file (eg CERN).

For more complicated cases (eg process form inputs and conditionally
redirect the user), use the "Location:" response header.
If the redirection is itself a CGI script, it is easy to URLencode
parameters to it in a GET request, but dont forget to escape the URL!

Try:

#! /usr/bin/perl -w

use CGI qw(:cgi);

my $q = CGI->new();
my $cookie = $q->cookie(
-name => 'yummy_cookie',
-value => 'chocolate chip',
-domain => '.globalguideline.com',
-expires => '+10d',
-path => '/'
);
print $q->redirect(
-url => 'http://www.globalguideline.com',
-cookie => $cookie
);

__END__

If you leave out the "-domain", and "-path", then they will default to current values. The above example will be returned to all servers in the irt.org domain.

If you leave out the "-expires", then the cookie will expire when the user closes their browser. The above expires after 10 days.

There are innumerable caveats to this answer, but basically any
Webpage containing a form will require a CGI script or program
to process the form inputs.

Try This:

require CGI;
$escaped = CGI::escape( $normal );

# ...or...

sub escape {
my $str = shift || '';
$str =~ s/([^w.-])/sprintf("%%%02X",ord($1))/eg;
$str;
}
$escaped = escape( $normal );

► Object Oriented means programme will be their in terms of Class and Object relationship will be their.
► Structured Oriented Means programme will be their in terms of multiple Functions.

The distinction is semantic. Traditionally, compiled executables
(binaries) are called programs, and interpreted programs are usually
called scripts. In the context of CGI, the distinction has become
even more blurred than before. The words are often used interchangably
(including in this document). Current usage favours the word "scripts"
for CGI programs.

The distinction is semantic.Traditionally, compiled executables(binaries) are called programs, and interpreted programs are usually
called scripts.In the context of CGI,the distinction has become even more blurred than before.The words are often used interchangably
(including in this document).Current usage favours the word "scripts" for CGI programs.

(1) Several CGI programming libraries offer powerful interactive
debugging facilities. These include:

- for Perl, Lincoln Stein's CGI.pm
(now part of the standard Perl distribution)

- for Tcl, Don Libes' cgi.tcl
http://expect.nist.gov/cgi.tcl

- for C++, Nick Kew's CGI++
http://www.webthing.com/cgiplusplus/

(2) Nathan Neulinger's cgiwrap is another package with debugging aids.
http://www.umr.edu/~cgiwrap/

(3) The "mod_cgi" Apache module (new with Apache 1.2) enables you to
capture script output and errors for diagnosis.

No, but it helps. The Web, along with the Internet itself, C, Perl,
and almost every other Good Thing in the last 20 years of computing,
originated in Unix. At the time of writing, this is still the
most mature and best-supported platform for Web applications.

CGI scripts are run by the HTTPD, and therefore by the UID of the HTTPD
process, which is (by convention) usually a special user "nobody".

There are two basic ways to run a script under your own userid:
(1) The direct approach: use a setuid program.
(2) The double-server approach: have your CGI script communicate
with a second process (e.g. a daemon) running under your userid,
which is responsible for the actual file management.

The direct approach is usually faster, but the client-server architecture
may help with other problems, such as maintaining integrity of a database.

When running a compiled CGI program (e.g. C, C++), you can make it
setuid by simply setting the setuid bit:
e.g. "chmod 4755 myprog.cgi"

For security reasons, this is not possible with scripting languages
(eg Perl, Tcl, shell). A workaround is to run them from a setuid
program, such as cgiwrap.

In most cases where you'd want to use the client-server approach,
the server is a finished product (such as an SQL server) with its
own CGI interface.
A lightweight alternative to this is Don Libes' "expect" package.

The most usual (but browser-dependent) way to do this is to set a cookie.
If you do this, you are accepting that not all users will have a 'session'.

An alternative is to pass a session ID in every GET URL, and in hidden
fields of POST requests. This can be a big overhead unless _every_ page
requires CGI in any case.

Another alternative is the Hyper-G[1] solution of encoding a session-id in
the URLs of pages returned:
http://hyper-g.server/session_id/real/path/to/page
This has the drawback of making the URLs very confusing, and causes any
bookmarked pages to generate old session_ids.

Note that a session ID based solely on REMOTE_HOST (or REMOTE_ADDR)
will NOT work, as multiple users may access your pages concurrently
from the same machine.

[1] Actually I don't think that's been true of Hyper-G since sometime
in '96. However, general advances in web server technology, such as
Apache's mod_alias or mod_rewrite, make it straightforward without
the need for CGI.