Installing Forms

Adding the capability to get user input from forms to your server requires a number of talents. You need to learn to write HTML form tags, learn to write a CGI application to process the form input, and learn how to properly install the form page and CGI application so the form refers to the right CGI. The last item actually seems to be the hardest for many people.

Install the Form page

Actually, installing form page is easy. Put it anywhere you want to on your site. The only limitation is that which applies to all pages served by MacHTTP; the page must be either in the MacHTTP folder, or in a sub-folder of that folder, or be referred to by an alias in one of those two places. This is explained more fully and competently in the MacHTTP documentation.

NOTE: When you are testing a form, do not use the option to load a local page, that many WWW clients offer (in Netscape this is the "Open File" option under the "File" menu). This option will load your form page properly but will cause an error when you try to Submit the form. The problem occurs because this form of loading bypasses MacHTTP, and loads the file directly from disk to your client software. Since MacHTTP wasn't involved, it won't know to send an AppleEvent to the CGI application when the form is submitted. A sure sign that you are using the wrong method to view your form is if the URL has "file:" at the start - that means the file is on your local hard disk.

Install the CGI application

The real problem with forms lies in properly installing the CGI application that you will use to process the information from the form. At the beginning of the form section, you need to tell where to find the CGI application. There are two ways you can do this; you can give the complete path relative to MacHTTP or you can give a partial path, relative to the form page itself.

Let's look at an example:
Assume that you have MacHTTP in a folder on the root of your hard disk. The path to MacHTTP would be "BigDisk:HTTP Server:MacHTTP". Now you have a folder on your site called "Testing" that contains a form page, "UserForm.html". The full path to the form page is "BigDisk:HTTP Server:Testing:UserForm.html". You will never use this path, though. The only path that matters here is the path relative to MacHTTP. This relative path is "/Testing/UserForm.html".

NOTE: The Macintosh OS uses colons (:) to delimit folders in a path. URL's, however, use the slash (/) character instead. This is because the first http servers ran on Unix machines, which use the slash character to delimit folders (directories) in a path. This is the way you will be writing paths for all of your HTML pages. In addition, this method doesn't allow any spaces in the path - you must use "%20" to indicate a space. It is best to avoid spaces in file or folder names under MacHTTP.

Back to the example:
Now, suppose you want to put the CGI application that processes this form into another folder within the "Testing" folder where you will keep all of your CGI's. The full path to this folder is "BigDisk:HTTP Server:Testing:CGI:". For the CGI application that will process this form, named "FormProcessor.cgi", the path relative to MacHTTP is "/Testing/CGI/FormProcessor.cgi".

Now everything's in place. In your form page, the element that marks the beginning of the form needs to specify where the CGI application is that will be used to process the form. If you use a path relative to MacHTTP ("/Testing/CGI/FormProcessor.cgi", as listed above) then the line would look as follows:

   <form action="/Testing/CGI/FormProcessor.cgi" method=post>

If, on the other hand, you choose to use a path relative to the form itself, the line will look like:

   <form action="CGI/FormProcessor.cgi" method=post>

Either one is acceptable, and the second method provides a little more portability so it might be preferable.

Summary

This is one of the areas of using CGI applications that tends to trip people up the most often. For this reason, I include a form and pre-compiled CGI application in the archive ("Form1.html" and "Script1.acgi") that you can use to test with. Both of these have been tested so the tags and the CGI are working correctly. Therefore, any problems you have with them are due to improper installation or an error in the URL in the form that tells where the CGI is. Try moving both parts around and see if you can figure out what path to use to indicate the CGI application. Make sure you understand these paths (and URL's in general) before you try installing your own forms or using your own CGI applications. Otherwise you're begging for a migraine.

Jon Wiederspan
Last Edited: December 11, 1994