Today I got burned for the second time on this issue. And you know what our former Commander in Chief said about that: "Fool me once, shame on you. Fool me twice - uhh - won't get fooled again."
So in the interest of not getting fooled again. Here's the deal, all laid out in plain English for the future me to read the next time I have this problem, well, in the future.
I have a lovely little RESTful web service (ASP.NET MVC) that has some (IMHO) elegant exception handling built in. The controller action is wrapped in a nice big try-catch and when an exception is thrown the catch block passes the exception to a class that logs the failure and then creates a "Fault" message for the caller (basically an XML representation of the exception details). The response status code is set to 400 - Bad Request and the response body is set to the aforementioned XML "fault".
This code all works fine, that is, until it doesn't. When hitting the service locally everything is fine and the correct XML "fault" message gets returned in the response body, but from a remote client the response body is simply the 11-byte string "Bad Request". Pretty baffling behavior, until you figure out what's going on and understand the rationale behind it. Turns out that this behavior is by design and built into IIS.
At first blush this looks Just like
[N.B. I know, I've broken one of the cardinal rules - "Never anthropomorphize computing equipment" - but I think it's pretty innocent in this case. It's a web server after all. It's not like it's going to take over our nuclear power plants and enslave humanity or anything.]
Anyway, it turns out there's now an httpErrors element in web.config and applicationHost.config that supersedes what's in customErrors. So if you want to display the real response body on anything that has a response code of 400 or greater you now have to set this to allow detailed error messages to be displayed to remote clients (either directly in the file, or via IIS Admin).
(As a side note - I believe this is new to IIS 7.0, I haven't found any historical info on this, but I'm pretty sure that prior to IIS 7.0 things didn't work this way. Either that or I'm getting a little bit senile in my old age. Anyone know which it is?)
Why would you want to override this behavior and make your site vulnerable to terrorists? Remember, you're either against us or with us! Well in my case I was doing integration testing with a new partner deployment on QA server and needed the detailed info troubleshooting. Actually, I can think of several scenarios where you don't want this behavior, but I don't fault MS for making it the default. In fact I definitely think they made the right choice. I just wish someone over there would've picked up the phone and called me. Come on guys, one quick call to let me know about this.
Or if you just want the guts...
In web.config, comment out customErrors in system.web like so:
<!-- customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
<error statusCode="403" redirect="NoAccess.htm" />
<error statusCode="404" redirect="FileNotFound.htm" />
</customErrors -->
and then add to system.webServer the following:
<httpErrors errorMode="Detailed"/>
If anybody is thinking to themselves "Duh. It's always worked this way." Please let me know. I'll accept this assertion with minimal evidence, I just really don't remember ever having this problem prior to IIS 7.
♦Add to del.icio.us ♦DiggIt! ♦Reddit ♦Stumble This ♦Add to Google Bookmarks ♦Add to Yahoo MyWeb ♦Add to Technorati Faves ♦Slashdot it
