Lessons by Jon

Extending MacHTTP

So, you've got your server installed and running, and that was exciting. You sat for hours watching addresses from around the world pop up on your log window and perhaps one of them even wrote back to thank you for the excellent information on Hoover vacuum cleaners. In all, you're mostly satisfied. But somewhere deep inside a nagging feeling is developing; a feeling that there was supposed to be...well, something more.

MacHTTP is a great server, but that's all it can do - serve. It will serve a wide variety of files, but it doesn't do anything special with them. In order to have any kind of interaction with the user, you need to create applications that will work with MacHTTP to extend its capabilities. These applications are responsible for things like maps, online forms, document and database searching, and even pages that show the current time and weather for your city.

Chuck Shotton has built two methods into MacHTTP for communicating with external applications. The first method uses the "search" interface. The second uses the CGI (Common Gateway Interface) method. Both of these are common to a wide base of servers and are very nearly a standard, although the method of communicating with them varies from server to server. In MacHTTP's case, AppleEvents are used to communicate. AppleEvents are a method available in the MacOS for applications to pass information back and forth, including instructions for another application, like "please open up and print this document". We'll talk more about AppleEvents later.

Both of these methods work in a very similar manner. First, the information that needs to be sent to the application is appended to the URL. With the "search" method, a question mark (?) is used to indicate the end of the file reference and the beginning of data (e.g. "http://www.uwtc.washington.edu/Computing/searchme?text_to_find"). With the CGI method, a dollar sign ($) is used instead. The second step is to create an AppleEvent message containing the URL and the data. The third step is to send this AppleEvent to the correct application. The URL is used to determine what the correct application is. Instead of specifying a document in the URL, you specify the application (e.g. "/Computing/WWW/TestApp.cgi"). The final step, for MacHTTP, is to wait for the application to send an AppleEvent back containing directions on what to do. The AppleEvent that is returned can either contain HTML text (which is passed right back to the user), or can contain the URL to a document to be opened (this is called "URL redirection"), or can contain one of several other codes to indicate an error, or no action at all.

The two methods seem very similar, but in actuality the CGI method is far superior. It can handle much more data, where the "search" method is limited to only very short strings. The CGI method can also be run asynchronously, so that the server isn't tied up handling just one request at a time. The CGI application also gets much more information from MacHTTP, like a username and machine address, a password (if needed), the call pathway, and even the name of the client software being used. For these reasons, it is no longer useful to learn about the "search" method and in the following pages I will focus entirely on CGI's.

The Lessons

The following is a directory of the pages I have or hope to have soon that will help you learn how to use and/or create CGI applications to extend the capabilities of your MacHTTP server. The only requirement for following these lessons is a willingness to learn, patience with my jokes, and a MacHTTP server to practice on. I'll try to cover all of the basics as thoroughly as I can, although in some cases you would get more out of a good book (and I'll recommend those books).

Any listing above that doesn't have a link is still under construction. The latest versions of all of these documents can be accessed on my WWW pages.
Jon Wiederspan
Last Edited: December 11, 1994