I've been successfully using .less files in my dev Cassini server (with dotless) for a few weeks but when I publish to my local IIS server they yield 404 errors. Attaching my debugger to IIS yields no exceptions. I've restarted my IIS app pool and server as well.
Any ideas?
Looks like you're missing a mime type on IIS.
For IIS7 add the following to your web.config:
<system.webServer>
<staticContent>
<mimeMap fileExtension=".less" mimeType="text/css" />
</staticContent>
</system.webServer>
For IIS6 you can do (presuming you have administrator RDP access):
cscript adsutil.vbs set W3SVC/1/Root/MimeMap ".less, text/css"
Where /1/ is the IIS number of the site.
Just adding (quite late, I realize) my two bits to this discussion.
I just ran into the same symptoms and the previously mentioned fix did not work for me. I did however end up finding another reason for these symptoms and a solution for this.
The 404 response in my case contained the following message in the body of the response:
/* Error Occurred. Consult log or view on local machine. */
This seems to be an indicator that the less file was indeed found and the request was being processed by dotLess (the message can be found in dotLess's source code), but a FileNotFoundException occurred during processing the request.
I tracked down the problem to an #import statement that referred to a .less file that was mysteriously not present on the IIS server, even though it was present under the development server.
It turned out that the build action for this problematic .less file was set to None, not to Content, like all the other .less files in my project.
So the next logical question was why on earth was the Build Action incorrect?
Well, I had added the file as a .css file, then decided to import it into a .less file and thus renamed it to .less (since .css is a subset of .less, but less does not import css files). I repeated the process with a new .css file and found that the problem was reproducable.
It seems that Visual Studio changes the build action from Content to None behind the scenes as an unexpected side-effect of renaming .css to .less. Thus the renamed .less file does not get published to the IIS server.
Related
I'm running IIS 8 on Windows Server 2012R2, and I'm having an issue. I'd like to be able to host large files, but it's causing problems. If I put anything over ~400MB on it, then when I try to access that file from a browser I get a "404 file not found" error.
I should note that smaller files work fine. Any thoughts?
The problem could be that your MIME types need to be modified. From https://serverfault.com/a/78526/12894:
What is probably happening is that your server doesn't know that .war
is a type of file that needs to be downloaded rather than executed. It
then is run through your allowed Web Service Extensions for any
matches. If it doesn't find one, it throws a 404 error even though the
file does in fact exist.
If you set a MIME type for war files of type application/octet-stream,
that should resolve your issue.
See also the Microsoft article Requests for static files return 404 error (IIS 6.0)
Have you tried looking at the Web.config file for the maxrequestlength tag? The problem in this case is not the upload, but rather the request for the file, when the page is loaded. Look for the following line:
<httpruntime maxrequestlength="51200" executiontimeout="7200"/>
Where I set the second number to 2 hours (just a random timeout time) and the first number is the maximum file size that a page that needs the file can request. In this case, you can have 500Mb of upload size. This may fix it, however, there's also another section that you can edit, added in for security purposes:
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="524288000"/>
</requestFiltering>
</security>
Here, again you have 1024x1024*500=500Mb. This is edited in the session properties - you can do that through the Management Interface or through writing your own scripts. Have a look at MSDN here:
http://technet.microsoft.com/en-us/library/cc725820(v=ws.10).aspx
I know CF 10 has a number of issues surrounding 404 handling. This seems to be different from the other reports. Details:
Win2k8 R2/64 and IIS7.5
Upgrading from identical config on separate server. Only difference is CF9 -> CF 10. All works fine on CF9. Adobe CF9 Lockdown implemented on original server, CF10 Lockdown implemented on this server.
missing template handler set in CF Admin as /404.cfm, which should translate to the Cfusion root (c:\ColdFusion10\cfusion\wwwroot).
IIS has been config'd to trace failed 404 requests
IIS 404 handling is default (originally executed a CF URL but removed to simplify debug).
Coldfusion webroot where missing template handler resides is default install location
IIS site root is entirely different: c:\Other\Place\SiteRoot\
A sitewide error handler is also set in CF Admin in the same ColdFusion webroot and works as expected.
404.cfm is very simple:
<cfheader
statuscode="404"
statustext="Not Found">
<h1>404</h1><p>Page not found</p>
<cfoutput>#now()#</cfoutput>
Inputting the bad url [domain]/foo.cfm should display the above template. Instead I get an IIS error screen. The CF missing template handler is ignored. The IIS failed request trace says the url is
http://[mydomain]:80/jakarta/isapi_redirect.dll
and a detail view shows at Step 1
RequestURL="http://[mydomain]:80/foo.cfm
I've seen plenty of issues surrounding CF10 and 404's, but never that the missing template handler assignment is completely ignored. In CF9 this will generate output as expected. Anyone seen anything like this?
EDIT:
I have also tried config'ing this to match a different CF9 server I have running: Added a CF mapping to the web root of the site. Then placed the missing template handler in the web site's root rather than the CF default web root, lastly in cfadmin pointed to the missing template handler in the web site's root using the mapped folder. Same problem. Works fine in CF9 and not at all using CF10.
EDIT2:
As Miguel F pointed out in the comments, you can shut off HTML error codes in CF Admin and this will let the Missing Template Handler fire... BUT you get a 200 header to go with it. Apparently cfheader statements are ignored as I have tried placing the cfheader at the beginning and end of the template... still yields a 200. Visually fine but insofar as SEO is concerned thats a disaster. Just looked and my CF9 servers do not require this setting to be unchecked for their handlers to work.
EDIT3
Dana Kowalski's solution displays detailed IIS errors to the public, so for a 404 on, say, a made-up extension (foo.xyz), the screen will show file paths. Default behavior is to NOT display detailed errors except when running templates locally, and display custom error pages to visitors. The CF error template should work fine with that setting.
POSSIBLE SOLUTION
I stepped back to ColdFusion 9 as part of debugging this problem, and may have discovered the solution while debugging a separate related issue.
In the IIS Manager, click on the site in question. Select the Error Pages option. Select the 'Edit Feature Settings' link on the right side. Check that the 'Detailed Errors' option is selected.
If you have either of the other two selected, there are times IIS 7.x will take over and not let ColdFusion handle it.
To be able to get my application (Umbraco CMS) to handle 404 errors, I need to have following setting in my web.config:
<httpErrors existingResponse="PassThrough" />
It works well for displaying a custom 404 error page from Umbraco, but it doesn't work for displaying a 404 error page when a static file cant be found.
For example http://www.example.com/non-existing-file.png returns a 404 status code, but respons is blank. That fits with this description of the PassThrough mode:
PassThrough – If existingResponse is seen as “PassThrough”, custom
error module will always pass through responses from modules. This
setting will make custom error module return blank response if modules
don’t set any text.
(http://blogs.iis.net/ksingla/archive/2008/02/18/what-to-expect-from-iis7-custom-error-module.aspx)
What is the "custom error module"? And how do I get it to return a non blank response?
Update
After stepping through the request handling routines in Umbraco (with a debugger), I have a better understanding of the problem space. As written in the citation above, when existingResponse="PassThrough" then all handling of http errors is done in the custom modules. So to answer my own question, a "custom error module" is in this instance the "UmbracoModule".
One way to solve this problem would be to create a new custom module that will check for the existence of the static files on the disk. It can be done quite nice, I read the list of static files from IIS and read the configuration of customErrors or httpErrors elements from the web.config to get a custom error page. But I kind of think this is crude solution. I would much rather pass the responsibility back to IIS.
Any ideas?
You're correct. For the benefit of anyone else looking for help with this, here's some extra information on 404 handling.
Old Umbraco wiki page - describes your solution using the file /config/umbracoSettings.config
404 for files - works for Umbraco 7 and describes the use of the tag <httpErrors/>
IIS version 6 fix - fixing on IIS6 and how it compares with IIS7
How to enable the error information in the Sharepoint site by modifying the web.config file.?. I have done the following changes in web.config file
Callstack = true
CustomErrors mode = Off
Compilation debug = true
But still i am not able to get the call stack details(error details) in the sharepoint site for a error, instead of that i am getting this following error
"To enable the details of this specific error message to be viewable on the local server machine, please create a tag within a "web.config" file located in the root directory of the current web application". Please correct me on this?.
custom errors mode off, (or on, I can never remember). Then set debug=true. The catch is that there are many different web.configs used by sharepoint. There's one on the web application level (in inetpub, virtual directories), then there's one for layouts pages, control templates, etc in /web server extensions/14/. You have to make these changes in all of the relevant web configs associated with your code.
And obviously, make sure this is always turned off in production for security reasons.
You do not need to do an iisreset, changing a web.config file will cause one automatically.
Did you run iisreset?
Make sure you're changes in the web.config look like these:
<customErrors mode=”Off” />
<SafeMode … CallStack=”true” … >
<trace enabled=”true” pageOutput=”true”/>
PS: Showing stack traces in a production environment is not recomenned, instead use a tool like ULSViewer for diving through the log files.
I have a text file that I am trying to browse to using the browser http://files.mydomain.com/test.txt and I get a:
HTTP Error 404.0 - Not found
I double checked and the text file does exist. When I add a test.htm file, I have no issues.
Can someone help? Something tells me it's security issue.
Have you checked the following:
Your DNS 'A' record for 'files' is pointing to the correct IP address
If your server is using a shared IP address across multiple sites have you configured a HTTP host header?
Is there a mime type set for the .txt extension?
Have you made any changes to the Handler Mappings for the site? e.g. mapped the .htm extension to say the ASP ISAPI filter and accidentally removed the StaticFile handler?
Can you serve other static content such as .jpg, .gif, .pdf etc?
Kev has covered most of the possible problems, but for reference there is another possibility.
Confirm that in Request Filtering you either
have .txt as an Allowed extension, or
have Allow unlisted file name extensions ticked in Edit Request Filtering Settings
The same effect can be achieved with the following web.config section:
<system.webServer>
<security>
<requestFiltering>
<fileExtensions>
<add fileExtension=".txt" allowed="true" />
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
Also make sure also that the website is started. I was getting 404 and then realized that the Default Website was stopped because another website (Sharepoint) was using port 80. Sometimes the obvious is what gets you.
Add the MIME-Typ by going to ...
features / Mime-type
right click,
add,
put in the file extension ".txt"
and the mime-type "text/plain"
ok
et voila
I know this is an old post, but this might still help somebody out. I ran into this problem with my Asp.Net Core application. In my case it turned out that static files are served from a subdirectory called 'wwwroot' by default. Creating that subdirectory and moving the file in their solved it for me:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/index?view=aspnetcore-2.2&tabs=windows#web-root