I have done and checked the following.
1. made sure components are installed...
Made sure everything is enabled for the server in IIS
Made sure the site has modules enabled
Enabled the settings in web.config
<system.webServer>
<urlCompression doStaticCompression="true" doDynamicCompression="true" />
</system.webServer>
My site here http://tinyurl.com/lv44hl4 according to few sites when i enter my url in it says not compressed, for example
http://tinyurl.com/nzfv9z4 (GZIP TEST SITE WITH MY URL)
Am i missing something? (using IIS8, mvc5 and .net 4.5.1)
Ctrl-Shift-I will open developer tools in Google Chrome. According to that your content is compressed via gzip.
I'm not sure what I'm doing wrong but despite of everything I've tried, I don't seem to be able to get the clients to cache my static resources.
In my web.config, I've added the following entry:
<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
</staticContent>
According to the documentation, this should send a response header to the client browser to let it know we want to keep static content cached for 30 days.
If I use fiddler to see what the client is receiving, it looks like my web.config addition gets ignored completely.
Below is what fiddler is reporting:
Cache-Control: no-cache
Date: Mon, 05 Dec 2011 14:09:44 GMT
Expires: -1
Pragma: no-cache
Vary: Accept-Encoding
I don't have any headers in IIS overriding this so I'm not sure what is it that I am missing. Any help would be greatly appreciated.
I cracked this but it took a while. You're trying to force 304s from the server (no change). It differs with IIS versions.
It's best achieved by having all you're static content in one directory
(e.g. content so you'd have /content/css /content/js etc)
Then you just have to ensure everything under that directory doesn't expire for, say, 30 days.
IIS7
Much easier. Easiest way - add a web.config to the content directory referred to above. This web.config will have just the expires directive:
<system.webServer>
<staticContent>
<clientCache
cacheControlMaxAge="30.00:00:00"
cacheControlMode="UseMaxAge" />
</staticContent>
</system.webServer>
IIS6
You'll need to manipulate the metabase. It's not XML in IIS6, follow the instructions here: IIS6 ETags metabase commands
We used both the above and simple viewing of firebug shows 304s coming through.
I have an IIS7.5 web-site, on Windows Server 2008, with an ASP.NET MVC2 web-site deployed to it. The website was built in Visual Studio 2008, targeting .NET 3.5, and IIS 5.1 has been successfully configured to run it as well, for local testing.
However, whenever I try and navigate to a page running in IIS7, I get a 404 error.
I have checked the following things:
There is no corresponding 404 log entry in IIS logs.
Actually, there are 404 entries in the IIS log.
The application pool for the web-site is set to use the Integrated pipeline.
The "customErrors" mode is set to off.
.NET 3.5 SP1 is installed
ASP.NET MVC 2 is installed
I've used MVC Diagnostics to confirm all MVC DLLs are being found.
ASP.NET is enabled in IIS, which we've demonstrated by running the MVC Diagnostics page.
KB 2023146 did highlight that HTTP Redirection was off, so we've turned it on, but no joy.
EDIT
Ok, so we've installed the world's simplest MVC application (the one which is created when you create a new MVC2 project in Visual Studio), and we are still getting 404s on any page we try and access - e.g.
<my_server>/Home/About will generate a 404.
Any ideas will be greatly appreciated!
This is quite often caused by the following missing from the web.config:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
Do you have a problem with just 1 page or the whole site is not working?
A) 1 page
You can use RouteDebugger to verify if the route is matched correctly
B) Whole site
I assume you're using Windows Server - check if ASP.NET is enabled in IIS - it's disabled by default, I believe.
You can use MvcDiagnostics page to check if all dlls are deployed properly.
Are you running in IIS7 integrated mode? Classic mode of IIS7 does not automatically map extensionless URLs to ASP.NET (much like IIS6)
Make sure your Web.config tag is configured correctly.
We finally nailed this issue by exporting the IIS configuration of a working server, and comparing it to ours.
It was a really obscure setting which had been changed from the default.
IIS ROOT → request Filtering → Filename Extensions Tab → Edit Feature Settings → Allow unlisted file name extensions
This should be ticked.
This can be set at the IIS level, or the site-level.
Glad that fixed your problem. Others researching this issue should take note of the extensionless URL hotfix: http://support.microsoft.com/kb/980368
If none of the other solutions here solved your issue, check that you have the
Global.asax
file in your website. This solved the issue for me.
Checkout if KB 2023146 applies to your scenario. Also try requesting directly a controller action: /yoursitename/home/index
Apparently this can have many different causes.
For us, the problem was that the DNS entry was configured for two IP addresses, but the IIS configuration would only listen to one of them. So we got unpredictable results, sometimes it would work, sometimes a few files (css, etc) would not load, and sometimes the whole page would not load.
For me it was all about installing .NET Framework 4.6.1 on the server (my app was targeting that version)
You'll also get this if your bindings aren't correct. If you don't have www or a subdomain it'll return a 404.
I had this problem when running my MVC4 site with an app pool set to ASP.NET 4.0 and the Classic pipeline, even though the extension handlers were set in my web.config and were showing correctly in IIS. The site worked in Integrated Pipeline so I knew it was a configuration issue, but I couldn't nail it down. I finally found that ASP.NET 4 was disabled for the server in the ISAPI and CGI Restrictions settings. I enabled ASP.NET 4.0 and it worked.
In addition to checking if you're running in integrated pipeline mode, make sure your application pool is set to use .NET! I recently ran into this problem, and when I went in to check the app pool settings, I found that somehow it had been set to "No Managed Code." Whoops!
My Hosting company fixed this for me by doing this (I removed the original password value of course).
<system.webServer>
<security>
<authentication>
<anonymousAuthentication password="<password>" />
</authentication>
</security>
</system.webServer>
Typically I encounter this issue when there is a Routing problem. I compare a working vs non-working to resolve it.
Today however I accidentially created a Virtual Directory in IIS.
It has to be an Application, right click on the Virtual Directory (with a folder icon) -> Convert to Application:
Don't use runAllManagedModulesForAllRequests. You want to let IIS handle resources such as images.
<system.webServer> <!-- Rather do NOT use this -->
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
Instead add the MVC routing module
<system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
</system.webServer>
When I refresh my website in less than 2-3 minutes, Firebug shows these nice requests:
1. /core.css 304 Not modified
2. /core.js 304 Not modified
3. /background.jpg 304 Not modified
BUT when I refresh after >3 minutes, I get:
1. /core.css 200 OK
2. /core.js 200 OK
3. /background.jpg 304 Not modified
Why my CSS and JS files are downloaded again and images aren't?
I'm using ASP.NET MVC 3, I DON'T use [OutputCache], and in my /Content folder (where all css, js and img files live in subfolders) I have this Web.config:
<configuration>
<system.webServer>
<staticContent>
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="1.00:00:00" />
</staticContent>
</system.webServer>
</configuration>
which sets HTTP header Cache-Control: max-age=86400 ONLY. So basically CSS, JS and images are treated the same way, but somehow CSS and JS don't get cached for a longer period... why is that?
Hopefully this will help: http://www.iis.net/ConfigReference/system.webServer/staticContent/clientCache
The <clientCache> element of the <staticContent> element specifies cache-related HTTP headers that IIS 7 and later sends to Web clients, which control how Web clients and proxy servers will cache the content that IIS 7 and later returns...
This occurs with IIS or with the Visual Studio web server? for some time perceived this behavior while developing (using the VS web server), but when publish it in IIS this not occur anymore.
Could this be the bug in Firefox described here ?
You could test this by opening the same page in another browser and check what get's loaded using Fiddler or some other tool.
I have plugged in the HttpCompress module to enable compression for my MVC web application.
If I run my site through the development web server (Cassini) I have no troubles with the execution of compression.
However when I deploy the site to IIS6 the compression is not executing. I have checked the source code of the compression library and the CompressContent handler returns without acting becuase a null value exists for
app.Request.Headers["Accept-Encoding"]
My best guess is that this has something to do with the handling of extensionless urls in IIS6. What do I need to do to fix this problem in production?
[ below is the config for the module, if that is of any assistance ]
<blowery.web>
<httpCompress preferredAlgorithm="deflate" compressionLevel="high">
<excludedMimeTypes>
<add type="image/jpeg" />
<add type="image/png" />
<add type="image/gif" />
<add type="application/pdf" />
</excludedMimeTypes>
<excludedPaths></excludedPaths>
</httpCompress>
</blowery.web>
Some further investigation discovered that I was accessing the server via a proxy, and it appears that the proxy was not forwarding the compression headers to IIS.
It seems the easiest way to identify a proxy meddling with the request is to check the response headers for a via entry.
See the complete list of http headers as a homework task.