• Choose a category
• All
• Classic-Fiction

The following listing shows the implementation of the Init and Dispose methods for the sample module:

public void Init(HttpApplication app)

{

// Register for pipeline events

app.BeginRequest += OnBeginRequest;

app.EndRequest += EndRequest;

}

public void Dispose()

{

}

The BeginRequest and EndRequest event handlers have a similar structure. They obtain a reference to the current HttpApplication object from the sender and get the HTTP context from there. Next, they work with the Response object to append text or a custom header:

public void OnBeginRequest(Object sender, EventArgs e)

{

var app = (HttpApplication) sender;

var ctx = app.Context;

// More code here

...

// Add custom header to the HTTP response

ctx.Response.AppendHeader("Author", "DinoE");

// PageHeaderText is a constant string defined elsewhere

ctx.Response.Write(PageHeaderText);

}

public void OnEndRequest(Object sender, EventArgs e)

{

// Get access to the HTTP context

var app = (HttpApplication) sender;

var ctx = app.Context;

// More code here

...

// Append some custom text

// PageFooterText is a constant string defined elsewhere

ctx.Response.Write(PageFooterText);

}

OnBeginRequest writes standard page header text and also adds a custom HTTP header. OnEndRequest simply appends the page footer. The effect of this HTTP module is visible in Figure 4-7.

Figure 4-7. The Marker HTTP module adds a header and footer to each page within the application.

Registering with the Configuration File

You register a new HTTP module by adding an entry to the section of the configuration file. The overall syntax of the section closely resembles that of HTTP handlers. To add a new module, you use the node and specify the name and type attributes. The name attribute contains the public name of the module. This name is used to select the module within the HttpApplication’s Modules collection. If the module fires custom events, this name is also used as the prefix for building automatic event handlers in the global.asax file:

type="MarkerModule, AspNetGallery.Extensions" />

The order in which modules are applied depends on the physical order of the modules in the configuration list. You can remove a system module and replace it with your own that provides a similar functionality. In this case, in the application’s web.config file you use the node to drop the default module and then use to insert your own. If you want to completely redefine the order of HTTP modules for your application, you can clear all the default modules by using the node and then re-register them all in the order you prefer.

Note

HTTP modules are loaded and initialized only once, at the startup of the application. Unlike HTTP handlers, they apply to any requests. So when you plan to create a new HTTP module, you should first wonder whether its functionality should span all possible requests in the application. Is it possible to choose which requests an HTTP module should process? The Init method is called only once in the application’s lifetime, but the handlers you register are called once for each request. So to operate only on certain pages, you can do as follows:

public void OnBeginRequest(object sender, EventArgs e)

{

HttpApplication app = (HttpApplication) sender;

HttpContext ctx = app.Context;

if (!ShouldHook(ctx))

return;

...

}

OnBeginRequest is your handler for the BeginRequest event. The ShouldHook helper function returns a Boolean value. It is passed the context of the request—that is, any information that is available on the request. You can code it to check the URL as well as any HTTP content type and headers.

Accessing Other HTTP Modules

The sample just discussed demonstrates how to wire up pipeline events—that is, events fired by the HttpApplication object. But what about events fired by other modules? The HttpApplication object provides a property named Modules that gets