The diagram and description below show what happens when the URL given to the browser is for one of your .cgi's. (A static HTML page (a web page on disk) is the entryway to your application for the user. It involves just a simple request/response interaction between the browswer and the web server to fetch that page, not all the mechanism below.)

1. The browser issues a request (either a GET or a POST HTTP request) for a .cgi. A GET might come from a link to the .cgi embedded in some other page; a POST from the submission of a web page containing a form.

2. The web server detects that a .cgi has been requested and so launches it.
   (Testing that you can install a .cgi and have it invoked from your browser is part of Milestone 1.)

3. Your .cgi needs some information, e.g., the set of items matching a given search request or the set of items for sale by a particular user. To obtain this information, your code issues a SQL request to the database server on bicycle.cs.washington.edu. The request indicates (a) the database you want to look in ("auction"), (b) the criteria you want the data to match (e.g., "name=bill"), and (c) what data you want back. (See this page for a high level overview of what the DB does.)
   (Querying the database is part of Milestone 3.)

4. The database server receives your request. If it is properly formatted, it searches the DB for records that match your criteria.

5. The DB returns the matching records to your .cgi.

6. Your program processes those items a bit, then reads a template HTML file. The template file is almost exactly the data to be returned to the browser. However, because it's static, it cannot contain the results of the DB lookup that you just obtained. So, your script uses a function that implements a kind of #define feature for the template file -- it substitutes results from the DB request for placeholder tokens in the template file.
   (The processing of the template files in this step will be implemented as Milestone 2.)

7. Having performed those substitutions, your code replies to the browser. It does this simply by printing -- the web server has set things up so that your code's standard output is connected back to the original browser.

   You print first an HTTP header indicating that everything went okay, then the result of performing the substitutions on the template text from the previous step.

Important Notes

• Your .cgi runs as the Unix user of the owner of the file. That means it can do anything you can do. Be careful with your code, as anyone anywhere in the world can cause your .cgi to be invoked.

• Your .cgi dies once it is finished returning all the data for the current request to the browser. That means you cannot save state (e.g., values in variables) in your .cgi and expect them to be there the next time it runs. They won't be.

  This induces a very odd flow control as the user moves from one of your pages to another. If there is any data you want to "pass" from the invocation of one page to the invocation of the next, you must pass it by (a) first giving it to the client, hidden in the HTML you've sent back from the first invocation, and (b) then providing it on the next request from the client by making it part of the POST data that is supplied with that request (or possibly a parameter attached to the URL).

  Examples of this are in the sample pages.