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
Char buffer[256]; DWORD buffSize = sizeof(buffer); BOOL bHeader = pHeaderInfo->GetHeader(pCtxt->m_pFC,"url",buffer,&buffSize); CString urlString(buffer); urlString.MakeLower(); if (urlString.Find(".aspx”) != -1) //we want to change this file’s extension { urlString.Replace(".aspx",".asp"); char *newUrlString= urlString.GetBuffer(urlString.GetLength()); pHeaderInfo->SetHeader(pCtxt->m_pFC, "url", newUrlString); //we’re done, now give it to IIS for further processing return SF_STATUS_REQ_HANDLED_NOTIFICATION; } |
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.
Request | IIS [ ISAPI Filter -> Wildcard Extension -> ISAPI Extension] | Response |
Before getting into details lets see the Pros & Cons of ISAPI Filters & ISAPI Extensions.
ISAPI Filters
Pros of ISAPI Filters
- Every request can be intercepted regardless of the file extension
- Filter notification allows us to enhance or replace some of the IIS features
- Custom Redirection or request filtering - SF_NOTIFY_PREPROC_HEADERS
- Custom Authentication – SF_NOTIFY_AUTHENTICATION
- Modify IIS log values – SF_NOTIFY_LOG
etc… (notification list documented on MSDN)
Cons of ISAPI Filters
- No Asynchronous support
- 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.
- No access to entity body (huh! its another term for HTTP request body)
ISAPI Extensions
Pros of ISAPI Extensions
- Gets the entire entity body (HTTP request body)
- Can implement custom thread pool
- Processing the request can be asynchronous
Cons of ISAPI Extensions
- Can handle only requests to specific extensions (because its mapped to specific file extension.
- Processing happens only after getting the complete request entity body.
Wildcard ISAPI Extensions
Pros of ISAPI Wildcard Extensions (hybrid of Filter & Extension)
- Every request can be intercepted regardless of the file extension
ISAPI Filters: Yes
ISAPI Extensions: No
- Implement custom thread pool
ISAPI Filters: No
ISAPI Extensions: Yes
- Asynchronous Processing
ISAPI Filters: No
ISAPI Extensions: Yes
- 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
- 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).
Most of my interactions in the past with customers, web developers and some of my prior colleagues, I have found that a larger percentage of them don't have a good understanding of how HTTP protocol works. This could be due to various reasons; some of them could be like
- Coming from windows application development background.
- Not getting enough time to go through the details due to project deadlines.
- Too difficult to get the meat out of HTTP RFC document because it’s too much to read.
This results in lot of confusions and also leads to low performance application development. So I thought I would help the readers of putting those confusions to rest and explain all these in simple and effective way. So, in essence this article is no rocket science, but HTTP basics which most of those HTTP/IIS experts left out thinking that it would not be necessary to be explained (Or maybe its there but I missed noticing it).
Is HTTP a popular protocol, Oh really?
The popularity of HTTP protocol is simply because it's a simple protocol when you try to understand it from grass root level. Because of the simplicity (huh, I think due to recent developments people have made it a little complex) HTTP is used extensively not just for serving HTML pages but in order to empower several applications to make it work on the web.
How does a simple HTTP response look like?
|
#include <iostream.h>
#include <windows.h>
int main (int argc, char** argv,char **envp)
{
cout << "Content-Type: text/html\r\n\r\n"; //Header
cout << "<h2>Hello World!</h2>" <<endl; //Body
return 1;
} |
How does HTTP works with authenticated request?
- Browser send GET request to IIS (remember 1st request is always anonymous)
- IIS returns 401 and provides WWW-Authenticate Header with the supported authentication methods
- According to authentication method Browser pop-up the dialog to enter credentials and then submits to IIS
- Credentials gets validated and if valid, your GET request is served with HTTP Status 200 (200 = success)
Why do we need sessions in HTTP?
Since HTTP is a connection-less protocol we need to provide a way to continue request-response process without having to create a ‘fresh’ newer connection for every request.