linkibol web application runs on an IIS7 windows server box.

Althogh there exists a URL rewriting module for IIS7, we preferred enhancing our formerly-written HTTP module (IndigoWrite.RewriteHttpModule) over it, because of its lesser performance overhead.

IndigoWrite is currently a closed-source library. However we plan to distrubute it under an open-source license. It requires some workout beforehand though. It's is on our to do list none the less.

Adding a managed module in IIS7 is a piece of cake. First, you choose "Modules" section for the website using IIS Manager snap in:

 Then you select "Add Managed Module" action:

The module we added to linkibol is "IndigoWrite.RewriteHttpModule".

 Here follows the edit screen for our managed module:

After having added the module, we bound the requests to "link.bul" paths to a managed HTTPHandler. This can be easily done by first selecting HTTPHandler for the site from the ISS Management snap in:

and then choosing "Add Managed Handler".

We named the handler LinkBulManagedHandler and associated it with "link.bul" pathname. So any request that is sent to http://www.linkibol.com/link.bul/* is handled by this handler.

Actually this handler is a PageHandler that is created by a PageHandlerFactory. PageHandlerFactory Class creates instances of classes that inherit from the Page class and implement the IHttpHandler interface. Instances are created dynamically to handle requests for ASP.NET files. The PageHandlerFactory class is the default handler factory implementation for ASP.NET pages.

You can change mapings, verbs, and access restriction for the assigned handler if you like:

Here's how the entire HTTP Pipeline flows:

1. Web page request comes from browser.
2. IIS associates "link.bul" file extension to a "System.Web.UI.PageHandlerFactory", provided with ASP.NET.
3. IIS" forwards the request to the ASP.NET worker process (ASPNET_WP.EXE or W3P.EXE).
4. Then the worker process loads HTTPRuntime and passes the request to it. Thus, HTTP Pipelining has begun.
5. HTTPRuntime uses HttpApplicationFactory to either create or reuse the HTTPApplication object.
6. HTTPRuntime creates HTTPContext for the current request. HTTPContext internally maintains HTTPRequest and HTTPResponse.
7. HTTPRuntime also maps the HTTPContext to the HTTPApplication which handles the application level events.
8. Then HTTPApplication runs the HTTPModules for the page requests (in this case RewriteHTTPModule is run along with other registered modules (if any)).
   An HTTP module is an assembly that is called on every request that is made to the application. Since HTTP modules are called as part of the ASP.NET request pipeline, they have
   access to life-cycle events throughout the request. HTTP modules let you examine incoming and outgoing requests and take action based on the request).
9. Then HttpApplication creates the handler for the request using System.Web.UI.PageHandlerFactory. The handler, in this particular scenario, is nothing but a System.Web.UI.Page page implementing the IHTTPHandler interface. IHttpHandlers are responsible to process the request and generate corresponding response messages. This is the last stage of HTTP Pipelining.
10. Once the request leaves the HTTPPipeline, page-level events begin.
11. Page Events are as follows: PreInit, Init, InitComplete, PreLoad, Load, Control events (Postback events), Load Complete, PreRender, SaveStateComplete,  Render and Unload.
12. After having gone through the above events, the response is sent back to the IIS which in turn sends the response to the client browser.