ISAPI, ISAPI filters and finally ASP

A correction is in order: Two weeks ago we wrote that “the Windows Task Scheduler . . . only allows a minimum repeat interval of 24 hours,” and we were wrong. Despite having used the scheduler several times, we moved too fast to notice the checkbox that reads: “Open advanced properties for this task when I click finish.” Had we done so we would have found that we could schedule down to minutes. Of course we couldn’t schedule “the second Tuesday of every month” but that’s a different complaint.

Anyway, last week we started to talk about Microsoft’s Active Server Page (ASP) technology, got into the company’s Internet Server Application Programming Interface (ISAPI) and wound up in a discussion about thread-safe programming. Who could ask for more?

In our discussion of thread-safe programming, we covered the issues of race conditions, deadlocks and priority failures but had to stop before we made it to the problem of starvation failures.

This final requirement for thread-safe programming is about avoiding the situation that occurs when threads cannot execute within whatever limiting period is required. For example, a thread that provides data to a client (for example, a response to a request from a Web browser) might have to do so before the client (the browser) times out. Starvation occurs when that timeout is exceeded (and the user of the browser gets a 404), because the thread doesn’t get enough time to run to completion and provide a response.

So a thread-safe environment is what ISAPI attempts to create to support multiple requests from Web clients to minimize resource usage. Typically, ISAPI is significantly faster than the same process implemented using the Common Gateway Interface (CGI) not only because of threading, but because ISAPI DLLs don’t get loaded and unloaded for each request. CGI, on the other hand, requires a new instance of the CGI application to be loaded when each request is received and then unloaded when it finishes (yes, there is FastCGI but that’s not a great improvement or generally applicable).

ISAPI has some interesting advantages over CGI. And one thing that can be done with ISAPI is to create ISAPI filters, custom DLLs that are called for every HTTP request (rather than being called specifically) before the Web server does anything with the request.

This means that an ISAPI filter can be used to do anything with HTTP requests that ranges from controlling user access and logging activity to responding to the request in any way you please.

ASP is a technology based on ISAPI filtering that is designed for programming Web applications. The ASP ISAPI filter, called ASP.DLL, operates only on pages that have the ASP extension, which it identifies by examining each HTTP request. If the request is for an ASP file, then ASP.DLL gets involved.

On receipt of a request for an ASP the ASP module examines the page contents, determines which scripting languages to use, loads the DLLs for the scripting language interpreters, passes the scripts to the interpreters and passes the results (if any) to the Web server to be sent back to the device that made the request.

Here’s a simple ASP page, hello.asp:

Hello World! The server’s time is now

This pathetic piece of code starts off by telling the ASP handler that we’re using VBScript. This is indicated by . Anything in the “” tag is considered to be ASP code.

The only thing that this ASP page actually does is to replace the tag “” as the page is interpreted with the server’s time. The result in the requesting browser is a window titled “Yo-yo, ding-dong.” that contains the text “Hello World! The server’s time is now 3:44:53 p.m.”

Next week, we’ll try to get more exciting. Requests to gearhead@gibbs.com.