Hey Rick,
I have an Angular 1.x front end that makes AJAX calls that return JSON.
If an anticipated issue is trapped (not an "error"), the JSON string contains the applicable message which is, in turn, assigned to a $scope variable and displayed.
I'm using the .success() and .error() functions in the $http.get(url).
I set Response.Status = "404 Not Found" on the server to trigger the .error() function in the Javascript where I make the variable assignment to display the message.
This works fine on localhost but on the live server, an Error 404 HTML Page is being returned instead of the JSON (I'm presuming this is a standard Web Connect page).
What needs to be done to prevent this HTML page from being returned?
Or am I going about this the wrong way altogether?
Thanks,
Carl
Sounds like IIS is serving its error pages? You may have IIS configured to return custom error pages. Make sure that's not the case. Haven't looked recently how that's configured but there should be an option that doesn't have IIS do anything in response to errors other than for static content.
+++ Rick ---
Thanks Rick,
My site is on shared hosting and I don't know about any IIS settings.
I did find an arcticle that indicated a list of error statuses that cannot be overrridden (at least on Server 2008), one of which is "501 Not Implemented".
So I replaced the 404 status with 501 in my server code.
Response.Status = "501 Not Implemented"
Response.ContentType = "application/json"
Response.Write(lcResponse) && JSON string containing error message
Now I get an HTML Error page with a 501 error description. Here's the complete response...
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>501 - Header values specify a method that is not implemented.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
h1{font-size:2.4em;margin:0;color:#FFF;}
h2{font-size:1.7em;margin:0;color:#CC0000;}
h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
#header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
background-color:#555555;}
#content{margin:0 0 0 2%;position:relative;}
.content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;position:relative;}
-->
</style>
</head>
<body>
<div id="header"><h1>Server Error</h1></div>
<div id="content">
<div class="content-container"><fieldset>
<h2>501 - Header values specify a method that is not implemented.</h2>
<h3>The page you are looking for cannot be displayed because a header value in the request does not match certain configuration settings on the Web server. For example, a request header might specify a POST to a static file that cannot be posted to, or specify a Transfer-Encoding value that cannot make use of compression.</h3>
</fieldset></div>
</div>
</body>
</html>
So I need to make sure I understand something...
Am I correct in assuming that I should be able to set the Response.Status to whatever I choose without affecting the response itself? This assumption seemed OK during development on my machine but on a production server, the way I'm handling anticipated issues is completely shot.
Thanks,
Carl
Yes these are IIS's built in error pages and they will override ASP.NET error results if not triggered.
Now I'm pretty sure that Web Connection uses Response.TrySkipIisCustomErrors so I'm not sure why that's not happening for you, unless you are using the ISAPI module, which doesn't have this override. I have to double check, but pretty sure it's in the module because I always return error responses and IIS default to returning custom errors.
There's more info in an old blog post of mine:
- (IIS 7 Error Pages taking over 500 Errors)[https://weblog.west-wind.com/posts/2009/Apr/29/IIS-7-Error-Pages-taking-over-500-Errors]
+++ Rick ---
Thanks, Rick.
Your blog post was extremely helpful and I think it explains the problem.
I wrote a little method to test what you describe. When I call this method, the response is consistently overridden for 4xx and 5xx status codes though not all responses have full HTML markup.
Now I'm pretty sure that Web Connection uses Response.TrySkipIisCustomErrors so I'm not sure why that's not happening for you, unless you are using the ISAPI module, which doesn't have this override.
On my dev machine, I'm using the .Net Handler but the live server uses the ISAPI Module (host couldn't get .Net Handler working).
Do you think that switching from the ISAPI Module to the .Net Handler will solve the problem? If not, I've got a bunch of code to revise.
Thanks,
Carl
