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.
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).
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.
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.
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.
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 ?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With