We have a website that makes use of .less files (the pre-compiler dotless has been installed using nuget), however the .less files are not handled as css files.
When trying to view the website in firefox, the console gives use the following error:
The stylesheet http:// website/css/init.less was not loaded because its MIME type, "application/octet-stream", is not "text/css".
Our dotless file is trying to import more files:
#import "imports";
..
But even replacing this text with css code, the styles are still not applied. But if I go to that file in Visual Studio, it is displaying all the css from the files that are imported.
If you're using the dotLess handler to process and serve your .less files on the fly (which is fine for debugging, but you might want to consider pre-compiling for release), you need to ensure that you also send them down with the correct mimetype.
You can do this either at the server level in IIS Admin (if you're likely to using this for multiple sites on the machine), or at the local site level via the web.config - note that you can't do both, IIS will complain that there are multiple entries for the file extension.
To do this in the web.config, within the <configuration><system.webServer> element add the following elements:
<staticContent>
<mimeMap fileExtension=".less" mimeType="text/css" />
</staticContent>
Obviously, if you've already got some mimemap entries, just add the mimemap there.
This will ensure that IIS claims that the .less files served from the handler as CSS rather than the default application/octect-stream.
If that's still not serving them as processed, there are a couple of other things you'll need to check:
Ensure that the handler is correctly registered in both the <system.webserver><handlers> and <system.web><httpHandlers> sections (depending on the version of IIS you're using:
<add name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
and
<add path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler, dotless.Core" />
Ensure that IIS is configured to send all requests through the ASP.NET handlers configured in step 1. By default, .less files are probably being considered "static files" and will only be handled by the StaticFileModule.
Related
I´m using Plesk and in Web scripting and statistics I have Microsoft ASP support in ON.
I uploaded a application (which works correctly in my PC) to a directory and it can be shown but when I go to the aspx file it shows me the 404 error (The path is the correct).
I noticed that some files in "shtml" extension are neither shown by the server.
This is my very first time with ASP.NET, ISS8 and Plesk. I don´t know what to do. I will thank you for your help
You have to set the HTTP Handler Extension. If you have no access to IIS directly, you could do on the web.config:
Open the Web.config file for the application, locate the httpHandlers element of the system.web section and add an entry for the file-name extension
Example:
<system.webServer>
<handlers>
<add name="SampleHandler" verb="*"
path="SampleHandler.new"
type="SampleHandler, SampleHandlerAssembly"
resourceType="Unspecified" />
</handlers>
</system.webServer>
For more configuration options please refer to:
https://msdn.microsoft.com/en-us/library/bb515343.aspx
and
https://msdn.microsoft.com/en-us/library/46c5ddfy(v=vs.100).aspx
Check also the Custom Handler Policy of Plesk that should not be enabled:
https://docs.plesk.com/en-US/onyx/administrator-guide/plesk-administration/securing-plesk/custom-handlers-policy.76787/
Here I've found also another interesting document:
https://learn.microsoft.com/en-us/iis/configuration/system.webserver/handlers/
Scroll down and you'll find a piece of code to add the handlers programmatically, even if I suggest you to add them in your web.config
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.
In IIS, can I configure it to return different cache-control headers for different static file types in the same folder?
I'm aware that I can use the HTTP Headers feature to set Expires Immediately, but that seems to affect all content. Is there a way to do it for specific file extensions for static content?
While not an ideal answer, I did find a work-around. In my application, I have control over where my JS, CSS, and other similar files live in the directory structure. What I did was put a web.config in the IIS root directory with these lines (among others, unrelated):
<configuration>
<system.webServer>
<staticContent>
<clientCache cacheControlMode="DisableCache" setEtag="true" />
</staticContent>
</system.webServer>
</configuration>
This sets the default in IIS that nothing should be cached. This is where the HTML page (index.html) for my single-page-application (SPA) lives, so that's what I want.
Then, in immediate subdirectories for images, JS, CSS, etc, I have web.config files with the following:
<configuration>
<system.webServer>
<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="14.00:00:00" setEtag="true" />
</staticContent>
</system.webServer>
</configuration>
You can of course set the age to whatever you want. I am starting with 14 days for now until I'm sure I everything right, then I will probably bump that to several months.
This way, the HTML of my SPA will never get cached, but all the JS/CSS/images will live as long as I want. When I rebuild the project for next deployment, web-pack will generate new file names for the packed JS and CSS, so no cache problem there. The HTML file will be the same name of course, but the included JS file names will be different. So it's key that the HTML file not ever be cached, which this setup accomplishes.
IIS should really make this simpler. A cache-by-file-type config would work perfectly and not require strict directory structure management, which not all projects have the flexibility to follow.
I'm introducing LESS into an existing ASP.NET web forms application. In order to get intellisense to work, I decided to set up the LessCssHttpHandler to intercept requests for files ending in .less.css. That way, Visual Studio still thinks we're dealing with a CSS file. I did this by adding the following line to my web.config file:
<add type="dotless.Core.LessCssHttpHandler, dotless.Core"
validate="false" path="*.less.css" verb="*" />
In order to get this to work, I had to tweak my IIS settings so that .css files get handled by the ASP.NET framework. Unfortunately, by doing so, now my existing .css files (which aren't handled by the dotless HTTP handler since they don't end in .less.css) aren't returning any content. This makes sense since the ASP.NET framework doesn't really know what to do when it sees a file with that extension.
Is there some sort of base HTTP handler I can set up in addition to the one I have above to handle normal .cssfiles? Something like:
<add verb="*" path="*.css" type="insert some base HTTP handler here that will simply return the contents of the file" />
Looks like the StaticFileHandler is what I was looking for. This is how we ended up adding it to our httpHandlers node in web.config:
<add verb="*" path="*.less.css" validate="false" type="dotless.Core.LessCssHttpHandler, dotless.Core, Version=1.1.0.7, Culture=neutral, PublicKeyToken=96B446C9E63EAE34, processorArchitecture=MSIL" />
<add verb="*" path="*.css" type="System.Web.StaticFileHandler" />
We use Chirpy for our LESS support (as well as our google closure compiler support). It allows you to configure file extensions for LESS, such as .less.css, and then you can have Intellisense support.
It doesn't do translation at runtime but rather at design time within visual studio. When you edit and save the LESS file, Chirpy kicks in and processes the LESS file which generates the css file. This way we avoid having to hand off css file serving to ASP.NET.
I tend to use the console compiler and rename the less file to .css
The httphandler is usually only for people who need parameters in their CSS.
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.