Here’s a cool new behavior in ASP.NET 2.0: Response.End() no longer kills post Application Handler events! In 1.1 if you called Response.End() ASP.NET inside of an HTTP Handler, the call caused the pipeline to effectively bypass the rest of the HttpApplication events. This could cause problems for any content modifying modules or Application level event hooks. In 2.0 post Handler events continue to fire.
The behavior seems to apply only to Response.End() operations that fire from within a handler – if you call Response.End() from within a module event (like Application.Authenticate) the request still ends.
I think this is the way it should work, but some people may find this change will break their existing applications if they relied on Response.End() to not do any further processing.
For my Core ASP.NET session I’m doing in Germany next week, I have one slide that talks about the problems with Response.End() in modules but it looks like this is no longer necessary. One of the examples I gave is adding a shareware message to the end of a request via a PostRequestHandlerExecute() method:
/// <summary>
/// Summary description for SharewareModule.
/// </summary>
public class SharewareMessageModule : IHttpModule
{
private const string SharewareMessage =
@"<br clear='all'><p><table align='center' width='100%' cellpadding='6' bgcolor='darkblue'>
<tr><td><img src='images/poweredbywwstore.gif'></td>
<td style='color:white;font-weight:bold' valign='center'>This is a <b>non-registered version</b> of the
<a href='http://www.west-wind.com/WestwindWebStore/' style='font-weight:bold;color:yellow;text-decoration:none'>West Wind West Wind Web Store</a>.
If you are running in a production environment, please <a href='http://www.west-wind.com/WestwindWebStore/' style='font-weight:bold;color:yellow;text-decoration:none'>register</a> this copy.
</td></tr></table>";
#region IHttpModule Members
public void Init(HttpApplication application)
{
application.PostRequestHandlerExecute += new EventHandler(application_PostRequestHandlerExecute);
}
public void Dispose()
{
}
#endregion
private void application_PostRequestHandlerExecute(object sender, EventArgs e)
{
HttpApplication app = (HttpApplication) sender;
// *** Must make sure we don't add this to data responses!!!
if (app.Context.Response.ContentType.ToLower() == "text/html")
app.Context.Response.Write(SharewareMessage);
}
}
This works in 1.1 as long as Response.End() isn’t called anywhere at which point the message no longer gets appended. In 2.0 the PostRequestHandlerExecute event fires even when Response.End() is called so the message gets ALWAYS appended.
Besides the obvious issue of by passing the behavior which may be critical for content or security, it’s also quite common in my applications to use Response.End() for generic pages that manage their own output generation through other pages (via Server.Execute() or internal generation). These pages are supposed to cut short any further output.
One example, is the generic MessageDisplay class I use to display status and or error messages in the system with a single line of code. These page calls get embedded into a page and need to tell the parent page to stop rendering. But I sure would hope that the modules still fire. Well, now they do…
BTW, the code above to append the shareware message on the bottom is probably not the best way to do this as it generates invalid HTML <g>. In fact, the way I actually do this is by intercepting the Page’s Render() method, but this is a lot less generic than an HTTP Module, since the Page class obviously has to inherit from the proper class in order for the behavior to be there. Modules or Application event hookups are much more generic and much harder to unhook if necessary. Another option would be a Response.Filter, but they tend to be a bit more work to set up and also slower to execute and manage as you have to look at every byte coming off the Response Stream... So since browsers seem to be OK with rendering HTML after the offical </html> tag I guess I can live with this for demo purposes.
Now playing: Fu Manchu - Hell on Wheels
Other Posts you might also like