Let us see how HTTP is extended to do more than serving static content.

When we talk about Windows Platform & HTTP, Microsoft product which comes to the picture is IIS. In the early days (and early versions of IIS) HTTP was primarily used for hosting websites and to enable people to use browsers to request those websites.  So in essence IIS (or for that matter any web server) is built to serve “static” HTML pages with resources like images (referring to IIS2). But later versions of IIS provided ways to extend the web server in order to provide dynamically serving websites. In IIS world we call it as ISAPI Extensions. Hmmm... So what is ISAPI Filters then?

Let’s try to understand more about ISAPI Filters, ISAPI Extensions & Wildcard ISAPI Extensions to get more clarity.

ISAPI Filters

From the name itself you know that it’s something to do with filtering. Yea you got it right! So IIS exposes a set of notifications (IIS term for events) so that we can develop an ISAPI Filter (dll with a difference) to register for these notifications. When IIS triggers these notifications your ISAPI Filter DLL gets a chance to handle the data available for that specific notification.

Confused? Huh! Let me try with a hypothetical example then,

Assume that you have an ASP application and you don’t want your web users to know that it’s really ASP. So what can you do? Let them request .ASPX pages and we will change the extension to .ASP before IIS gets it for further processing. Good Idea?

Change all your links in the site to point to .ASPX extension. And when web users request “default.aspx” the ISAPI Filter would change the file requested to “default.asp” without the user’s knowledge and show off that you are running an ASP.NET application but under the hood it’s a legacy ASP application. J

How does this work or how is this implemented?

Like I mentioned before you need to use one of those ISAPI Filter notification called SF_NOTIFY_PREPROC (search on MSDN for more information). So what does that give us? When a request enters IIS and when IIS reads in the HTTP request header our ISAPI Filter gets a chance to access HTTP request header and if required we can modify it. So in our scenario, we would see that URL field in the header contains “default.aspx”. Yes you guessed it, we would change that URL to “default.asp” and let IIS know that it needs further processing. Cool deal hah!

Important piece of code from the ISAPI source provided below to show how easy it is

ISAPI Extensions

So like I mentioned before a web server serves static pages, the dynamic features like ASP, ASP.NET, PHP etc happens because of ISAPI extensions. So the obvious is that ISAPI Extensions are a way to extend the Web Server to add more features to it.

So once the requests surpass the ISAPI Filter and if the request is not for static page, IIS searches for an ISAPI extension which is mapped to the request file extension. If found the request is forwarded to that ISAPI Extension for further processing and returning a valid response back to the client.

Wildcard ISAPI Extensions (IIS6 specific)

Here we will talk about why we need this piece and what are we trying to achieve here. Yes you guessed it, Wildcard extensions comes in between ISAPI Filters & ISAPI Extensions, so that it can have the features of both ISAPI Filters & Extensions.

Before getting into details lets see the Pros & Cons of ISAPI Filters & ISAPI Extensions.

ISAPI Filters

Pros of ISAPI Filters

1. Every request can be intercepted regardless of the file extension
2. Filter notification allows us to enhance or replace some of the IIS features
   1. Custom Redirection or request filtering -      SF_NOTIFY_PREPROC_HEADERS
   2. Custom Authentication – SF_NOTIFY_AUTHENTICATION
   3. Modify IIS log values – SF_NOTIFY_LOG
      etc… (notification list documented on MSDN)

Cons of ISAPI Filters

1. No Asynchronous support
2. Uses IIS thread pool and cannot implement its own thread pool, so whatever processing of request is being done inside the filter should be completed quickly, otherwise chances are that IIS runs out of worker threads and users starts seeing errors like “Server too busy” or IIS gets into a hung state without responding to requests.
3. No access to entity body (huh! its another term for HTTP request body)

ISAPI Extensions

Pros of ISAPI Extensions

1. Gets the entire entity body (HTTP request body)
2. Can implement custom thread pool
3. Processing the request can be asynchronous

Cons of ISAPI Extensions

1. Can handle only requests to specific extensions (because its mapped to specific file extension.
2. Processing happens only after getting the complete request entity body.

Wildcard ISAPI Extensions

Pros of ISAPI Wildcard Extensions (hybrid of Filter & Extension)

1. Every request can be intercepted regardless of the file extension

ISAPI Filters: Yes
ISAPI Extensions: No

2. Implement custom thread pool

ISAPI Filters: No
ISAPI Extensions: Yes

3. Asynchronous Processing

ISAPI Filters: No
ISAPI Extensions: Yes

4. Handle entire request processing and return response to the client or hand over to an ISAPI Extension (according to the extension) for further processing.

ISAPI Filters: Yes
ISAPI Extensions: Yes

5. Can get access to complete request entity body

ISAPI Filters: No
ISAPI Extensions: Yes

So from the above list you can see that Wildcard ISAPI Extension provides a way to get best of both worlds (ISAPI Filter & ISAPI Extension).