I have two ASP.NET projects in my solution, and run on different localhost ports when I start debugging. I have a generic handler in site A, which is called by site B:
String url = "http://localhost:1234/UrlOnSiteA.ashx";
WebClient client = New WebClient();
client.Credentials = CredentialCache.DefaultNetworkCredentials;
client.OpenRead(url);
The OpenRead call throws an exception with a 500 error, and I don't know why. The error message is:
System.Net.WebException: The remote server returned an error: (500) Internal Server Error.
Other info:
A breakpoint on the very first line of the handler code isn't hit.
The handler runs properly (and hits the breakpoint) when its URL is used in a browser.
Visual Studio 2008 Professional, running .NET 2.0 sites.
I suspect it's a configuration issue. Any ideas?
I'd diagnose this first by figuring out what's causing the exception. Look at the Response property of the WebException, and read the HTML returned. Any clues? (You may need to disable custom errors in your web.config to see the actual error response.)
Another approach to get the same response info would be to use Fiddler, and set the proxy of your WebClient call to the Fiddler proxy address. Then you can use fiddler to see the response HTML.
A slightly different approach would be to change the Exceptions settings in Visual Studio to break into the debugger whenever a WebException is thrown. You can do this from the Debug...Exceptions... dialog box.
Related
I have a couple Azure VMs behind a Basic Load Balancer with an HTTP URL Health Probe for the Backend Pool. To mark a server down, that URL returns Status Code 503 (Service Unavailable), but when I call that page from those VMs, the Status Code returned is 403. That still has the desired effect, I suppose, of marking the server down - but I dont understand why the code I set has changed.
This is from an ASP.NET web forms application on the VMs. I look at developer tools in the browser, and from my local machine or from a Dev server on our local network, that page returns Status Code 503, but calling that page from the VMs in Azure, the Status Code is 403.
Here's where I set the Status Code in that page:
Response.Clear()
Response.StatusCode = 503
Response.Flush()
I suppose I should mention that my local is a Windows 10 box, and the server VM is Windows Server 2016. Both are running IIS 10. The application is compiled with .NET Framework 4.6.
Here's the dev tools from my localhost:
Here's the dev tools from the server in azure:
Why the change? Anything I can do to stop this behavior?
So today I tried enabling Failed Request Tracing, but either something wasnt set up correctly, or the error was being handled elsewhere, and didnt result in any failed requests being logged.
Since I wasnt getting any failed requests logged, I opened up Process Monitor and could see that immediately after the call to my Health Probe page, I was getting a call to my custom HTTP Error page. That page must have been what was giving the 403 (dont know why, b/c that page works correctly for other HTTP Errors with a friendly error message and logging of the error to my custom error tracking solution).
I was going to change the Status Code to see if there was something special with the 503 that I was setting that was handled differently in IIS, but that got me thinking about how I was setting the status code...
In my research today, I saw this page https://www.leansentry.com/HowTo/AspNet-Response-Flush-Poor-Performance which cautions against using Response.Flush(). The code that I had implemented was in the Page_PreRender method, so there's not really a need to Flush there anyway.
I removed the Response.Flush and of course, my troubles went away.
The Health Probe page no longer triggers an Error from the Azure VM, and therefore, the status code that I get in my client browser is the 503 that I set in code.
So I guess this case is closed. I will need to figure out why the HTTP Error page was throwing a 403 instead of returning the friendly error message, but that should be easy enough...
I have a web api running on a remote server that I connect to over VPN in order to deploy updates.
I installed the Rewrite Module for IIS 7 and made a rule to rewrite http to https for all requests.
Suddenly I am getting this error when I attempt to acquire an authorization token (OAuth):
{
"error":"server_error",
"error_description":"Exception has been thrown by the target of an invocation."
}
And this message for any api endpoint:
I cannot for the life of me figure out what's going on. How can I get a more useful error message from asp.net or iis? I cannot do remote debugging and the server does not have visual studio installed.
I have undone all the modifications I made and its still broken.
This is usually a sign that IIS is having problems even starting the application. I'd remove everything from the web.config file and add each line in one by one until you get back to this error message. If it is an application error (i.e., something in your code) you would get a 500. Since you aren't getting a 500, it is a lower level than your application and the next lower level is IIS parsing your web.config file before serving requests.
I'm debugging two ASP.NET applications running on the same machine under different instances of Cassini and with "custom errors" off. One app is running on port 100 and wants to perform a GET request from the other app running on port 90. So it runs this code:
WebRequest request = WebRequest.Create(
"http://localhost:90/Controller/Action?Param1=foo&Param2=bar");
request.Timeout = 10000;
request.GetResponse();
and the last line throws a WebException with HTTP 400 code and null InnerException. If I copy the very same URL in clipboard, past it into IE running on the same machine - the request is queued to the app on port 90 and its /Controller/Action/ is invoked and even parameters are passed okay.
What could be the problem origin here and how do I solve it?
I think you should try without the params in the url.
WebRequest request = WebRequest.Create("localhost:90/Controller/Action");
request.Timeout = 10000;
request.GetResponse();
if it does work you need to add some user-agent headers to allow the use of params.
Also you should probably look at WebClient.
MSDN
personally I would also look at using IISExpress or IIS to develop this kind of solution.
Just an outsider's observation here, consider making this call to the second webmethod via an ajax call from the browser and aggregate the results clientside using javascript (jQuery).
I would try and use the overload of WebRequest.Create that takes a URI object, that way you can rule out a fat-fingered URL.
Two hours debugging - and it turned out that service at port 90 would redirect the request back to the service at port 100 but wouldn't provide a required parameter in the URL, so the handler in the service at port 100 would throw an exception and return the HTTP 400 which was then reported by the GetResponse(). The solution was to change the logic so that there's no redirect for this specific request because the redirect would make no sense for this specific request.
And the jury finds both Cassini and ASP.NET to be not guilty.
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.
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 PUB'.
There are tons of references for this error message on the Web, but I can't figure it out. The problem is that the application works fine when I run it locally or when deployed to other servers. There is just one server where I get this error during a post back from an Update panel (it is supposed to populate and open a popup panel). There is no Response.Write() anywhere in the code and the other suggestions do not apply, either. I think. The next thing I will try is install the remote debugger. In the meantime, can someone tell me how to check if server trace is enabled (IIS 6)?
Oddly enough, this was caused by a database exception. The application framework injected the stack trace into the HTML stream, but obviously in case of an Ajax call the error should not be reported in the HTML response.