I have a website project, that is working fine. However every once a while certain ajax pages (that make calls to a webservice) throw a "the server method xxx failed". I have ELMAH installed, however do not see any stacktrace or anything. The worst is that I can not reproduce the error locally. I just get an email notification from ELMAH. Does anybody know how I can fix this issue?
Edit: After 1 year I am still having the same issue.
It's too insufficient description. My assumptions:
Did you add EnablePageMethods
="true" to your ScriptManager control?
If yes, did the control (if it is; e.g. button) which call the web service method perform an anync postback instead of full one?
Does the signature of server method
and a call from the client-side
match?
Are you using URL rewriting?
I had the same issue and found my application firewall was blocking the content-type 'application/json'. Check if you have anything running on the web server that could be blocking the page method.
I happened the same with ASP.NET, remove the property runat="server" and run success
Related
I'm in the process of migrating a series of classic ASP web pages from a Windows 2000 server to a Windows 2008 R2 server. One of the pages uses CPSHOST.DLL (in the Scripts folder) to upload a file to the server.
The page in question uses a POST method on the form, but consistently returns a "Method Not Allowed" response when the page runs. I have changed the method from lowercase to uppercase, and I have configured the ISAPI and CGI Restrictions to allow the cpshost.dll to run.
The page in question prompts the userid for a file format type (3 possible options are available), and a file name. The form header is as follows:
<form enctype="multipart/form-data" method="POST" action="http://dcnb/scripts/cpshost.dll?PUBLISH?http://dcnb/scripts/dcn_cnam_repost.asp?user_id=jsommer&telco_code=GRGS" id=image_upload name=image_upload >
I tried changing the follwup .asp routine, in case it was throwing the error, but it made no difference (i.e., I changed the code to call a different web page than the repost.asp page, but to no avail.
The detailed error informaiton tells me the following:
Module: StaticFileModule, Notification: ExecuteRequestHandler, Handler: StaticFile, and Errorcode: 0x800700001.
The Requested URL is:
http://dcnb/scripts/cpshost.dll?PUBLISH?http://dcnb/scripts/dcn_cnam_repost.asp?user_id=jsommer&telco_code=GRGS
The physical path is listed as c:\inetpub\wwwroot\dcn\scripts\cpshost.dll, which is correct. The Logon Method and Logon User are both Anonymous.
Any help with this would be greatly appreciated. I have looked around for pure ASP solutions for uploading files (to eliminate the use of cpshost.dll), but have yet to find one that works in the IIS 7 environment. If anyone has any suggestions there, I'm all ears.
Thanks in advance for any help that you can provide. I appreciate it!
Can you try running Process Monitor when you request the page. Please confirm if the process is able access to cpshost.dll. If everything looks good, you can try running Failed Request Tracing to get some good information on what stage the request fails.
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.
When setting up asp.net error handlers for things like 404 errors, it is more 'efficient' to do this in IIS, or handle it in the Global.asax Application_Error event? I know the latter will be called, and I want to log this information in a database, but should I then just return without any redirect and let IIS do the redirect, or would it be better to do a response.redirect inside application_error once we've logged it?
Handing in IIS is more efficient but in glabal.asax allows you to log it or react to it.
Remember the decision is not commonly yours but based on the mime setup. So if a resource has been set to be hanled as a static content, you will not receive it in the ASP.NET.
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.