Remove default HTTP modules in ASP.NET

Published Sep 22, 2007

While hooking an HttpHandler up in web.config I thought about all the default HttpModules that are hooked up in machine.config. I did some research and found that the following modules are loaded into the ASP.NET pipeline by default:

[code:xml]

[/code]

If you don't use all of them, then why not remove them from the pipeline? This is a great question that I immediately had to find the answer to, but after a while I gave up finding anything on the web. Nobody has written about it. What I really wanted to know was how this will affect the performance of the application. The logical conclusion will be that it would boost the performance to have fewer modules in the pipeline, but I want to know how much. It should also reduce the attack surface.

The next question that needs an answer is which of the modules are safe to remove. I found that the UrlAuthorization and FileAuthorization modules act as a safeguard for security reasons, so they must stay. The three authentication modules can be removed if you don’t use them or at least the ones you don’t use. The rest can safely be removed if you don’t need them.

You can remove the modules you don’t need in the web.config like so:

[code:xml]

[/code]

If you know about the performance impact involved, please let me know.

UPDATE: Scott Guthrie says

This morning I checked my mail and saw one from Joe Kaiser. He had asked Scott Guthrie about this and here is his reply:

In general you can get some very small performance wins using this approach - although I'd probably recommend not doing it. The reason is that some features of ASP.NET (forms auth, roles, caching, etc) will of course stop working once you remove the modules they depend on. Trying to figure out why this has happened can often be confusing.

So there you have it. Small performance gains but you might be confused later on.

URL rewrites and the HtmlForm action attribute

Published Sep 22, 2007

A known bug in ASP.NET 1.x and 2.0 is that the action attribute of a form doesn’t respect URL rewrites. Everyone that uses URL rewrites uses one of several mechanisms to take care of the action attribute bug.

Recently it has been quite popular to use control adapters and .browser files to change the rendering of a form and its attributes. I’ve never liked that approach because it treats the symptom instead of fixing the problem in a transparent and clean way.

<strongOpinion>
The use of control adapters and .browser files to alter the output for different clients is just as bad as having separate stylesheet files for IE and Firefox. Instead of writing cross-browser mark-up and CSS you treat the browser differences as an illness and try to treat it. The thing is that you don’t cure it by using control adapters; you just treat the symptom of not being able to (or don’t care to) write cross-browser code.

However, it still has its right when dealing with mobile devices, but not much longer. The browser in the iPhone or Windows Mobile is becoming so good that it soon doesn’t matter anymore.
</strongOpinion>

In the past I’ve used a custom overridden HtmlForm but when I had to do it recently on my job, I thought it was about time to make it better and cleaner. I very much like the use of a custom form control approach because it is very transparent in what it does and where it does it.

The code

[code:c#]

#region Using

using System;
using System.ComponentModel;
using System.Web;
using System.Web.UI;
using System.Web.UI.HtmlControls;

#endregion

/// <summary>
/// A custom HtmlForm for use when a postback is made to a website
/// that has URL rewriting enabled.
/// </summary>
[DefaultProperty("Text")]
[ToolboxData("<{0}:RewriteForm runat=server></{0}:RewriteForm>")]
public class RewriteForm : HtmlForm
{
/// <summary>
/// Renders the attributes using the RewriteFormHtmlTextWriter.
/// </summary>
protected override void RenderAttributes(HtmlTextWriter writer)
{
RewriteFormHtmlTextWriter custom = new RewriteFormHtmlTextWriter(writer);
base.RenderAttributes(custom);
}

/// <summary>
/// Writes the HtmlForm's markup to support URL rewrites.
/// </summary>
private class RewriteFormHtmlTextWriter : HtmlTextWriter
{
    /// <summary>
    /// Initializes a new instance of the <see cref="RewriteFormHtmlTextWriter"/> class.
    /// </summary>
    /// <param name="writer">The writer.</param>
    public RewriteFormHtmlTextWriter(HtmlTextWriter writer)
      : base(writer)
    {
      base.InnerWriter = writer.InnerWriter;
    }

    /// <summary>
    /// Writes all attributes the normal way, but writes the action attribute differently.
    /// </summary>
    /// <param name="name">The markup attribute to write to the output stream.</param>
    /// <param name="value">The value assigned to the attribute.</param>
    /// <param name="fEncode">true to encode the attribute and its assigned value; otherwise, false.</param>
    public override void WriteAttribute(string name, string value, bool fEncode)
    {
      if (name == "action")
      {
        HttpContext context = HttpContext.Current;

        if (context.Items["ActionAlreadyWritten"] == null)
        {
          value = context.Request.RawUrl;
          context.Items["ActionAlreadyWritten"] = true;
        }
      }

base.WriteAttribute(name, value, fEncode);
}
}
}

[/code]

Download

RewriteForm.zip (320 bytes)