Ans: The Common Gateway Interface, or CGI, is a standard for external gateway programs to interface with information servers such as HTTP servers. A plain HTML document that the Web daemon retrieves is static, which means it exists in a constant state: a text file that doesn’t change.
A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information.
Ans: 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 interchangeable.
Ans: 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.
Ans:
Ans: 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.
Ans: At First, in the CGI code, at it’s start, add “sleep (30);” This will cause the CGI to do nothing for thirty 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’s 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 doesn’t receive anything.
Ans: 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”.
Ans: 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.
Ans: 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.
Ans: 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.
Ans: The HTTPD takes care of this, and simply sets REMOTE_USER to the username if the correct password was entered.
Ans: Rigging is use for if we want to give animation for any object or character then we apply to character or object internal bone setting(like our bones) that is called rigging. When apply rigging, then we can give proper animation.
Ans: 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.
Ans:
Ans:
Ans: 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!
Ans: require CGI;
$escaped = CGI::escape( $normal );
# ...or...
sub escape {
my $str = shift || '';
$str =~ s/([^w.-])/sprintf("%%%02X",ord($1))/eg;
$str;
}
$escaped = escape( $normal );
Ans: 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:
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 itsetuid 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.