IIS and ASP.NET Configuration
HTTP requests in IIS arrive at the appropriate extension: aspnet_isapi.dll or asp.dll. ASP.NET requests get passed
through to the ASP.NET runtime. It’s this application that processes incoming
In IIS 5, the inetinfo.exe process
hosts aspnet_isapi.dll. This passes
requests into the managed ASP.NET runtime to invoke an HttpHandler. There is a thread that
processes this request, running within the ASP.NET worker process inside an appdomain. In IIS 5, therefore, every application has its
own appdomain. Every time an HTTP request comes in,
it gets its own thread from the thread pool.
In IIS 6, the process is slightly different. The kernel (http.sys) directly passes requests
to the correct pool within the HTTP runtime, thus bypassing a step. We can now
have multiple processes running (w3wp.exe).
Configurable pipeline components include HTTP handler factories, HTTP handlers,
HTTP modules and SOAP extensions. You can configure any or all of them together
as part of the round-trip.
These are objects that can interact with every
HTTP request, and use an event-driven model to interact with web applications.
You can create custom modules that listen to incoming requests and process
things such as custom authorisation, error handling,
diagnostics, session state management or diagnostics. Shipped in the box are: WindowsAuthenticationModule,
and others. In the same way as for handlers, you can configure modules through
section in machine.config.
All modules implement IHttpModule
and add an event handler for events occurring within the Application object. Within a event handler, you can access the HttpApplication object – sent as
the event source.
Michele showed how you could create a custom authentication module so that
guest users could gain access to a site without being fully logged in, using
the module to give non-logged in users a set of roles and set the auth cookie.
HTTP Handler Factories
HTTP Handler factories return an HTTP handler to process incoming requests.
You can use this to intercept requests for specific resources or format custom
types. You could even use an HTTP Handler Factory to create a request for a
file that doesn’t even exist, and construct it on the fly (a classic example of
this is the trace handler that deals with .axd
requests). All handler factories implement IHttpHandlerFactory, which has two
methods: GetHandler() returns an IHttpHandler given the HttpContext and ReleaseHandler() cleans up any resources. The handler
factory could even return different handlers depending on the context (for
example, different user roles).
setting to select which class factory is used to handle incoming requests. For
files are handled by System.Web.UI.PageHandlerFactory
and .config files
are handled by System.Web.HttpForbiddenHandler
(which prevents their download). The default configuration in machine.config
can of course be overridden in web.config to alter settings at the application level.
For example, you might choose to handle XML files and apply some settings, or
disallow additional file extensions by routing other calls to the HttpForbiddenHandler.
Handlers themselves implement IHttpHandler
– an interface with a ProcessRequest() method to do the work, and an IsReusable
read-only boolean property. To access the session
from a custom handler, you also need to implement a marker interface IRequiresSessionState
in the HTTP handler. There’s also an asynchronous Begin/End design
pattern that enables you to offload incoming requests to their own thread. But
this may not improve performance as the work still needs to be done!
Don’t forget that you need to add a mapping to the aspnet_isapi.dll extension if you want it to handle file
types that aren’t already passed to ASP.NET. Otherwise the file will be handled
by inetinfo.exe directly and will
never be seen by the handler.
You can also use handlers without having to modify a config
file by creating an endpoint with an .ashx extension. This allows you to create a web
handler class using a attribute – the handler factory is
already provided for you.
SOAP extensions provide a method to interact with incoming web service
requests. You can create your own custom SOAP extensions in a pipeline process
to handle the data en route between aspnet_isapi.dll
and the web service method. This is how WSE is implemented.
Incoming requests are routed to an HTTP handler that derives from WebServiceHandler.
(There are four variants to handle aspects such as sessions and asynchronous
communication.) The handler routes calls to a SOAP extension before and after
execution of the web service method.
To implement a SOAP extension, you can either create an extension class that
derives from SoapExtension,
or create an attribute class that derives from SoapExtensionAttribute. The
extension class has a ProcessMessage() method (allowing the message to be
handled) and a ChainStream() (allowing the stream to be edited).
These extension classes are once again invoked using web.config or machine.config.
UVN Pardha Saradhi