I have an issue which has arisen using Google Page Speed Online although I am worried that there may be a bigger picture to this. I ran my site through the online tool, see the results here: https://developers.google.com/pagespeed/#url=www.exclaimer.com&mobile=false. Notice that it claims a redirection as occurred to http://www.exclaimer.com/oops.aspx?aspxerrorpath=/default.aspx
Now the original URL I plugged in http://www.exclaimer.com and http://www.exclaimer.com/default.aspx both work find in my browser. I keep a log of any pages which aren't found and indeed /default.aspx is in there over a thousand times (only change has happened 24 hours ago). This wasn't me trying the Page Speed online tool 1000 times so I worry that this may be another Google service (or some other automated system) which is failing. There have been no complaints from visitors to the site unable to get access which leads me to believe that for ordinary users there are no problems, the issue only comes from automated bots or similar.
I guess my question is, does anyone know of a way I can isolate the source of the problem? I attempted to modify my 404 logging code to capture the page from which /default.aspx was being accessed but not had much luck here as Url Referrer only works under pretty specific conditions.
Update
I have modified my code to log the error details but nothing is being passed through for /default.aspx.
Exception error = Server.GetLastError();
string errorTitle = "";
string errorDetails = "";
if (error != null)
{
errorTitle = error.InnerException.Message;
errorDetails = error.ToString();
}
Server.ClearError();
... send to database
If the page is redirecting to the error page then there must be an error occuring when that page is being accessed so what you want to do is try to capture what that error is to find what part of your code is causing you problems.
My guess would be that the problem is that you are assuming a certain http header to be sent from the client and you are not doing a null check on it. When you get a request from a robot which may not be sending accepted languages or something then you get a crash.
In your global error handler you shouldlog whatever exception is getting thrown either in a database or just by dumping it straight to a file. This is useful information at all times and should be captured in the event of any other errors on the site and tracking down their cause.
Related
I am at my wits end with the following problem:
My site www.sebastianthalhammer.com is available under that URL without any problems.
However Google Search Console as well as other external third party test tools return a 404 error.
Status report from Uptrends
It is just the main page that's affected. All the other subpages and blog content isn't affected.
I have been in contact with the server stuff but it seems alright to them. As mentioned. The site can be reached. The site runs on wordpress - latest version.
I have no real clue where to start as this error seems to be quite a tricky one. Does anyone here might have an idea what's going on?
Sebastian
The 4xx class of status code is intended for cases in which the
client seems to have erred. Except when responding to a HEAD
request, the server SHOULD include a representation containing an
explanation of the error situation, and whether it is a temporary or
permanent condition. These status codes are applicable to any
request method. User agents SHOULD display any included
representation to the user.
This leaves me with two possible explanations:
Explanation 1: it's a server error.
the server wrongly returns a 404 status code
the browser thinks the response body contains details about the error and displays it - for the end user this is the actual page
Explanation 2: it's done on purpose to defeat crawlers and page watchers.
the server returns 404 on purpose - non-browser user agents won't process the result as they interpret it as error
browsers are unaffected, the end user doesn't care as long as the page is being displayed
The second one would indeed be kind of clever if you don't want your page to be indexed.
Thanks to your feedback I could think about the problem in a different way.
Ultimately at the unholy depths of a certain plugin I could dig out a setting that caused the error.
It was a redirection plugin that (for whatever reason) sent out a 404 signal when the URL was requested.
I don't know what the purpose would be for something. All I know is that the setting was on default for quite a while now and that caused the weird situation.
thanks guys for getting me on the right track.
Sebastian
Whats difference between return new HttpStatusCodeResult(500) and cause a real error in the action (like division by zero)?
I'm asking because my customErrors works fine when a error like division by zero ocurred, but if i return new HttpStatusCodeResult(500) the customError dont show my page
HttpStatusCodeResult is for notifying the browser of the result of an action, using an actual HTTP status code. For example, if the browser tries to load an image that is no longer available, you could send a 404. If the user is attempting to access a resource that requires authentication, you could return a 401.
Errors caused by your code often don't need to inform the browser of an error, but instead need to inform the user, using an error page with a message. This error page though, would (most likely) be sent to the browser with an HTTP status code of 200.
tldr; these are two different types of errors with different meanings, meant for different recipients.
I have read a lot about this error message.
I've learned that the most common causes for this error are
when the response is modifed by calls to Response.Write(), response filters, HttpModules
server trace is enabled.
There are some suggestions like to use a web debugger (ie. Fiddler) to get the server's response, set the EnableEventValidation="false" to the page that this error came up, set the cookie timeout and the likes.
My question, is there any other way to avoid this like doing something on the settings of the browser?
What is the point in hiding the error altering the browser settings? Your end user would still get that error as you wont be able to change their browser settings.
The key to the answer is in your question itself. You find out what is causing the error and then rectify it.
Useful read: Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it
Here's an interesting one for you.
I've got my custom 500.aspx setup which is called when a 500 error occurs in my application. The 500.aspx also sends me an email with the error details.
I've noticed one small problem.
If you attempt an xss attack on the 500.aspx itself, the 500 page is not called.
This is obviously some sort of logic issue.
In fact, microsoft themselves suffer from the same issue.
See it in action here
http://www.microsoft.com/500.aspx?aspxerrorpath=%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
How can I prevent this?
Ed
If you attempt an xss attack on any page, the custom error page will not be called (here's another random page on Microsoft.com with xss in the querystring).
The behavior appears to be intentional to stop the attack dead in its tracks. Even the error message indicates this behavior:
Request Validation has detected a
potentially dangerous client input
value, and processing of the request
has been aborted.
The only workaround appears to be to disable validation or to capture and handle the error in your global on Application_Error.
It appears that once you define a page to handle specific(or non specific?) errors, it is no longer available directly via its url, sorta like the Web.Config cant be called via the browser.
I would set up a 500Test.aspx which throws an exception causing a 500 error (and thus fires the 500.aspx)
That might work.
You might want to think about handling your errors in the Application_Error event in Global.asax.cs instead of the 500.aspx page. You could put the email code there, then redirect the user to an error page after you've done your error handling (this is how we do it where I work).
I'm finding this problem every now and then in my production website, and it has me absolutely stumped...
My app works perfectly in both dev and production, but every now and then, I get an e-mail from my global error handling with this:
MESSAGE: This is an invalid webresource request.
URL: /WebResource.axd
(which means that for some reason webresource.axd was requested without specifying any GET parameters)
I'm not doing anything with webresource.axd myself, I don't get any of my resources through it, it's only used automatically by .Net to serve it's typical JS for validators, etc.
Any idea why this might be getting requested without parameters?
Has anyone encountered this?
That definitely is a bot not doing very good job of crawling your web site. It processes your web form and locates reference to WebResource.axd, for example:
<script src="/site/WebResource.axd?d=MtIW_TBRtZCvAXDMJGwg4g2&t=633772897740666651" type="text/javascript"></script>
The bot expects static JavaScript files only and tries to download it by requesting WebResource.axd without parameters. The result is an exception thrown by System.Web.Handlers.AssemblyResourceLoader class and intercepted by Application_Error in Global.asax.
I believe this exception is harmless - the client will receive 404 error. You can safely ignore it.
We also have all of our errors emailed to us, and we occasionally get those too. They never seem to have a referrer, and the user agent is usually a little wacky. We write them off as bots.
I just checked a couple of the offending client IP's against Arin, and one them belonged to a web-spidering-type organization, so there's a little more evidence for the bot theory.
I would also log the useragent that made the request to WebResource.axd. It wouldn't surprise me if it was a bot crawling your site.
This discussion...
http://www.telerik.com/community/forums/aspnet/spell/this-is-an-invalid-webresource-request.aspx
... and this linked MSDN article...
http://msdn.microsoft.com/en-us/magazine/cc163708.aspx
... might shed a little light (though not much).