IIS and ISAPI
Managing IIS in a Shared-Server Environment Through the Use of ISAPI Filters
By Jay Frazier
It can be very difficult for a Web-hosting company to administer multiple sites within a shared-server hosting environment utilizing Microsoft Internet Information Server (IIS). Luckily, IIS provides the Internet Server Application Programming Interface (ISAPI), a mechanism that opens up server-request processing and lets administrators customize this processing through the use of ISAPI filters.
ISAPI filters are usually written in C and then compiled into dynamic link libraries (DLLs), which are loaded by the Web server on startup. The filters stay in memory until the server is shut down. In contrast, you may have heard of ISAPI extensions, which are loaded only when requested. When monitoring all incoming requests to a server -- as we'll do with the LogFilter tool presented later in this article -- a filter can often be more efficient than an extension because there's no loading/unloading overhead.
When a browser requests a document from IIS, a number of things happen. First, IIS reads the request data. Then it processes the HTTP headers. The URL gets mapped to a physical path, and so on until the server sends a response, writes to the log file, and closes the session. Unfortunately, when running in a shared-server environment, IIS has a quirky default action that causes requests to individual Web sites to be stored in individual log files. Sifting through each file in search of errors is tedious, especially for companies hosting hundreds of sites. This is a case in which a well-placed ISAPI filter can save administrators a lot of time.<>
