1 / 14

Internet Server Group

Andrew Kozarik - CGI Brandon Zarzoza- C# Chris Young- Perl Lawrence M. - Python John Hall - JSP. Ray Skoog- TCL Chad Stadig- SSI Scott Kircher- PHP John Alexander - Cold Fusion. Internet Server Group. Introduction to CGI.

kirkan
Download Presentation

Internet Server Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Andrew Kozarik - CGI Brandon Zarzoza- C# Chris Young- Perl Lawrence M. - Python John Hall - JSP Ray Skoog- TCL Chad Stadig- SSI Scott Kircher- PHP John Alexander - Cold Fusion Internet Server Group

  2. Introduction to CGI • The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. It is not a programming language. • For example, let's say that you wanted to "hook up" your Unix database to the World Wide Web, to allow people from all over the world to query it. Basically, you need to create a CGI program to interface with the database, and display the results to the client. This is an example of a gateway, and this is where CGI got its origins. • There really is no limit as to what you can hook up to the Web. The only thing you need to remember is that while the CGI is being used to access information the user will just be staring at their browser waiting for something to happen. The whole time a program is executing on your server using resources.

  3. How does it work? • A CGI program can be written in any language that allows it to be executed on the system, such as: • C/C++ • Fortran • PERL • TCL • Any Unix shell • It just depends what you have available on your system. If you use a programming language like C or Fortran you must compile the program before it will run. If, however, you use one of the scripting languages instead, such as PERL, or a Unix shell, the script itself will be executed since there is no associated source code. Many people prefer to write CGI scripts instead of programs, since they are easier to modify, and maintain than a compiled program.

  4. The interface • The system is fairly simple, first the client requests a document the daemon on the server calls the CGI which interfaces with a program or script on the server the response is then sent back to the client through the CGI.

  5. CGI Applications • Forms • One of the most prominent uses of CGI is in processing forms. Forms are a subset of HTML that makes Web browsing an interactive process for the user and the provider. Forms can be used to collect information from the user. But they can also be used in a more complex manner to provide back-and-forth interaction.

  6. CGI Applications • Gateways • Web gateways are programs or scripts used to access information that is not directly readable by the client. You can use a language such as a DBI extension to Perl to form SQL queries to read the information contained within the database. Once you have the information, you can format and send it to the client. In this case, the CGI program serves as a gateway to the database • Virtual Documents • Virtual, or dynamic, document creation is at the heart of CGI. Virtual documents are created on the fly in response to a user's information request. You can create virtual HTML, plain text, image, and even audio documents.

  7. The CGI request • When a user opens a URL associated with a CGI program, the client sends a request to the server asking for the file. • For the most part, the request for a CGI program looks the same as it does for all Web documents. The difference is that when a server recognizes that the address being requested is a CGI program, the server does not return the file contents verbatim. Instead, the server tries to execute the program. Here is what a sample client request might look like: • GET /cgi-bin/welcome.pl HTTP/1.0 • Accept: www/source • Accept: text/html • User-Agent: Lynx/2.4 libwww/2.14 • From: shishir@bu.edu • This GET request identifies the file to retrieve as /cgi-bin/welcome.pl. The string HTTP/1.0 identifies the communication protocol to use. The client request also passes the data formats it can accept, identifies itself as a Lynx client, and sends user information. All this information is made available to the CGI program.

  8. Passing parameters • CGI does not use the command line to send options to the program to be executed. Instead it uses environment variables to send parameters to the program. There are 22 environment variables in the current CGI standard. The two major variables used are: • QUERY_STRING which is defined as anything that follows the first ? In the URL. • PATH_INFO which can be used to pass extra path information to the gateway that will help locate the document that the application the CGI will operate on.

  9. Query Strings • One way to send form data to a CGI program is by appending the form information to the URL, after a question mark. You may have seen URLs like the following: http://some.machine/cgi-bin/name.pl?fortune • The information after the "?" character is known as a query string. When the server is passed a URL with a query string, it calls the CGI program identified in the first part of the URL and then stores the part after the "?" in the environment variable QUERY_STRING. The following is a CGI program called name.pl that uses query information to execute one of three possible UNIX commands. • #!/usr/local/bin/perl • print "Content-type: text/plain", "\n\n"; • $query_string = $ENV{'QUERY_STRING'}; • if ($query_string eq "fortune") { print `/usr/local/bin/fortune`; } • elsif ($query_string eq "finger") { print `/usr/ucb/finger`; } • else { print `/usr/local/bin/date`; } • exit (0); • You can execute this script as either: • http://some.machine/cgi-bin/name.pl?fortune • http://some.machine/cgi-bin/name.pl?finger • or http://some.machine/cgi-bin/name.pl, and you will get different output.

  10. Returning data to the client • CGI programs can return a myriad of document types. They can send back an image to the client, and HTML document, a text document, or perhaps even an audio clip. They can also return references to other documents. The client must know what kind of document you're sending it so it can present it accordingly. In order for the client to know this, your CGI program must tell the server what type of document it is returning. • In order to tell the server what kind of document you are sending back, whether it be a full document or a reference to one, CGI requires you to place a short header on your output. This header is ASCII text, consisting of lines separated by either linefeeds or carriage returns (or both) followed by a single blank line. The output body then follows in whatever native format. • Today's browsers are smart enough to automatically generate the document with the proper formatting if a header is used.

  11. How do I access it? • <!--#exec cgi="/scripts/textcounter.pl"--> • To use this Perl script in a web page the preceding statement would be inserted into the HTML source code of the page. The CGI would then use that statement to run the proper Perl script and replace the statement with dynamically generated HTML code like that below. This would all happen without the knowledge of the user of the web page. • <a href="http://www. doofus.com/scripts/textcounter.shtml"> 16608 </a> hits since 04/29/2001 • Final browser output: “16608 hits since 04/29/2001”

  12. Security • Security is a big issue for servers using CGI and SSI as it allows a client to request that a program be run on the server machine and this is easily abused. As CGI has evolved there have been improvements to the security in each new version of the draft.

  13. Conclusion/The Future of CGI • CGI is in my opinion one of the most important elements of the internet. It adds the possibility of dynamic and platform independent content to the internet. Most server side programming is dependant on CGI to exchange information between the client and server. • Like all tools in the information world the CGI is constantly evolving and improving. Currently security is one of the main issues as people are constantly finding new ways to abuse the ability to run a program on the server machine using CGI.

  14. The CGI Resource Index http://cgi.resource index.com Common Gateway Interface - RFC Project page http://CGI-Spec.Golux.Com/ CGI Scripts for fun and profit http://hotwired.lycos.com/webmonkey/99/26/index4a.html References

More Related