I have an ASP.Net single-file web service (a .ashx
file containing an IHttpHandler
implementation) which needs to be able to return errors as responses with 500 Internal Server Error status codes. This is a relatively straightforward thing to do in PHP:
header("HTTP/1.1 500 Internal Server Error");
header("Content-Type: text/plain");
echo "Unable to connect to database on $dbHost";
The ASP.Net (C#) equivalent should be:
Context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
Context.Response.ContentType = "text/plain";
Context.Response.Write("Unable to connect to database on " + dbHost);
Of course, this doesn't work as expected; instead, IIS intercepts the 500 status code, trashes whatever I've written to the Response
object, and sends either debug info or a custom error page, depending on how the app is configured.
My question - how can I suppress this IIS behaviour and send error information directly from my IHttpHandler
implementation?
This app is a port from PHP; the client-side is already written, so I'm essentially stuck with this spec. Sending errors with a 200 status code sadly doesn't fit the mould.
Ideally, I need to control the behaviour programmatically, because this is part of an SDK we want to distribute without any "edit this file" and "change this IIS setting" supplementary instructions.
Thanks!
Edit: Sorted. Context.Response.TrySkipIisCustomErrors = true
was the ticket. Wow.
Context.Response.TrySkipIisCustomErrors = true
I have used the following in the past and been able to throw a 503 error with a custom message using the code shown below in the Page_Load method. I use this page behind a load balancer as the ping page for the load balancer to know if a server is in service or not.
Hope this helps.
You may wish to set a customErrors page (configurable via the web.config). You can store your content across requests in Session (or via an alternative mechanism) then have asp.net configured to display the custom error page which in-turn displays your custom output.
A word of caution, though: If the 500 is being caused because of a fundamental problem with the application (i.e. StackOverflowException) and you try to display a page that depends on asp.net (i.e. MyCustomErrors.aspx), you may end up in a loop.
For more information, check out this page.