Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Requests for static files are hitting the managed code in ASP.NET MVC3

Creating custom IHttpModules, I have realized that the requests for static files (e.g.: .css and .js files) are hitting the managed modules. Probably pictures have the same problem. Shouldn't IIS bypass ASP.NET for files that exists in the filesystem?

For example:

public class MyModule:IHttpModule
{
    public void Dispose(){ }

    public void Init(HttpApplication context)
    {
        context.BeginRequest += (o, e) => Debug.Print("Request: " + HttpContext.Current.Request.RawUrl);
    }
}

And I declare it this way:

<modules runAllManagedModulesForAllRequests="true">
  <add name="MyModule" preCondition="managedHandler" type="MVCX.Modules.MyModule, MVCX"/>
</modules>

But, even using the precondition I can see how the static files goes through the module:

Request: /MVCX/
Request: /MVCX/Content/Site.css
Request: /MVCX/Scripts/jquery-1.4.4.min.js

I have tried to ignore the rules for static files, but it does not make a difference:

routes.IgnoreRoute("{Content}/{*pathInfo}");
routes.IgnoreRoute("{Scripts}/{*pathInfo}");

Is this the usual? Or am I missing something here? As far as I know, if the static file request should be answered by IIS. If my managed module is being hit, means that a CLR ThreadPool thread is handling that request, right?

Regards.

UPDATE:

I have disabled the "runAllManagedModulesForAllRequests":

<modules runAllManagedModulesForAllRequests="false">
      <add name="MyModule" preCondition="managedHandler" type="MVCX.Modules.MyModule, MVCX" />
</modules>

And everything seems to work just fine, but I have found this article: http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html that recommends remove and readd the "UrlRoutingModule-4.0" module with an empty precondition.

I my machine, the adding of that module is in the root web.config, and it has already an empty preCondition:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config>type machine.config | find "UrlRouting"


C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config>type web.config | find "UrlRouting"
            <add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" />

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config>

So now I am a little bit confused, what is the status of this parameter? Should I use it or shouldn't? why does it come as "true" by default?

Regards.

like image 738
vtortola Avatar asked Dec 05 '11 15:12

vtortola


People also ask

Which of the following Middlewares must be installed to serve static files in ASP.NET Core application?

To serve static files from an ASP.NET Core app, you must configure static files middleware. With static files middleware configured, an ASP.NET Core app will serve all files located in a certain folder (typically /wwwroot).

Which of the files are static files in ASP NET MVC app?

In this article Static files, such as HTML, CSS, images, and JavaScript, are assets an ASP.NET Core app serves directly to clients by default.

How ASP.NET Core serve static files?

In ASP.NET it's easy to serve static files by using app. UseStaticFiles() as part of configuration. This simple configuration maps the wwwroot folder to the the / path and serves any content from that folder as static content, prior to processing other application middle ware like Razor Pages, Minimal APIs, MVC etc.


2 Answers

Answering your first question about the fact that IIS should bypass ASP.NET for static content.

If configured in integrated mode, IIS 7.5, will allow managed modules to register for events related to requests that are not traditionally handled by ASP.NET, like static files.

This does not happen in IIS 7.5 classic mode, which is similar to IIS 6 and does not allow for a managed module to listen for events in requests that are not handled by ASP.NET.

So, basically if you have runAllManagedModulesForAllRequests="true" with integrated mode, than your managed module will be notified of events for every request. Also, from the documentation on runAllManagedModulesForAllRequests:

True if all managed modules can process all requests, even if the request was not for managed content; otherwise, false.

The default value is false.

The documentation does not explain how this attribute interacts with the preCondition option. From what you experienced it seems to override the preCondition configuration, so I if were you I would leave it at false and just work with the preCondition options even if it means altering other modules preconditions to an empty string to workaround the change of runAllManagedModulesForAllRequests to false.


Update: Found some documentation on the implications of the use of runAllManagedModulesForAllRequests and as already stated, if true, is an override for the preCondition with a managedHandler option.

You can also use a shortcut to enable all managed (ASP.NET) modules to run for all requests in your application, regardless of the "managedHandler" precondition. To enable all managed modules to run for all requests without configuring each module entry to remove the "managedHandler" precondition, use the runAllManagedModulesForAllRequests property in the section:

When you use this property, the "managedHandler" precondition has no effect and all managed modules run for all requests.

like image 143
João Angelo Avatar answered Oct 05 '22 21:10

João Angelo


I my machine, the adding of that module is in the root web.config, and it has already an empty preCondition

Perfect. That means this module will always run which is required for MVC as it uses extensionless urls.

So now I am a little bit confused, what is the status of this parameter? Should I use it or shouldn't? why does it come as "true" by default?

Because extensionless url support is new in IIS7 SP1 and IIS7.5 SP1. It is available for IIS7 as a patch that you have to request and install. You will find it here with complete answers to your questions: http://support.microsoft.com/kb/980368

Why this parameter comes to true by default ? Because VS2010 was shipped before IIS7 SP1. Maybe it is at false in new MVC projects in VS2010SP1 ?

like image 25
Softlion Avatar answered Oct 05 '22 23:10

Softlion