I have a web API endpoint called SaveEstimate which is returning a 404 error when certain data is POSTed. Based on research I did, I was originally thinking it was because of the file size. However, the file is less than 2MB and in my web.config file I have the following settings:
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="26214400" />
</requestFiltering>
</security>
and:
<httpRuntime targetFramework="4.7" maxRequestLength="26214400" />
The data being posted is the file (as a Base64 encoded string) along with some JSON data. I've tried setting up various logging in both IIS and in my site (to write to a file and SQL database), however this error is not being caught anywhere I can find.
If I do the test with a different (smaller) file, than the request completes successfully. This leads me to believe it has something to do with the file size but, unless I misunderstand the web.config settings, they should allow a request up to about 25 MB. Is there another setting I'm missing?
Thanks in advance for any guidance/help you can provide.
I followed these step it worked.
https://www.inflectra.com/support/knowledgebase/kb306.aspx
Modify the maxAllowedContentLength setting in the web.config
Edit the request filtering feature settings and the request limits using IIS manager
Manually edit the ApplicationHost.config file
I try to deploy ASP MVC 5 app in virtual directory (without creating new iis application)
I use IIS 7.5
I already put
<modules runAllManagedModulesForAllRequests="true"/>
<directoryBrowse enabled="true" />
in web.config file.
But when i go to app url with IE browser it shows me just directory listing like in screenshot below
Is there a way to deploy MVC 5 in virtual directory and make it work like usual MVC application?
You need to convert the virtual directory to application. Right click on it in the IIS management console and choose Convert To Application.... Also make sure that the associated application is configured to use Integrated Pipeline Mode.
I solved this problem earlier in my production environment by checking the directory pointer in IIS. Apparently when I unzipped the deployed site from one server to the next, the zip utility made an extra level, so IIS was pointing to /MyProject when the files were in /MyProject/MyProject. I had a little better clue though, you have Document Browsing enabled based on that screen shot, make sure not to do that in production. I set the site to log custom errors and got a 403.14 response, from there found a blog on my mistake. You need to setup the environment to find the specific module that's failing, I think something to do with trace routes, idk. I'm a software developer that always gets forced into doing devOps; was googling my own problem and thought I'd throw you a line. Without a specific error message, all I can tell you is IIS is not connecting to .NET; something is not configured correctly. Turn off directory browsing, google how to get good error logs back, and let us know the status code so we can help you: 403.14, 401, 500, 404? Also give us the module that's failing. If it's the last one on the handler list, guess what, IIS isn't connecting to the app, which I suspect is your case.
I'm using MVC 4 with IIS 7.5. I'm trying to handle 404, 500 and other codes with my own controller and view.
However, no matter what I try, IIS overrides my settings/code and injects it's own 404 (and so on) error pages. This happens locally on dev machine with IIS Express as well as production with IIS 7.5.
Here's a combination of all I've tried so far:
Used tag in web.config with redirect to my custom error view, no luck.
Provided custom error handling in Global.asax. It gets there (tried 404 and 500), it does call my custom controller and view, but at the end, IIS still wins and shows its page instead of my view.
By the way, I'm trying this will extensionless url as well as .html pages. How can I get IIS to leave it alone and allow MVC to take care of these errors.
I"m out of options at this point. Any advice would be appreciated.
You need to override how IIS handles the error status codes. This can be done by simply modifying the <system.webServer> section in your web.config.
<httpErrors existingResponse="PassThrough" />
Full information can be found on the IIS.NET site: http://www.iis.net/configreference/system.webserver/httperrors
I ham having problems serving a .appcache file from Azure.
When viewd in Chrome developer tools console, I get the following message
Application Cache Error event: Manifest fetch failed (404) http://mydomain.cloudapp.net/c.appcahe
Now I know the default vm of an Azure instance will not recognise the .appcache extension and mime type, so I added the following to my webrole web.config
<system.webServer>
<staticContent>
<mimeMap fileExtension=".appcache" mimeType="text/cache-manifest"/>
</staticContent>
</system.webServer>
yet I still get a 404 error when I try and browse c.appcache, and the corresponding 404 in the console.
If I run the the app in dev fabric, the resources within c.appcache get downloaded fine and the temp website created in IIS has the corresponding Mime types added in the iis config.
Can anyone help me with this issue.
Thanks
Brett
Thought I would provide an answer for this question in case others were having the same problem.
The problem is in 2 parts.
1. First part was the mime type, which my code above correctly fixed.
2. The second half of the problem was down to the packaging my deployment from VS2010 omitting the c.appcache file when it packaged everything up. So even though IIS now recognised the mime type, it still gives a 404 as the file isn't there.
This can be fixed by R-clicking on the c.appcache in VS and making the build action on the file "content".
Hope this helps.
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>