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
Related
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.
Here's the situation: -
I have
<customErrors mode="On" defaultRedirect="error.html" />
in my web.config.
I also have custom error handling code in Application_Error (in global.asax.cs) that checks for certain well known exception types and redirects to custom error pages for each. If the exception is not a well known type then I simple return from Application_Error without calling Server.ClearError() so the default custom handling should take care of showing the page error.html.
But whenever my app throws up an unhandled (and not well known) exception I end up at the default Asp.Net error page - you know the one I mean, the yellow screen of death...
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.
Details: 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" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "RemoteOnly". To enable the details to be viewable on remote machines, please set "mode" to "Off".
I have checked the obvious stuff (like double checking that I am not throwing another error in Application_Error and I am not accidently' calling ClearError. It is definitely something fishy with this one web app (I made a little test web app and the custom error handling worked as expected) - that should rule out oddities in my machine.config file.
I am going to keep on scratching my head and trying things but in the meantime I thought I would put the question out here to see if anyone had any bright ideas.
PS. I am working on Windows 7 Business (IIS 7.5) but the same behavior is observed on Win server 2003 (IIS6).
Thanks Joe and Click for having a look but this problem is all my fault!
One crucial bit of information that I omitted from the description is that my web page flushes the response before the request is finished (see * below if you want to know why I do this nastiness).
It seems that once some content has been sent to the client, the customError handling no longer works. I can't say that this is a failing of the custom error handling because it would probably take some dark voodoo to tell a browser to redirect to once it had started rendering content!
Having said that I was hopeful that adding redirectMode="ResponseRewrite" to the customError node would help (maybe get the error page below the content I have already sent to the browser?) but that fails too. Nevermind.
A quick google yields this http://forums.iis.net/p/993221/1313916.aspx - and a chap on there has a work around that I will try. The technique suggested in http://forums.iis.net/p/993221/1399583.aspx#1399583 works. It is far from ideal (we have to read the web config) but it works.
(*) why am I flushing the response before the request is finished? Some of our pages return large reports which can take several seconds to generate. We send a "PLease wait + spinny gif" message to the clients at the start of these requests and flush that so that the browser renders the message + icon whilst it waits for the rest of the response. I think I shall investigate a less "hacky" way of achieving this.
I’ve had a bit of feedback from some threat and vulnerability folks relating to websites returning HTTP 500 response codes. Essentially the advice is that all possible measures must be taken to avoid the server throwing a 500 (i.e. extensive form input validation) which is fine.
However, the advice also suggested that attempts to compromise security by means such as inserting a tag into a random query string causing ASP.NET request validation to fire or manipulating viewstate also should not return an HTTP 500. Obviously the native framework behaviour is to interpret the request and possibly throw to a custom error page but even this will return a 500 response code.
So I’m after some thoughts on how to approach this. Is there any way to configure the app at either the .NET level or IIS level to return an HTTP 200 when a 500 is raised? Or does this become a coding exercise at global.asax level in one of the application events? Are there other consequences to consider?
BTW, the rationale from the security side is that apps which return HTTP 500 may be viewed as “low hanging fruit” by bots randomly scanning for vulnerabilities and prompt further malicious activity. attempts I’m personally not convinced that changing response codes offers any real security gains but am happy to hapy to take the advice of the pros.
To answer your question: global.asax is the correct place, in particular, the Application_Error event handler. You should be able to do something like
Response.StatusCode = 200
Response.StatusDescription = "OK"
there.
PS: Don't do it. :-) To me, this sounds like yet another security-by-obscurity-by-violating-standards approach. I really don't think the (possibly marginal) security increase is worth breaking correct HTTP behavior (think about Google indexing your error pages, etc.).
Why? Sending back a 500 code without any other information does not give an attacker much information.
Provided you don't throw stack trace, state dumps etc, back to the client then you're fine. And I doubt very much you want to do that.
Seriously, just create a "500" page (picture of a whale optional) and return that with your status 500 - it gives nothing away.
Sending a 200 status when the page was NOT generated successfully is plain wrong and may cause bad things to happen - such as bots thinking it is a genuine page. You don't want your "500 error" page showing up on Google because you sent back a 200 status instead.
You can set custom error pages in config - and you could re-set the response status in your custom error page
<customErrors mode="On" defaultRedirect="~/DefaultErrorPage.htm" >
<error statusCode="500" redirect="~/CustomError.aspx"/>
</customErrors>
Serious warning...!
Make sure there aren't any errors EVER in your custom error page. Usually, you would use a html page, not an aspx page - but if you want to change the response headers you may need to use the aspx page. Don't do anything else on there except change the headers (i.e. don't display any data from a database or try to run any logic) and error on your custom error page will cause a "maximum number of redirects" error.
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).
Has anyone run into this error message before when using a timer on an ASP.NET page to update a DataGrid every x seconds?
Searching google yielded this blog entry and many more but nothing that seems to apply to me yet.
The full text of the error message below:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Many issues can cause that error. It's usually a Response.Write call, but anything that modifies the response can cause it.
We probably won't be able to help you unless you post some pertinent code-behind.
The RoleProvider sets a cookie to cache role information in a cookie. When the cookie resets during an asynch post back from AJAX, you will get this error. The solution is to either set the cookieTimeout in the roleManager section of your web.config to a very large number of minutes, or set the cacheRolesInCookie=false.
This was a known bug in AJAX 1.0 Extensions. I'm not sure if it was fixed in future releases, and I should have mentioned that I was using AJAX 1.0 extensions in VS2008 targeting the 2.0 framework.
Happy programming!
Regarding the formatting of your post: If you use the quote-button instead of code-button, people do not have to scroll to see the complete error message.