NOTE: This information is relevant only for MacHTTP on Macintosh computers. While CGI applications exist for most platforms, the method of communication between CGI applications and the servers on various platforms differs so CGI applications cannot be used across platforms. There is one kind for Unix, another for Macintosh, and yet another for any other types of computers you might be using.
NetScape: I want to look at the page with the URL
http://www.uwtc.washington.edu/UWHome.html
MacHTTP: Ah! That's one of my pages. Here is all
the data from the URL you sent. I'm sending
it as text.
NetScape: Ah! I see the text begins with an HTML tag
that I recognize. I'll interpret this as HTML
then and display it correctly for my user.
MacHTTP: I couldn't care less how you display it. I'm
done dumping the data so goodbye.
As you can see, the client and the server both have their responsibilities
in the interaction. The server decides what the client is requesting and how
to feed it back to the client. The client decides what to do with what is
returned to display it for the user.
When the user requests a URL that involves a CGI application (like clicking on a map, submitting a form, or many other things), the interaction is a little different because there is also interaction between the server and the CGI. Let's take a look now at the conversation that might occur between a server and client when handling a map click (assuming they speak English, of course).
User: Hmmmm. A map of Washington state. There's a star in
the upper right-hand corner. I wonder what that's
for. Let's click on it.
NetScape: Let's see, that click was at 287,48. I'll add
that to the URL that was given with the map and
send it back to the server.
MacHTTP: Hey, someone sent me a URL with some extra data.
That URL is for a CGI application on this machine.
Well I'll just send an AppleEvent to that CGI
application with the data enclosed in the post_args
argument. I'm glad I don't have to do anything to
the data myself.
CGI app: Finally, an AppleEvent! Let's see, first I
decode the information in the post_args argument.
Now I can use these map click coordinates to figure
out what page to return to the client. Here it is -
I'll send the server an AppleEvent reply,
containing the URL for the new page and a code to
redirect the client to that page.
MacHTTP: Finally. I've been waiting for this AppleEvent reply.
This code says I should redirect the client to this
other page instead. I'll send back the new page then.
NetScape: Here comes another HTML page. Better display it
nicely for my user.
User: Republic, Washington? I've never even heard of that
place before!
Well, that was a bit long, but it should give you an idea of the
complex interactions that go on when you're using a CGI application. There
are a couple of important points to remember from the above nonsense:
Later, Chuck added the ability to run the CGI applications asynchronously. This meant that MacHTTP didn't have to wait uselessly while the CGI application ran. Instead, it passed an AppleEvent to the application then went on processing other things until a reply was received. To distinguish between the two, MacHTTP now recognizes two different file extensions. ".cgi" means the file should be handled synchronously and ".acgi" means to handle it asynchronously. The latter is almost always preferable (actually, I can't think of a reason not to use the asynchronous mode), but a well-written CGI application can run either way. The key is to remember that AppleEvents might be queued up in your CGI application while it is processing the current event. Therefore, you want to design the application so it doesn't quit immediately after processing an event or it might miss the next one. Instead, give it time to test to see if there is another event queued up.
After you have finished those lessons, you may want to take a look at a real-world solution using CGI applications, Form Processing.