Web application initialization is as follows:
- As we know when IIS receives the first request for a particular Asp.net application resource, IIS creates an instance of a
HttpApplication
(defined inglobal.asax
codebehind). - When this new instance is created it's initialization happens that also checks all configured HTTP modules.
- All modules are then instantiated and put in the application's
Modules
collection (of typeHttpModuleCollection
) - modules are looped through and their
Init()
method is called (when they register for request events)
As far as I understand it the above scenario happens when a web application is started/initialized (hence application start event).
What happens with modules?
Are they (re)instatiated on each request or reused from the Modules
property on each consecutive request while the web application is alive? As I understand IIS and Asp.net they are reused through the whole life of a web application.
If they are reused, can we assume that their Init()
method is actually a pseudo event handler for application start event? The thing is we can't attach to application level events within http modules. But if they are being reused we could use Init()
as application start event and do whatever we'd put in global.asax
instead.
Question
Can we assume that module's Init()
method is called only on application start event? Could we use this assumption to i.e. register routes for applications whose global.asax
codebehind we can't change? web.config
is usually accessible and we can change it the way we want.
Would this actually work?
Additional info
We can check HttpApplication
code and check its InitModulesCommon()
method. This one actually calls Init()
of each registered HTTP module. What is more interesting is that this method is only used by InitIntegratedModules()
and InitModules()
methods. Which are both used only in HttpApplication.InitInternal()
method. This is the basis of my assumptions, but I would like to know whether someone has abused IHttpModule.Init()
for application start event.