Waiting For Response…

One of the most important things to keep in mind is that while your program is executing happily on the server machine, the user is staring at what might as well be a blank screen. The typical Web browser application (also referred to as a user agent), displays a message in its status panel to the effect of Connected to www.xyz.com...Waiting for response.... The cursor is the hourglass cursor, further emphasizing to users that they're on hold. Therefore, CGI applications must do their thing and return control to the Web server as quickly as possible. The program should avoid using any but the quickest methods of accomplishing what needs to be accomplished.

For instance, you should avoid attempting to start a slow OLE automation server. If the application attempts to create an Excel spreadsheet object, stuff data into it, analyze the data, export the spreadsheet to a Word document, and then return the Word document to the user, the client will probably produce a time-out error-unless, of course, your Web server is running on a machine with an ultra-fast motherboard and hard drives. Unfortunately, there are no "rules of thumb" for what you should and shouldn't do. Only experimentation with the application will reveal how fast or slow it operates.

The Sluggish Net

Another item to keep in mind while we're discussing speed is the speed of the user's connection. If your application returns complicated Web pages with lots of graphics on them, you'll want to connect to the server and try the application using a 14.4Kbps modem. This simulates not only the typical user's connection, but also a fast T-1 connection from across the country. As the Internet becomes more and more crowded, even fast access points slow down as the user traverses the continent, hopping from network to network before finally reaching your server.

This is not a concern for CGI applications only-when designing a Web site, you should attempt to design for the lowest common denominator. If you can afford separate sets of pages for users with fast and slow connections, the effort is usually very much appreciated.

Do Not Allow for Interactivity

Perhaps the most important item to keep in mind is this: No one is there to click the OK button on a message box that a CGI application might open. This is particularly true on Windows NT Web servers that run as a system service. For debugging on a Windows 3.x or Windows 95 Web server, such interactivity might work. However, unless you want to sit by the machine while the Web server is operating and click OK, make sure you remove all possibility of having a message box appear.

If you're running a Windows NT Web server, such as the Microsoft Internet Information Server, the problem is even more severe. A CGI application that causes a message box also more than likely causes a time-out error on the client or returns no data if the server realizes the app is effectively dead in the water and times out first.

If you use common code modules, comb through them to make sure they contain no user interface code.

Use Tighter, Centralized Error Control

Make sure error trapping is turned on in the Sub Main routine and that, if errors are trapped separately in procedure and function calls, that no message boxes will display! It is best to use a central error trapping mechanism: The only ON ERROR... statement should be in the Sub Main procedure. This provides you with the ability to control exactly what code is executed when an error occurs. It also helps eliminate the possibility of an object requiring interaction being opened. The examples you'll build later use this type of error trapping.
 

Synchronizing with HTML Forms

When designing an application that accepts input from the user (such as a guest book registration or search engine), you must keep CGI data in the application and input elements on the HTML forms in synch. If you change a form input element's NAME tag, for instance, you must update the CGI code to reflect this change. This becomes more apparent when you start into the examples.

For example, you wouldn't try to access a textbox named Text1 in a typical application if it didn't exist. Likewise, you can't get meaningful data from a CGI field named Text1 if one doesn't exist on the HTML form that serves as the user interface for a CGI application.

Formatting Output for HTML Browsers

Just as you have to be conscious of HTML forms for inputting data, you must also take care with HTML when outputting data to the client. Although HTML is an Internet standard, each Web browser renders an HTML document slightly (or, in some cases, grossly) different. You should limit what you try to accomplish with the output page in order to serve the most number of browsers possible.

http://www.research.digital.com/nsl/formtest/home.html 

There is an HTTP header field and a corresponding CGI data field called UserAgent (in the CGI data file it's in the [CGI] system as User Agent). This field is where the Web client that generated the request message specifies its name and version. This could be useful for determining what to output to the client. However, there are so many different values used for this field that trying to make sense of it can be more trouble than it's worth. For a demonstration of this, visit the HTML Form-Testing Home at http://www.research.digital.com/nsl/formtest/home.html and follow the Test Results Sorted by Browser link. This will provide a long list of all the UserAgent values that have been tested by the site.

We hope a future version of HTTP (and Win/CGI) will provide a field for specifying HTML conformance and the graphical capabilities of client applications. This type of field would provide meaningful information to server-side applications when those applications produce HTML output.

Leave No Objects or Files Open

When the CGI program is ready to end, make sure you close all open files and any objects that have been created. The mechanism the server uses to monitor when your program exits has been known to trigger before the program has completely cleaned itself up. As most VB programmers are aware, VB cleans up behind an application if it leaves files or databases open. However, doing so in the CGI environment may cause unexpected results. This is particularly true with the CGI output file. If it is not explicitly closed before the server attempts to open it for transmission to the client, you're in for big trouble! The server may actually read all that's available in the file but miss the last segment of it. This could happen if VB has to close the file after the application exits-the last pieces of data the app wrote to it won't actually make it to the disk until the file is closed.

Use AutoNumber Fields for Access Databases

Because of the tremendous concurrency issues that arise on Web servers, you should always allow the database engine to specify primary keys. This ensures that two concurrently running CGI applications that add records to a table won't pick the same key.