So it looks like we're running into a weird issue where we're seeing 404 errors on pages that exist. We have some web services and regular MVC 3.0 pages that get hit that will normally return 200 as expected but occasionally they'll return a 404 error.
We haven't really be able to track it down in weblogs and nothing exciting in the eventviewer. Any know where else I should take a look to try and track down this issue.
EDIT:
We found out what the issue was. We ended up doing some error tracing within IIS and found out that the sub status was 13 which means the file that was being uploaded was too large for IIS to handle with our current configs. Ended up being a bug in our code.
Actions to investigate :
cache prior the web client
IIS 7.0 configuration (notably, expires options)
look at the code in master pages
Related
What scenarios cause IIS to generate a 302 besides response.redirect? I'm working on an legacy ASP.NET app and it's generating 302s in IIS. The thing is, the code doesn't make any response.redirect calls. I don't know how to debug this thing. Could losing session generate a 302? I'm totally lost.
It can happen if you return a CSS file in ASP.NET over http when it should be over https, ive seen that happen in the past. Also if any web services tied into that application that are getting hit or making passes that fail, that could cause it too. Just shooting from my hip and trying to recall the last time I seen those issue's arise.
Check at the IIS level, not ASP.NET level.
Check the IIS management console. Possible options are:
"URL rewrite module"
"HTTP redirect" (under the website settings, for IIS7)
I've set up a new Windows 2012 R2 server running IIS 8.5.
We noticed that when an error occurs (eg the ASP.NET State Service was not running) that instead of outputting a 500 status code error screen, the request actually returns a totally blank page (only headers - with no content). We obviously need to see the errors and serving 200 OK for an error could be very problematic for indexers like Google etc or any wesite monitoring tools (which would not notify us that the site had gone offline).
On our other servers (IIS 7) we see the "yellow error screen" with a message like "could not connect to state server" (or similar).
What could possibly be wrong here? Is there some setting to globablly disable all errors (but this would be stupid if it also serves the 200 status code) or could something else be getting in the way?
The only other thing which could be interfering is we've got ISAPI_Rewrite installed on the server (but this doesn't usually cause this problem).
Thanks!
Had a similar issue on Windows 8.
In settings search for "Turn Windows features on or off".
Check that the following features are enabled
"/Internet Information Services/World Wide Web Services/Common HTTP Features/HTTP Errors".
"/Internet Information Services/World Wide Web Services/Common HTTP Features/Static Content".
You need to ensure Server Side Debugging is not enabled in the ASP module.
Classic ASP server 500 errors are returned as 200's. An attempt is made at opening the Server Side Debug Application, that then can't be found and IIS subsequently returns a 200 response and a blank page.
Make sure that you are not calling Server.ClearError() in Application_Error of Global.asax.cs that ended up being my problem.
Ripping out all Global.asax code helped me to find the cause of the error.
After that, the IIS started to return the error page as expected. Then, after the fix is applied, I returned the Global.asax code back.
Maybe this case helps you.
I had a similar issue when requesting the Default.aspx (set as page default in directory). The Server returned status 200, but the Content was blank.
In this case it worked to switch the Application pool's managed pipeline mode from integrated to classic.
Make sure you have enabled HTTP Activation
I want to make a custom 404 page for my site but I want to log all the normal information into my IIS 7.5 logs like the default 404 deals with so my Statics program can tell me things like what page got the 404 error, what was the referring URL to that broken page, and more. Do I have to do anything special on my 404 page to do this or has ASP evolved enough to automatically do logging for me if I return a 404 status code?
How you handle the errors determines how the errors will show up in the logs/responses. If you simply use custom error pages, it will show up no different in the log than if you had used the OOTB pages. If, however, you are writing an ASP.NET application, and handle/bury the exception, nothing will show up in the logs.
If you are writing a .NET application, this blog post provides a pretty good overview on how to properly handle errors for SEO.
ASP.NET Custom Error pages can be implemented in many different ways. The "worst" way are those that return a 301 redirection to "NotFound.aspx" (or similar), which will, of course, return a 200 status code. Unfortunately the IIS Manager actually lets you specify this method. If you're finding your 404s and 500s aren't being logged then check out this setting first.
Error pages, regardless of their implementation, must not issue any redirection and must set the status code to 404, that way IIS's logger will log it accordingly (IIS inspects the headers of all outgoing responses and uses that to populate the log).
We are in the process of migrating an ASP Classic/ASP.NET application from IIS 6 to IIS 7.5. Most things run just fine in classic mode but we are having alot of problems with how errors are handled by IIS 7.5. We do our error reporting using a classic ASP page where we capture the error information here then redirect to a page to display the error. Based on our testing both Server.GetLastError and Request.ServerVariables("SCRIPT_NAME") when accessed from the logging page do not return the error details and source. Are there other ways we should retrieve the error information on IIS 7.5 or perform the logging?
In case this helps, using freb we have noticed that IIS appears to generate a completely new request then begins executing our error capturing.
Thanks in advance.
#smaclell: See http://dylanbeattie.blogspot.com/2008/12/fun-with-servergetlasterror-in-classic.html for a potential solution for you.
Here's the relevant paragraph from the article:
There was a very similar known bug in Vista which was supposedly fixed
in SP1, but it looks like the same fix isn't part of Windows 2008
Server yet. There is a workaround, though - if you set the site's
default error property (under IIS settings -> Error Pages -> Edit
Feature Settings...) to the custom page, IIS will invoke
this page whenever an error is not handled by an explicitly configured
status-code handler (so your 404, etc. handlers will still work) - but
for some reason, handling the error this way means
Server.GetLastError() still works properly.
A vulnerability scanning service regularly tests our site for PCI scan compliance. It has just started trying to access URLs with abnormal formatting, such as:
http://www.mydomain.com/ShoppingCart.aspx//ErrorPage.aspx%3fid%3d2?
We have a Custom Error Page set which works for everything except this. Is there any way to force IIS to display it for this type of URL?
The Error: Runtime Error - An application error occurred on the server....
We're using:
ASP.NET 2.0 (Framework 3.5)
IIS 7.0 (Windows Server Web 2008)
I've tried to debug this, but I can't reproduce this on IIS 6.0.
There might be a more simple solution, but if you're on IIS7 you can use URL Rewrite to match those type of URLs and map them back to your error page.
The %3f part isn't being parsed by IIS 7 and so it can't find the page. If you look in your site logs you'll probably see some 404's.
You'll need to configure IIS 7 to point to your errorpage.aspx file as it's default 404 page.