ISAPI stands for Internet Server Application Programming Interface, In simple words it’s a way to gain the highest performance that you’d ever dream from IIS. ISAPI is “up to a certain level” similar to CGI but also overcomes many of CGI’s problems. One of the biggest differences between ISAPI and CGI is the process handling. In CGI, a new process is created “spawned” for each request. ISAPI uses threads to solve this issue “I wish to know a problem that hasn’t been solved by threading!”.

ISAPI extensions, the heart and soul!

ISAPI has two major types. ISAP extension applications and ISAPI Filters. ISAPI extensions are the heart of IIS. For instance, ASP.dll is an ISAPI extension that processes ASP pages, perlis.dll is another ISAPI extension works as a Perl script engine that runs .pl and .plx file extensions “You can obtain it from ActiveState“. Don’t conflict between the Perl ISAPI extension “perlis.dll and Perl CGI “Perl.exe”.

If you’re using IIS 6.0 or above, you will notice a different Application Configuration form. Have a look:

Wildcard Application Maps

Wildcard Application Maps contain a list of ISAPI Applications (ISAPIA) that will be processed before any HTTPS request, will make these applications available for all file extensions “regardless of whatever the file extension is”.

ISAPI filters

On the other side, ISAPI filters can be used to enhance an existing functionality provided by IIS. Any incoming/outgoing request can be processed and modified by those filters. As an example, you can provide your own custom operations (authentication, logging, etc…)

You may conclude now that ISAPI filters (ISAPIF) are kinda similar to the Wildcard Application Maps (WAM). I also agree with you, except that the WAM has many advantages over using ISAPIF. One of the chief differences is that WAM performs the customization operations “remember: encryption, logging, etc.” using the ISAPI extensions (ISAPIE) through IIS 6. And thereby you can overcome many limitations in ISAPIF, such as:

• ISAPIF are limited to parse the HTTP headers and cannot be used to process information contained in the body of an HTTP request “forget about processing HTTP Post”.
• ISAPIF can only configured per website, not per virtual directory.
• ISAPIF are synchronous.

ISAPIF are synchronous. “I know, that was informative!”

That last point is a very interesting one! Generally, a synchronous call blocks a process till the operation completes “Blocking Call”. In contrary, an asynchronous call is non-blocking and can only initiate the process “Send-And-Pray”. ISAPIF executes synchronously because of it’s execution on a core IIS thread. For example, If you’re involved in a network latency scenario “multiple agents”, ISAPIF are not of your choice. Most likely, It will cause serious problems. In ISAPIE “Again, ISAPIA -> WAM”, the concept is totally different, it has its own thread and thereby it executes asynchronously.