So this is a bit of asp.net I feel like way too many people don't understand. That is to say, I don't understand it and I've asked a bunch of people/googled and no one else seems to know the specifics either.
By default ASP.Net applications will serve files in Content and Scripts directories as static content. In fact, if I create other directories, I think it will serve static content in these as well.
However, the contents of some directories won't be served - the typical Asp.Net Mvc Controllers directory for example. In addition, you can always configure routes in asp.net (or OWIN handlers) that will pick up certain routes but not either.
Nothing seems to be configured anywhere. I have my suspicions, but I'm really not clear on what exactly is the rule for what gets served as static content and what gets processed by asp.net?
I've always found this graphic helpful: https://web.archive.org/web/20211021221111/https://www.4guysfromrolla.com/images/step2.gif
Specifically, the HttpHandlers mentioned in that graphic correspond to this section of the Web.Config file in your .NET web project's root directory:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
The path attribute of that tag can be used to configure only certain directories being handled by a certain class. At that point, IIS will hand off the HTTP request to the appropriate class, with the proper context and thread etc. My guess is that if you are running IIS with multiple frameworks, each has a distinct path associated with its add-handler tag.
Additionally, IIS has its own default settings for what file extensions are mapped to what handler classes. These can also be modified in the IIS management interface, so it's possible that your super-helpful ops team added that for you there even if it's missing from your web.config. At the end of the day, though, it's a relationship between url-HttpHandler class that determines static-file versus dynamic.
Edit:
There's another set of tags, outlined at this ServerFault answer:
https://serverfault.com/questions/175499/serving-cs-csproj-files-on-iis7-5
That describes a <add fileExtension=".cs" allowed="false" /> tag that operates on the file extension as opposed to a pattern on the entire path. This is what disallows files ending in .cs, and .csproj from being served. Additionally, since you're operating on an installation of IISExpress, you should know that it uses a different configuration file than the standard machine.config. The path for that file is described at this answer:
Where is the IIS Express configuration / metabase file found?
All this gets muddied a little by the notion of self-hosting, aka no IIS. Nancy does this, I believe, and ServiceStack can as well. I have no experience doing that, but the way they handle paths is probably a little different.
Related
I've got informed that following the general Microsoft recommendation our web servers will be reconfigured; among other things the allowSubDirConfig setting should be set to false. Thus, our ASP.NET applications must use a single Web.config at their root level (which is quite okay for our applications by the way).
However, ASP.NET MVC uses a "non root level" configuration file (by default!) for the Views directory, which contains a simple (but important?) web server related section:
<system.webServer>
<handlers>
<remove name="BlockViewHandler" />
<add name="BlockViewHandler"
path="*"
verb="*"
preCondition="integratedMode"
type="System.Web.HttpNotFoundHandler" />
</handlers>
</system.webServer>
Regarding to a post by Phil Haack this is security related, hence important.
Since the other .NET Framework related sections still work, because the ASP.NET runtime does not obey the allowSubDirConfig setting, an ASP.NET MVC application still works too. So the ignored web server configuration doesn't really attract attention during general usage, although i've a bad feeling about it.
Isn't that a lousy idea? If web servers are configured that way (by recommendation), how vulnerable are those ASP.NET MVC applications out there?
The HttpNotFoundHandler has a path attribute which means you can add it to the root config file and point path to the Views folders and you would not be altering the security level in any way:
<system.webServer>
<handlers>
<remove name="BlockViewHandler"/>
<add name="BlockViewHandler" path="Views/*" verb="*" preCondition="integratedMode" type="System.Web.HttpNotFoundHandler" />
</handlers>
</system.webServer>
This will work with a basic web.config file, but beware if you are adding/removing handlers as part of your application. Handlers that come before the BlockViewHandler could still deliver content from the Views subfolder (but then I believe this is also the case with the standard web.config in the Views directory unless you remove the handler there specifically).
Generally speaking IIS will not serve .cshtml files from the Views folder (unless specifically allowed) even if the system.webServer section is missing/ignored in the Views subdirectory.
But it would serve other files (e.g. html,css,js) which would be blocked by the BlockViewHandler handler which could be regarded as reduced security.
IIS Express is producing 403.14 Forbidden errors when a URL that would otherwise be handled through ASP.NET URL routing happens to correspond to a physical folder in my ASP.NET project. (The folder contains only code, and it's coincidental that the folder name happens to match the URL of a page; my URL structure is determined dynamically by a database, and users can edit that structure, so although I could just rename my project folder, in general I can't prevent this sort of collision occurring.)
This seems to be happening because the DirectoryListingModule steps in to handle the request, and then promptly fails it because directory browsing is disabled. I've tried removing this:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFile" path="*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
That removes the default StaticFile handler configuration, which has modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule", and replaces it with a configuration that provides just the feature I want. (I want static file serving, but I have no need for directory listing or default documents in this app.) But the effect seems to be that IIS then produces a completely empty (0 byte) response (with a 200 status) when I hit the offending page.
So next, I tried configuring the StaticFile handler to handle only the specific physical folders that I want to make available:
<system.webServer>
<handlers>
<remove name="StaticFile" />
<add name="StaticFileCss" path="style/*.css" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
<add name="StaticFileScripts" path="Scripts/*" verb="*"
modules="StaticFileModule" resourceType="Either" requireAccess="Read" />
</handlers>
</system.webServer>
But when I hit the offending URL, this then produces a 404.4 - Not found error, with a message of The resource you are looking for does not have a handler associated with it.. (The Detailed Error Information on the error page says that we're in the IIS Web Core module, during the MapRequestHandler notification, the handler is Not yet determined, and there's an Error Code of 0x80070002, which is a COM HRESULT that corresponds to the Win32 ERROR_FILE_NOT_FOUND error.)
The mystifying thing is that it's not even bothering to ask ASP.NET whether it has a handler for it. IIS seems to be deciding all by itself that there definitely isn't a handler.
This only happens when there's a folder that matches the URL. All other resources with dynamically-determined URLs work just fine - IIS asks ASP.NET for a handler, ASP.NET's routing mechanism runs as normal, and if the URL corresponds to one of my dynamically defined pages, it all works fine. It's just the presence of a physical folder that stops this all from working.
I can see it's IIS doing this because I get one of the IIS-style error pages for this 404, and they have a distinctive design that's very different from the 404s produced by ASP.NET. (If I try to navigate to a URL that neither corresponds to a physical folder, nor to a dynamic resource, I get a 404 page generated by ASP.NET. So normally, IIS is definitely handing requests over to ASP.NET, but IIS is definitely getting in the way for these problematic resources.)
I tried adding this inside my <system.WebServer>, in case the problem was that IIS has decided that requests corresponding to physical folders do not meet the managedHandler precondition:
<modules runAllManagedModulesForAllRequests="true">
But that doesn't appear to help - it still doesn't get ASP.NET routing involved for URLs that correspond to physical folders. In any case, it would be suboptimal - I would prefer not to have managed handlers run for the content that I definitely want to handle as static content. I effectively want ASP.NET URL routing to be used as a backstop - I only want it to come into play if the URL definitely doesn't refer to static content.
I don't understand why ASP.NET isn't even asking ASP.NET what it thinks in this scenario. Why is it not calling into ASP.NET during the MapRequestHandler phase if there's a physical folder that happens to correspond to the URL?
When a physical file or folder with the same URL as the route is found, routes will not handle the request and the physical file will be served.
Althrough you can change this behavior by setting the RouteExistingFiles Property from the RouteCollection object to true.
Take a look at the MSDN page Scenarios when routing is not applied
Forgive me if this is basic. I've never made one before and can't seem to figure out why it's not working. I wrote a little handler to do some parsing on CSS files. I added this:
<system.web>
<httpHandlers>
<remove verb="*" path="*.css"/>
<add verb="*" path="*.css"
type="MyNameSpace.CssRelativePathHandler,CssRelativePathHandler" />
</httpHandlers>
</system.web>
Nothing ever happens. CSS files get parsed normally. No errors, nothing, the code never runs. What am I missing? Shouldn't this cause the handler to be used when *.css files are served? (I added the "remove" later, since I thought perhaps I needed to do that to override a built-in hander, again, no difference either way).
This is IIS 6. I added the IIS 7 code anyway (after searching for answers) but makes no difference.
<system.webServer>
<handlers>
<add name="CssHandler" verb="*" path="*.css"
type="MyNameSpace.CssRelativePathHandler,CssRelativePathHandler" />
</handlers>
</system.webServer>
You need to configure IIS6 to send requests for .css files to ASP.Net.
Had you been using IIS7, your <system.webServer> element would have done that for you, but IIS6 predates this.
For IIS 6 you need to have to tell it to send *.css files to ASP.NET.
Launch IIS Manager
Right-click on Default Web Site
Click on the Home Directory tab
Under Application Settings click on Configuration...
Add a new association for .css and map it to .NET executable:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
It sounds like you need to configure IIS to enable ASP.NET to execute the .css extension.
Phil Haack has a walkthrough on doing that (just replace .mvc with .css under the heading "Mapping .mvc to ASP.NET"):
http://haacked.com/archive/2008/11/26/asp.net-mvc-on-iis-6-walkthrough.aspx
Or you can set up a wildcard mapping in IIS 6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5c5ae5e0-f4f9-44b0-a743-f4c3a5ff68ec.mspx?mfr=true
I'd recommend going with the first method as doing the wildcard approach will send all requests to ASP.NET - so it has a more overhead.
PS: Further down Phil's post, he also lists "IIS6 Extension-less URL" and also covers the wildcard mapping method.
We are working on a web application that creates more web applications.
Each web application will have to get a Url Rewrite rule (URL REWRITE MODULE 2.0).
As far as I know, there's no way to add such rules without modifying the web.config file (am I right??).
So my plan was to work with multiple web.config partial files. One main .config file, and lots of .config files per application (every file will contain it's web application url rewrite rules).
This way sounds a little bit messy, but I can't think of anything else, and suggestions will be welcomed.
So is it possible to use very-multiple web.config files for the root application?
Thanks in advance, Gal.
This following Tag will do the trick.
The absence of this tag was the main reason for my problem when i using with two web.config files for my two different application running in my website.
**<location path="." inheritInChildApplications="false">**
<system.web>
<!-- ... -->
</system.web>
**</location>**
Every application must have a full web.config and not partial, exept if you go with net 4
The trick is to use a lot the remove command on the other inside web.config and remove the parents setting that must not used on this.
For example if on the main root you have the a module that you do not won to use it on the other trees, you use the remove command on all other web.config to remove it. Especial the modules that are on one Bin and not on an other directory bin.
<httpModules>
<remove name="TheHttoModuleNotNeedHere" />
<remove name="AnonymousIdentification" />
... add here your other modules for that directory...
</httpModules>
The remove command is working for almost all sessions on config.
You can do make it work, I have done it, but its a lot of work to find all the conflicts/unnecessary configs and remove it.
For some other session there also the clear command. For example on role Manager you can clear all and add new.
<roleManager enabled="true" ...>
<providers>
<clear />
<add name="MyName" ... type="System.Web.Security.SqlRoleProvider" />
</providers>
Hope this help as tips to make it work.
The application folders in ASP.NET are used for storing various elements critical to running a website. I want to get a handle on understanding these folders in more depth, specifically the folder accessibility. According to the article on ASP.NET Web Site Layout:
The content of application folders,
except for the App_Themes folder, is
not served in response to Web
requests, but it can be accessed from
application code.
Any browser request to these folders results in a "404 - Page Not Found."
So what prevents folders like App_Code, App_Data, App_WebReferences, bin, etc. from being served to users? Is it an IIS hard coded "don't serve this folder?" Is it a permissions configuration? And is there anyway to knowingly/unknowingly circumvent this?
On my IIS7.5 config, found at C:\Windows\System32\inetsrv\config\applicationHost.config there is this section:
<hiddenSegments applyToWebDAV="true">
<add segment="web.config" />
<add segment="bin" />
<add segment="App_code" />
<add segment="App_GlobalResources" />
<add segment="App_LocalResources" />
<add segment="App_WebReferences" />
<add segment="App_Data" />
<add segment="App_Browsers" />
</hiddenSegments>
See also IIS Documentation.
In IIS7 on Windows Server 2008, ASP.NET is more tightly integrated into the entire processing pipeline, so I would imagine that in IIS7, it is very easy for ASP.NET to say "No, I'm not going to touch that."
In IIS6, IIS itself has very little direct knowledge of IIS, instead, it's all controlled through the ISAPI configuration.
In the IIS6 IIS Manager, right click a website, get Properties, go to the Home Directory tab, and then click Configuration in the lower right. This shows the ISAPI application extensions and what is done for each one.
For all the ASP.NET extensions (aspx, ascx, config, browser, a ton of others) it specifies handling to be done by C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
The ASP.NET system then has registered handlers for each of these file types defined in the global machine.config and/or web.config files at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG
For instance, in the global web.config file, under httpHandlers element:
<add path="*.ascx" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
So it is not just these special folders, but many types of files, but many types of reserved files that are disallowed from browsing.
The .net framework itself intercepts requests to these folders (along with a bunch of other file types that you should be allowed to browse) and returns a 404 to IIS, which then gets passed back to the browser as "404 - Page Not Found".
So it doesn't happen at the permissions level, or even the IIS level. It's inside the framework -- probably in one of the HttpHandlers in the global web.config.
If you look in there, you can see a ton of file extensions that are explicitly configured to not be served. Presumably you could tweak the settings and cause it to serve, say, web.config files as xml (which is different than the usual behavior of saying that this file type is not served).
It's worth noting that I don't specifically see any of the special folders (app_code, etc) mentioned in the global web.config file. Maybe it's handled inside other HttpHandlers -- for instance, the handler for .aspx might contain some code that prevents serving of .aspx files located in special folders, etc.