In the past, Web sites consisted of static HTML pages. Interactivity was through external processes on the Web server, called common gateway interface (CGI) applications.
For example, if you needed to access data not stored in hypertext markup language (HTML), you would use a CGI application to access the data and send the results back to the client in HTML.
You could develop the CGI application in any language. This was usually the language the developer was most proficient in.
In this chapter we compare CGI and ISAPI, and look at the benefits and drawbacks of each. This should help you plan for either or both technologies in your current and future Web development.
ISAPI is a standard programming interface that can be used by both Web site developers and Web server developers. ISAPI offers faster, more efficient solutions than CGI. ISAPI also has new features such as the ability to apply additional processing to all HTTP requests.
The ISAPI alternative to CGI is the ISAPI extension (also called a server application). ISAPI extensions allow CGI-type function with faster performance and fewer resources.
ISAPI filters (also called server filters) afford additional preprocessing and postprocessing of all HTTP requests to a Web server. Filters enable developers to add custom logging, authentication, auditing, and security to their Web sites.
If you have already invested in CGI applications, your time and effort have not been wasted. ISAPI is fully compatible with CGI.
You can also supplement ISAPI by developing new ISAPI that put a mix of ISAPI and CGI on the server. For operating Web sites, it might make sense to continue CGI applications and add new function on the Web with ISAPI.
CGI has been the standard for building interactive Web sites for many years. CGI was originally conceived in the UNIX world of Internet development. The purpose was to provide a common method for handling client requests for information that didn't reside in HTML format.
A CGI application is a separate process (executable) that is invoked by the Web server to handle a specific client browser request. For example, the client browsing a company intranet might request the phone extension of an employee.
The client browser types in the name of the employee in an HTML fill-in form. The logic in the fill-in form passes in the name of the employee to a CGI application on the Web server in the form of a hypertext transport protocol (HTTP) request.
The server invokes the CGI application to search on the employee name and return the phone extension in HTML to the server. The server forwards the information back to the client.
CGI has served the Internet development community well over the years. CGI uses standard input (stdin), standard output (stdout), and environment variables to communicate between a Web server and a CGI application. The rest of this section highlights CGI's benefits.
CGI was born into UNIX, which until recently was the predominate Internet server platform. The reasons were simple.
CGI used existing operating system features for interprocess communications. Reading stdin, stdout, and environment variables were simple operations. And since UNIX was a preemptive, multitasking operating system, starting another process was easy.
Above all, the approach did not vary from traditional UNIX development or Web development practices. CGI applications are standalone processes that can be developed and tested independently of ancillary systems.
CGI was a manageable process for software developers and server administrators. Developers could use their existing UNIX experience to create new Internet applications using CGI. And its consistency with traditional development practices made CGI a natural choice for the Internet.
Since CGI applications are executables, they run in a separate address space from the Web server. It is virtually impossible for a rogue CGI application to crash the Web server.
This supplies a high level of reliability to your Web site. If the CGI application crashes during an HTTP request, the Web server times out after not receiving a response and returns a server failure error to the client.
A "bad" CGI application cannot directly harm the Web server. But a bad CGI application can affect the performance of your Web site if the operating system does not clean up after the application crashes. Each instance of the CGI application that stays in memory consumes the resources of the Web site computer.
![]()
This is in direct contrast to ISAPI extensions and filters, which are used as dynamic-link libraries (DLLs). ISAPI extensions are loaded into the address space of the Web server. Although ISAPI extensions provide speed and resource advantages, it is also possible for an ill-behaved extension to crash the Web server.
Debugging a CGI application is relatively easy, depending on the complexity of the application. Because a CGI application is a separate process, you can run it through the debugger without intervention from external applications such as a Web server.
A CGI application gets all its data from stdin and from environment variables. During a debugging session, the parameter string that would normally be passed from the Web server can be manually entered to the CGI application as command line parameters.
Let's say a client browser calls the CGI application with the following query:
http://scripts/foo.exe?Param1
The Web server in turn starts the foo.exe process with the Param1 parameter on the command line of the executable. During a debugging session, you can manually enter the same information. Figure 4.1 illustrates entering command line parameters using the Microsoft Visual C++ debugger.
Debugging a CGI application using Visual C++ to enter command line parameters.
The nature of CGI applications allows traditional debugging methods. This means a CGI application can be debugged like any other application. You don't need any special tricks. Such familiarity allows developers to quickly test and debug their CGI applications.
Another feature you can use to debug CGI applications is Just-in-Time debugging. Just-in-Time debugging means executable files can be compiled and linked in debug mode.
If at any time while the application is executing, a protection violation occurs, the debugging libraries take over and let the user debug the application. The debugger is loaded into memory and the source code pin-points the spot where the error occurred.
To use Just-in-Time debugging, you have to meet the following criteria:
With the introduction of IIS, Microsoft has embarked on a new direction for extending the capabilities of Web servers and Web sites. This is an API specifically for the Internet server called ISAPI.
In traditional Microsoft fashion, ISAPI is positioned as an open specification. Any vendor's Web server software can be compatible with applications that use ISAPI.
![]()
ISAPI enables Web developers to tailor their Web sites through the use of ISAPI extensions and ISAPI filters. Extensions offer capabilities like those of CGI applications. Filters allow preprocessing and post-processing of HTTP requests for services such as authentication, custom logging, and security.
ISAPI is part of a common trend initiated by Microsoft to blend ancillary programming interfaces into the operating system. One look at the Win32 API reveals this trend.
ISAPI is the first step toward a standard Internet interface to the Win32 development platform. IIS is included as a standard part of the Windows NT server operating system.
In addition, IIS Peer Web Services, which work with ISAPI, is included with Windows NT Workstation. The result is one-stop shopping developers of Internet applications.
If you buy Windows NT you get a Web server and a standard programming interface with the server. This makes the life of a system administrator and also developer much easier.
Its tight integration with Windows NT enables IIS to take advantage of the benefits of the operating system.
When a client issues a request to your Web server, you would like your response to be returned as fast as possible. HTML pages are generated much faster by ISAPI extensions by comparison to CGI applications.
ISAPI extensions are used as DLLs, which means that the extension is loaded into the address space of the server. When a client requests information from an ISAPI extension, the server looks to see if the extension is loaded into memory.
If the extension is already loaded into memory, the server calls the entry point into the extension to pass any search criteria and to get the generated page response. If the extension is not loaded into memory, the extension is loaded from disk and the entry-point function is called.
Loading a DLL and calling a function are much faster than starting a CGI application and waiting for the response. In a recent study done comparing the throughput of an ISAPI extension versus a CGI application using IIS, ISAPI extensions outperformed CGI by a factor of 5.
Figure 4.2 shows the results of this test.
The study done by Microsoft Business Systems Division in March 1996. Two Web server performance benchmark tools were used in the study, National Software Testing Laboratories, Inc. (NSTL) Web benchmark tests and WebStone version 1.1 from Silicon Graphics.
The NSTL tests were done by the NSTL at its corporate offices. The WebStone tests were done by Shiloh Consulting and Haynes & Company at the offices of Shiloh Consulting.
More information on these tests can be found on the Microsoft Web site at http://www.microsoft.com/infoserv/. The test platforms were Pentium 133-Mhz machines with 32 MB of RAM.
![]()
Comparison of ISAPI and CGI throughput.
The test comparing ISAPI and CGI throughput was configured to return only pages generated by CGI or ISAPI applications. No static HTML pages were used. The results were run with 64 clients.
One advantage of a CGI application that runs as a separate process from the WEB server is also one of its biggest drawbacks. Each client request to a CGI application causes a separate instance of the application to be started. As a result:
As you can see, if your server is extremely busy and handles hundreds, even thousands of simultaneous requests, starting a CGI application for each request quickly reduces the throughput of the server.
ISAPI extensions overcome these problems with CGI applications because ISAPI extensions are used as DLLs. As DLLs, the ISAPI extensions are loaded into the address space of the Web server when the first request for the extension is issued.
The DLL doesn't need to be reloaded for subsequent calls to the ISAPI extension, resulting in increased speed and decreased use of resources. Task switching by the operating system is also reduced since the extension is treated as part of the Web server.
For each client connection to the Web server that uses an ISAPI extension, the Web server starts a separate thread of execution to call and process the ISAPI extension. The ISAPI extension executes within the confines of the newly created thread on the Web server.
For this invocation of a new thread, ISAPI extensions use thread-safe synchronization to protect shared resources in the extension from simultaneous access.
Chapter 18, "Making Your Extensions Thread-Safe," tells you how to create thread-safe ISAPI extensions.
In a test comparing the number of connections per second that could be handled by ISAPI extensions and CGI applications, ISAPI was approximately five times faster then CGI. Figure 4.3 illustrates this point.
Comparison of number of connections handled per second by ISAPI and CGI.
This test shows that clients at a Web site using ISAPI extensions have less waiting than at a Web site using CGI applications.
ISAPI gives the Web site more control than CGI. ISAPI filters allow both preprocessing and postprocessing of HTTP requests sent to the Web server. This means that you can administer custom handling of all events before the request is passed to an ISAPI extension or other handler.
You can use ISAPI filters for user authentication and security checks. Failed security credentials are returned before they reach the ISAPI extension.
You can use filters for custom logging and auditing of Web server usage. With filters, all HTTP requests sent back to the client from an ISAPI extension to be processed if necessary.
ISAPI filters, like ISAPI extensions are used as DLLs. ISAPI filters are loaded by the server at startup, not on demand like extensions.
When a filter is loaded it registers with the Web server for each event it is supposed to get. When the event is received by the server, it is routed through the filter before it reaches its target destination.
The filter can process and forward the request. Or it can reject the request without forwarding it to the destination.
Chapter 12, "Using ISAPI Filters," and Chapter 13, "Understanding ISAPI Filters," analyze how ISAPI filters can be used by a Web site.
When a client request is issued to an ISAPI extension, the extension can map the request to another URL. This is useful if information is moved from one URL to another. The original URL can stay in place and when the request arrives, it can be routed to the right location.
URL mapping is done by the API ServerSupportFunction, which redirects and maps URL requests.
Chapter 8, "Using Extension Capabilities," tells you how to use URL mapping in an ISAPI extension.
Security is always a concern of system administrators. ISAPI gives developers techniques to supply extra layers of security for users of the system.
One of these techniques is to use an ISAPI filter for custom authentication on the server. This allows you to do your own security checks on the server.
If the server is on a corporate intranet, you can use the Win32 API by calling the Windows NT security features to limit the access of the client. You do this with the ImpersonateClient function, which changes the current permission level of the application to that of the client. When the request is finished processing, the default security level is returned.
Since ISAPI implements its functions inside DLLs, it is harder to intercept and replace by hackers because custom handshaking can be designed between the filters and the extensions. With a CGI application, if the application can be replaced by a hacker, your system can become very vulnerable.
Your choice between ISAPI and CGI to create Web sites depends on several factors. Two important ones are the target platform and whether existing CGI applications remain at your Web sites.
If your target platform is Windows NT and IIS, ISAPI offers the best performance, capabilities, and integration possibilities. If many CGI applications remain at the sites, you might choose to maintain these applications rather than port them to ISAPI. However, ISAPI will give you the best results.
ISAPI is a standard interface for developing Internet applications on the Windows NT, IIS platform. As we saw earlier in this chapter, independent tests prove that ISAPI provides better throughput and connection handling than CGI applications.
IIS works with CGI. But for the best performance use this combination only if existing CGI applications remain at your site.
ISAPI also supplies much more function than CGI: ISAPI extensions offer the same benefits as CGI with less overhead and more speed. ISAPI filters supply custom authentication and security, which are unavailable from CGI.
To help you develop ISAPI applications, languages such as Visual C++ include an application wizard which can be used to build a template for developing ISAPI extensions.
Sometimes the server has to rely on separate processes for retrieving information. In these cases, you won't want to put all the logic and handling of information in an ISAPI extension.
An example of this is a process gathering environment control information from a network of sensors in a factory. The sensors must be polled in real time for information.
If any sensor, such as a smoke detector, reports trouble, you may have to enable an output control point such as a fire alarm. A critical process like this must be running constantly.
For a facilities manager, it would be nice to have an intranet application report the status of all of the factory sensors and control points. An ISAPI extension would work best for such an application.
The ISAPI extension would query the environment control process for the current status and return the information to the client requesting the data. The ISAPI extension could use interprocess communication (IPC) such as named pipes, sockets, or remote procedure calls (RPCs) to communicate the request to and receive the information back from the extension.
Figure 4.4 illustrates the data flow of this system.
Data flow of an ISAPI extension using a Win32 IPC to request information from an external program.
In this situation, it would not be practical for the ISAPI extension to hold the logic for interfacing to the control sensors. The extension would not be online 24 hours a day as needed because it would only be loaded on client request. A CGI application would not be practical for the same reasons.
Developing ISAPI extensions is straightforward. An ISAPI extension is used as a DLL and a variety of development tools are available for developing DLLs.
You can create ISAPI extensions in any development environment that enables developing Win32 DLLs. When you use the language your development team is proficient in, you get the highest productivity.
In this chapter we look at the benefits of and drawbacks to both CGI and ISAPI. CGI applications appear to be easier to develop and debug. But if your target platform is Windows NT and your Web server is an ISAPI-compliant server such as IIS, ISAPI offers the best results.