1/23/16

ASP.NET MVC Remove Unwanted HTTP Response Headers

When creating Web apps using ASP.NET technologies, we notice than on the response headers there are some entries that we often take from granted as being part of the technology and/or web server. These common entries are listed below:

Response Headers

Name
Value
Description
Server
Microsoft-IIS/8.0 
 Indicate the version of the web server
X-AspNet-Version
4.0.30319 
ASP.NET runtime version
X-Powered-By
ASP.NET 
Custom header (IIS)
X-AspNetMvc-Version
5.2 
MVC runtime version

Note:  Notice the header values and compare to your current environment as other version of IIS may not work the same.

We may think that these headers are by default, so it should be OK to have them. Hey, they are not visible, so what is the harm?  Well, the answer is that these additional headers offer no content related data, and search engines like Google and Bing are all about content, so this is why many SEO validation tools report that these headers should be removed. So the short answer is that it is good SEO to remove unwanted headers. In other technical concerns, these headers take space and provide information about the server and technology.

OK, let’s take a look at how we can remove these headers. We may think that this can easily be done in one place, but the problem is that these headers are added by different modules or the web server. We first need to take a look at each header and see its source, so we can understand how to remove it.

Response Header Source

Name
Source
Description
Server
IIS
added by IIS server
X-AspNet-Version
ASP.NET
 added by ASP.NET runtime
X-Powered-By
IIS
custom header added by IIS
X-AspNetMvc-Version
MVC.NET
added by the MVC Handler runtime

Now that we know where the headers come from, we can make our changes to remove them.  Our goal is to manage these changes with the constraint that we do not have access to our web server, so let’s not think that we can just configure IIS.

Server Response Header

In an ASP.NET app, the response headers can be managed by using the web.config. We need to add the following entry below by setting removeServerHeader attribute of the requestFiltering element to true:



<system.webServer>
   <security>
      <requestFiltering removeServerHeader="true"/>
   <security>
</system.webServer>


X-Powered-By Response Header

Since this is an IIS custom header, we can remove this header by using the web.config as well. For this header, we need to use a different section as listed below. We add the remove element under the customHeader section for each custom header we want to remove. Note that this only works for custom headers, so adding the Server header name here does not remove it.


<system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By"/>      
      </customHeaders>
    </httpProtocol>
  </system.webServer>


X-AspNet-Version Response Header

This header is added by the ASP.NET runtime.  Lucky for us, there is also a section in the web.config that can help us remove it. For this we set enableVersionHeader attribute of the httpRuntime node to false:


<system.web>
    <httpRuntime enableVersionHeader="false" targetFramework="4.5.1" />
</system.web>


X-AspNetMvc-Version Response Header

Similar to the X-AspNet header, the X-AspNetMvc header is added by the MVCHandler runtime. Unfortunately for us at the time of this writing, the only way to remove this header is by making a code change. The simple approach is to add the following code in the Global.asax.cs file:


public class MvcApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {

           MvcHandler.DisableMvcResponseHeader = true;
        }
    }


OK, that was all over the place, but it is a good exercise to understand the source of these response headers. Now that we have made those changes, we could run the application locally and open our favorite browser development tools.  We should see that those headers are now gone.

We can now prepare to deploy to production and run a SEO tools against our web app. It should now tell us that it is happy about not finding those headers.

This solution also works for Azure Hosting.


Happy ASP.NET + SEO.

1 comment :

What do you think?