Develop Reference

Error 520 on asp.net web app in production

Our asp.net web app is returning Error 520 on a page in production though no error in development.
This particular error skips our custom error page and present a different error page with Cloudflare.
As in this image
When you inspect the page, you see
"Error: Promised response from onMessage listener went out of scope"
in console
No error is logged by our logging tools, and we cannot tell why it's skipping our custom error page.
Any direction as to how to solve this?

Receiving different responses depending on client

I have two ASP.NET MVC web apps running on the same server. One of them is a web service that returns an error message in plain text if an exception occurs. However, right now, some clients that call the web service don't receive the error message; instead, they simply receive "Bad Request" in HTML.
The second web app (on the same server as the first) can call a URL handled by the first one and, right now, correctly receives the error message in plain text. However, I have tried calling that URL other ways, and all of them have resulted in receiving "Bad Request":
Pasting the URL into Chrome on my computer
Pasting the URL into IE on the server
Calling the URL from a web app on a different computer from the server
This error does not occur locally. When I run the 2 web apps on my computer, I receive the error message in plain text from both the second web app and from calling the local URL from Chrome.
I have narrowed down the offending line of code to the first line of the following ActionResult snippet:
Response.StatusCode = (int)HttpStatusCode.BadRequest;
return Content(errorMessage, ContentTypes.PlainText);
Removing the first line appears to fix the problem; however, that also eliminates the ability for me to use a descriptive status code. It appears to me that after the ActionResult is returned the response is being intercepted if either (a) the client is on a different computer or (b) the client is a web browser. So I guess I have a 2-part question:
Is there a reason why .NET or IIS would intercept and change a response depending on the client type or location?
Is there an easy way to view the response at any point between this code and when it's dispatched to the client?
Thanks!
Update: I changed the web app to use HttpResponseException. Now I am getting the following YSOD exception:
Processing of the HTTP request resulted in an exception. Please see
the HTTP response returned by the 'Response' property of this
exception for details.
Using MVC version 5, Visual Studio 2013. The code for the ActionResult looks like this:
MyImage image = new MyImage(parameters);
if (image.Errors.Any())
{
throw new HttpResponseException(new HttpResponseMessage(HttpStatusCode.BadRequest) { Content = new StringContent(image.Error) });
}
return File(image.AsJpeg(), ContentTypes.Jpeg);
Anyone have an idea how to bypass this unhelpful response?
Update 2: The issue turned out to be that the error message was being suppressed because of the Web.config setting system.webServer > httpErrors > errorMode which has a default value of "DetailedLocalOnly" and seems to be invoked in some cases for a reason I don't know (although this question may start to shed some light). Once I changed it to this, it worked as I expected:
<httpErrors errorMode="Detailed" />
I understand why they suppress error messages by default on remote machines, but this was a lot harder to track down than I would have thought. Anyway, I hope this is helpful to someone in the future.

I can't think of any reason why IIS would care what client was calling a service. My guess is that the client is sending a different request to the server than what you think it is sending. You can verify this by using a program called "Fiddler".
Also, I'd recommend following a pattern that returns a HttpResponseMessage like this when sending back information from a Web API call:
return new HttpResponseMessage(HttpStatusCode.BadRequest)
{
ReasonPhrase = message,
Content = new StringContent(string.Format("{0}", exception))
};

Getting error message from WebMethod while keeping Web.Config secure

I have a page that's doing jQuery Ajax calls to a WebMethod in one of my ASPX pages. In some cases, my WebMethod is throwing an exception with an error message. This error message is really important for the UI, because it tells what to say to the user, so he can fix his form.
This is working fine in development environnement. But, in my production Web.Config, I need to keep customErrors set to "On", so I wont show important information. Moreover, my IIS is overriding HTTP 500 errors too.
I tried the WebServices from ASMX, and it was working perfectly. IIS wasn't overriding my HTTP 500, and customErrors was not hiding the message sent by the WebService. But migrating all my ASPX's WebMethods to ASMX files is not possible for now.
I'm looking for a guideline. How my UI can gets my WebMethod's errors, while keeping my Web.Config safe for production?

You should never show a yellow screen of death to a user.
Instead, consider implementing a Response object, contaning a boolean Success, an ErrorMessage (string) and the actual result data if needed.
You can then use a JavaScript callback and check if the call succeded. If it did not, just alert() the error message.

update panel stops working in IE 8 when site is redirected via a proxy server

the site normally works fine in all popular browsers including firefox, chrome, safari and ie.
but doesn't work in ie 8 when it's redirected via a proxy server and it gives an error saying
"Message: 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'."
this only happens if (in ie 8) && (via a proxy server)
any idea??

Its because the UpdatePanel expects its Response formatted a specific way("|" delimited). If anything tampers with the format of the data in transit, it cannot parse the response.
Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it
Asynchronous postbacks go through the
same life cycles events as regular
pages (this is a question I get asked
often). Only at the render phase do
things get different. We capture the
rendering of only the UpdatePanels
that we care about and send it down to
the client using a special format. In
addition, we send out some other
pieces of information, such as the
page title, hidden form values, the
form action URL, and lists of scripts.

How can I debug problems related to (lack of) postback

I have created a custom wizard control that dynamically loads usercontrols as you progress though it. The wizard is behaving as expected in all environments (PC/MAC) and browsers I have tested however a client is reporting that she is unable to complete the wizard. What I know about the issue:
It always fails on the same wizard step for this user (not the first step)
When the user clicks on the 'next' button in the step, the controller reports that the request was not a postback request (ie. IsPostBack() == false) and displays the first page of the wizard
The client is using a Mac and is accessing the site using the latest version of Safari
If the client switches to Firefox, or even just switches the user agent in Safari to something other than Safari the problem goes away.
So the problem is that when the client reaches a certain step in the wizard and clicks 'next', instead of re-loading that step to initiate the save event, the controller is merely displaying the first step of the wizard.
The step that fails contains many different form controls including textboxes, dropdowns, checkboxes and a fileupload control. We thought that it might have something to do with invalid characters getting pasted in from Word or something similar but that seems strange seeing as the problem only appears to be happening in Safari.
No exceptions are thrown and the windows event log is not displaying any related errors/warnings.
What I am looking for is ways to diagnose this error. At the moment I've been unable to reproduce the behavior that the client is experiencing but after going on site and seeing it for myself I can verify that it is definitely a valid issue.
Update 26/10/2010:
We installed a proxy on the clients NIC in order to retrieve the requests and responses. Problem is that when running the proxy the client appears to not have to problem any more. Does this behavior make sense to anyone?
Update 27/10/2010:
After investigating the traffic on the clients machine we noticed that the response headers were including some entries related to a client side proxy and we confirmed that they are in fact running the squid proxy in their office. To rule out that it had anything to do with the problem we got them to turn if off and then try the wizard again. This time no problems were encountered! So the proxy seems to be interfering with the requests causing .NET to somehow record the POST request as a non-postback. The following lines were found in the response header of a failed request. Can anyone comment on how squid could cause the behavior we are experiencing and what we can do about it?
Via:1.0 squid-12 (squid/3.1.0.13), 1.0 ClientSiteProxy:3128 (squid/2.7.STABLE4)
X-Cache:MISS from squid-12, MISS from ClientSiteProxy
X-Cache-Lookup:MISS from ClientSiteProxy:3128

If I have to troubleshoot this, I would first take a fiddler trace (www.fiddlertool.com) on the client and see what the requests are up to. I am not sure if Fiddler works on Mac, but any HTTP Watch, Network Monitor tool should be good. The reason that I am not doubting the code is that it works very well on all the other browsers, so the code shouldn't be bad.
May be there is something in the code [like adding cookies, etc] that is messing with the specific Client's browser.
HTH,
Rahul

For Mac There's a HTTPScoop which lets you to debug http post data's....it is similar to fiddler

The problem is not solved as such but we ended up just adding an exception to the clients squid proxy to bypass our website. The problem seems proxy/IIS/Safari related but we haven't been able to track the problem down any further and the client is happy with this solution as long as the problem doesn't resurface somewhere else. I'll re-post if more information surfaces.