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 -
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 me Perl is more versatile".
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.
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.
Yes. Period.
There is a lot you can do to minimize these.
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.
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.
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.
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.
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 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.
If you're already a programmer,CGI is extremely straightforward, and just three resources should get you up to speed in the time it takes to read them:
If you're NOT already a programmer, you'll have to learn. If you would find it hard to write, say, a 'grep' or 'cat' utility to run from the commandline, then you will probably have a hard time with CGI. Make sure your programs work from the commandline BEFORE trying them with CGI, so that at least one possible source of errors has been dealt with.
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.
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 );
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.
There are innumerable caveats to this wer, but basically any Webpage containing a form will require a CGI script or program to process the form inputs.
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.
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.
No - you can use any programming language you please. Perl is simply today's most popular choice for CGI applications. Some other widelyused languages are C, C++, TCL, BASIC and - for simple tasks -even shell scripts.
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 2@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
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!
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.