URLS used to gather information:
By Searching: http://search.cnet.com/ to start with
For Administration: http://www.zeus.co.uk/products/zeus1/docs/guide/admin/
For Dynamic Doc API: http://www.zeus.co.uk/products/zeus1/docs/guide/features/sockd.html
For Tutorial: http://www.utoronto.ca/webdocs/CGI/cgi2.html
For related Resources: http://www.cgi-resources.com/
For Related Articles: http://www.cgi-resources.com/Magazine_Articles/
CGI is not a language. It's a simple protocol that can be used to communicate between Web forms and your program. A CGI script can be written in any language that can read STDIN, write to STDOUT, and read environment variables, i.e. virtually any programming language, including C, Perl, or even shell scripting. Normally HTML pages are static files that are prepared by their authors, and retrieving the page always yields the same information. The WWW would be extremely limited and boring if this was the limit of its functionality. Luckily it is not, it is possible to produce pages that are dynamically created; their content being different every time, maybe depending upon input from the client or from some external source.
Such pages are created by CGI scripts. These are programs written by the organization producing the web server content, normally in scripting languages such as Perl or sh, or compiled languages such as C.
CGI scripts can be used to process input data submitted from a HTML form and produce an appropriate response in return. Such an example might be an online shopping system whereby customers enter their credit-card details, the items they wish to purchase and their address. The CGI scripts might then go and validate the data submitted by the client, connect to some back-end database system to check whether such products are in stock, and if so to allocate them to the customer and send a dispatch order to the sales department. Another CGI might then produce a HTML page as a response to the client confirming the success of the order, the amount that was debited off their credit-card and the expected delivery date.
They are not just restricted to form input however. CGI scripts can be used in any part of the page makeup, in fact their use is only limited by your imagination (and time!).
The requirements for a CGI script are pretty simple, and in the following sections we provide from simple examples to help guide you through the process of creating your own.
Here's the typical sequence of steps for a CGI script:
The first and last steps are described below.
When the user submits the form, your script receives the form data as a set of name-value pairs. The names are what you defined in the INPUT tags (or SELECT or TEXTAREA tags), and the values are whatever the user typed in or selected. (Users can also submit files with forms, but this primer doesn't cover that.)
This set of name-value pairs is given to you as one long string, which you need to parse. It's not very complicated, and there are plenty of existing routines to do it for you. For a more elaborate CGI framework, see Perl's CGI.pm module. The CGI directory at Yahoo includes many CGI routines (and pre-written scripts), in various languages.
If that's good enough for you, skip to the next section. If you'd rather do it yourself, or you're just curious, here's the format of the long string:
"name1=value1&name2=value2&name3=value3"
So just split on the ampersands and equal signs. Then, do two more things to each name and value:
- Convert all "+" characters to spaces, and
- Convert all "%xx" sequences to the single character whose ascii value is "xx", in hex. For example, convert "%3d" to "=".
This is needed because the original long string is URL-encoded, to allow for equal signs, ampersands, and so forth in the user's input.
So where do you get the long string? That depends on the HTTP method the form was submitted with:
- For GET submissions, it's in the environment variable QUERY_STRING.
- For POST submissions, read it from STDIN. The exact number of bytes to read is in the environment variable CONTENT_LENGTH.
-------------------------------
Introduction to The Common Gateway Interface
Copied from URL: http://www.utoronto.ca/webdocs/CGI/cgi2.html
[Top] [JDBC and ODBC] [Java Servlets]
.............. Introduction to CGI
2. Server Processing of Passed Data: Gateway Programs
Sending data to the server is one thing, but in most cases the server cannot itself process the data -- most HTTP server program are designed only to serve out documents, and are not designed to process data sent from a client. Therefore, if you want to do server-side processing of the data sent from a fill-in HTML FORM (or by any other mechanism), you need three things:
- a second program to do process the data sent by the client,
- a mechanism by which the server can forward the data to this second program. Such secondary programs are called gateway programs, because they act as a gateway between the Web and other resources on the HTTP server machine, such as databases
- a way whereby this second program can return data to the client, so that the gateway program can return results of its analysis to the user.
An example of this flow of information is shown in the attached figure -- the arrows show the flow of data, while the small ovals straddling the lines show the protocols and mechanisms by which the data are communicated from client(browser)-to-server-to-gateway and back again.
See Figure Figure: Flow of Data to Gateway Programs
This Figure illustrates the flow of data when a user accesses a CGI program. The solid line shows to data flow using HTTP and CGI. HTTP transfers data from the client to the HTTP server, and back again. The CGI mechanisms control the flow of data from the server to the gateway program (shown as the prism) and back again. These are called gateway programs because they generally act as gateways between the World Wide Web and server-side resources such as databases, feedback forms, clickable imagemaps, and so on.
[Top] [JDBC and ODBC] [Java Servlets]
.............. Introduction to CGI