Auf deutsch (in German), as translated by
En español (in Spanish), as translated by René Alvarez
Em português (in Portuguese), as translated by Clay Chagas
In het Nederlands (in Dutch), as translated by Simon Amstel
So it's 4:00, your boss needs a CGI script written by 4:30, and you don't even know what CGI stands for. You've come to the right place.
There's not much to it, despite any intimidating hype you might have heard. If you can read from STDIN and write to STDOUT, then you can write CGI scripts. If you're a programmer already, this primer can teach you the basics of CGI in a few minutes. If you're not a programmer, this primer won't help you much-- sorry. Learn some programming, even shell scripting, and come back when you're done. Good luck!
This primer focuses on writing CGI scripts to process HTML forms on the Web. It skips some details, but can bring you up to speed fast (literally an hour or less), and covers 90% of real-world situations. When you feel the need, check out the full CGI spec. For help with writing HTML forms, see this tutorial fragment, or this documentation at NCSA.
Once you've read this page, see the footnotes for sample scripts and other topics.
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. Here's one in Perl, a simpler one in Perl, or one in C. 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, the long string is in one of these two formats:
So just split on the ampersands or semicolons, then on the equal signs. Then, do two more things to each name and value:
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.
- 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 "=".
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.
(If you're wondering about the difference between GET and POST, see the footnote discussing it. Short answer: POST is more general-purpose, but GET is fine for small forms.)
First, write the line
Content-type: text/htmlplus another blank line, to STDOUT. After that, write your HTML response page to STDOUT, and it will be sent to the user when your script is done. That's all there is to it.
Yes, you're generating HTML code on the fly. It's not hard; it's actually pretty straightforward. HTML was designed to be simple enough to generate this way.
If you want to send back an image or other non-HTML response, here's how to do it.
See how easy it is? If you still don't believe me, go ahead and write a script. Make sure to put the file in the right place on your server, and make it executable; see this footnote for more hints.
Before you write too many scripts, learn about CGI security issues.
Oh yeah, CGI stands for Common Gateway Interface-- in other words, a standard ("common") way of communicating ("interface") between different processes ("gateway", sort of).
See the Footnotes Page for the following stuff:
|Last Modified: April 12, 2002||http://www.jmarshall.com/easy/cgi/|