Async HttpModule

The merits are exactly like you said, you can plug them in passively to the http pipeline for your app.. as for implementing them, they aren't scary complex beasts, if you ignore the configuration side, essentially when a HttpApplication starts a request, it runs through a phase where it creates instances of each registered http module.. and it calls Init on each of them passing itself in..

Whats expected is that the http modules will register theirselves to events that happen in the request.

What is important to understand is how threading works, and what the lifetime of HttpApplications is.. the most basic way to think of it is that for every request to the server that results in the asp.net handling the request (so in iis6 this is aspx, and registered resource handlers or any other types you have registered, in iis7 integrated mode with server registered modules, this is for ANY request), a httpapplication instance manages executing the request and building a response.

Technically a httpapplication will be reused but imagine you have multiple requests coming in at a time, you'll have multiple httpapplications running.. and once the request completes they return to the application pool (where a limited amount of them (usually 20) will stick around until the app pool recycles).

You need to make sure any work you dispatch in your httpmodule, is aware that another instance of the module could also be doing the exact same action at that time.. so you'll want to manage how you handle concurrency here..

If you are running long running tasks then its certainly advisable to dispatch this work on another thread.. otherwise you're requests will be 'stuttering' at each event you do long work on.

One thing you'll need to be careful of is exceptions on these work threads.. if a thread bubbles up it will kill the app domain (causing the app to need to start up again)..

If at all possible you'll probably just want a single thread to do the work, and the http modules would simply queue work up for that one worker.. otherwise you'll be creating a new thread for every http application that starts up.

They're just normal event handlers so they'll get cleaned as normal, dispose tends not to be pretty obsolete in the http module design.. not sure why its not a proper disposable patterned object, could be it was designed before idisposable was well defined.