I am getting this situation over and over again where any sort of server error causes an ajax page not to load. This seems to occur when a user requests a page from the server running iis and the connection times out or something causes it to be lost. If you are looking at the ajax page the code will just says that it's still executing even though it's not any longer. If you try and go to another page on the same website you can't load it. The only way to fix it is to close the browser and start again.
Has anyone else had this issue and what have you don't to resolve it?
[Edit]
The error occurs when the web XHR request is aborted.
Related
An asmx service we're hosting under IIS decided to attach below message at the top of xml response body rendering the xml invalid. The guid is unique in each response.
Your request could not be processed. Please press the back button on
your browser and try again. If the problem persists, please contact
technical support. Information below is for technical support:
Support Code: 7d6cbea0-9491-4cb0-9ca0-32f0a8b41bc4
I've limited access to the source; it does not appear like this is coming from the application code itself. Googling brings several hits current or cached having exactly the same behavior (variation of "could not processed" or "could not be processed" in different cases):
https://www.histiocure.org/jTlSn/about.aspx
https://webcache.googleusercontent.com/search?q=cache:8gRsTgrCarQJ:https://retirement.insperity.com/education.aspx+&cd=4&hl=en&ct=clnk&gl=us
https://www.perfectprovisions.org/index.aspx
Yet, I don't get any hit from technical sites like stackoverflow or MSDN. This is very puzzling; has anyone seen this behavior? Is it IIS doing this? What causes this?
BTW, the issue itself was resolved when AppPool was restarting but I'm worried that this can happen again anytime unless we get to the bottom of this.
I'm testing an ASP.NET application using JMeter. Occasionally there will be an exception caused somewhere, and the page will redirect to an screen displaying the exception message.
How can I get JMeter to recognise this as a error? At the moment its showing as a green indicator, since I'm successfully getting a response.
I want to be able to recognise this as an error so it shows later on in the reporting/aggregation listeners.
Thanks.
You need to add an assertion as a child to the request which can check the contents of the reply and raise an error if needed.
http://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion
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
I have a rather complex legacy ASP.Net application that is under continuous development, and for one client it has started erroring recently.
The application uses ASP.Net 3.5 and C# on the server side, backed by SQL Server 2005 and IIS6.
The application also utilises the Microsoft ASP.net AJAX libraries and DevExpress components.
We have a fairly comprehensive logging platform in place, via a Page_Error handler in a custom page base, which logs all unhandled exceptions and displays a nice error page.
The problem is, one client has recently started getting errors which we cannot trace - nothing is logged, despite the nice error page being displayed. No exceptions are caught and handled by the Page_Error handler, which is the method which redirects users to the error page - and no redirection happens without the error being handled.
I have added some client side Javascript to the ASP.Net Ajax PageScriptManager EndRequestHandler Javascript handler which logs clientside errors to a wide open ashx logging script.
The only errors the client side catches are as follows:
Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 0
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.
Details: Error parsing near '
<!DOCTYPE html P'.
These errors have no corresponding server side error.
Unfortunately, there is no scope to set up unit tests for this project, its too large and I wouldn't know where to begin for the client-server interaction part.
My question is, can anyone recommend a method of seeing what is erroring, why it is erroring and why this isn't being caught by the Page_Error handler?
You could try using ELMAH to catch exceptions that aren't handled inside your application.
As it turned out, there isnt a way to track these down - the issue was wider in scope and involved a clients firewall preventing AJAX communications randomly, or modifying the resulting pass back.
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).