Iis – Disabling IIS 7.5 server error response for 5xx and 4xx HTTP status codes

custom-errorshttp-status-codeiis

Is there any way to prevent IIS from automatically overriding the output of a web app that is returning a status code in the 500 or 400 range?

Just as an example, in ColdFusion I can create the following page:

<cfheader statuscode="500" statustext="Error">
Sorry, an error occurred.

The behavior should be that I see a page that says "Sorry, an error occurred." and see in the headers that the status code is 500.

Instead, I see:

Server Error
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.

In lovely IIS styling.

I tried just deleting the 500 custom status page but that simply resulted in:

The page cannot be displayed because an internal server error has occurred.

Without any of the lovely styling.

Looks like this happens with any page that returns a code that is not in the 200 or 300 range.

Best Answer

This was answered in another question: IIS7 Hijacks My Coldfusion Error Page

Seems that the solution is changing the configuration so that IIS ignores the error and allows it to pass through, hence the setting

    <httpErrors existingResponse="PassThrough" />

So the solution is to change the behavior of IIS, which is fortunate, because requiring every existing web application server to change their behavior would be really stupid.

Update

Please see my updated answer in another similar question to find out why and how there is no workable answer to this problem.

Related Solutions

Nginx: error_page directive is silently ignored

I found this question on Stackoverflow that accomplishes what I was looking for.

I guess for whatever reason even though a return works inside of a server block, it does not respect any error_page directives. This may be a bug, or an intentional behavior I don't understand. The solution is to put the return inside of a location block:

server {
    listen 80;

    root /var/www/html;

    error_page 400 /400.html;
    location = /400.html {
        internal;
    }

    location / {
        return 400;
    }
}

HTTP/1.1 Status Codes 400 and 417, cannot choose which

If the parameters for a GET request are incorrect, the canonical thing to do is send back either a 404 (not found), or 200 (OK).

The RESTful way to use GET requests is to query a resource (get something). Therefore, if the required parameters don't correspond to an extant resource (because they are incomplete), you can accurately say the resource as queried in the URI is not found.

Practically, if you want to avoid things like browsers ignoring your 404 page and substituting their own (I am looking at IE 9 and 10), you may want to use 200. If you consider your application to be the resource, 200 is appropriate; you queried the application, and it returned a result (that happened to be an error, but not at the HTTP level). However, this use is not very RESTful.

Best Answer

Update

Related Solutions

Nginx: error_page directive is silently ignored

HTTP/1.1 Status Codes 400 and 417, cannot choose which

Related Topic