Error messages returned from Web API method are omitted in non-dev environment

Question

I have a Web API controller POST method that behaves fine locally and on the testing server. If everything goes well it returns:

new HttpResponseMessage( HttpStatusCode.Created )

If something goes wrong, it returns:

new HttpResponseMessage<IEnumerable<string>>( usefulMessages, HttpStatusCode.BadRequest );

The problem is that when I make a request to the testing server that results in an error, I get the bad request code back but I never see the messages. If I make the exact same request to my local machine, I do see the messages. The following outputs are from my own tool:

Sending a request to my local machine I get:

Status code: 400 (BadRequest)
Response data: ["Error message one", "Error message two"]

Sending a request to the testing server I get:

Status code: 400 (BadRequest)
Response data: Bad Request

The code that is running is exactly the same. The database is the same. Everything is the same except for the server servicing the request. I even have code to email myself the error messages so I know that the server is producing the correct error messages and behaving correctly. Could this be an IIS thing (like the equivalent of customErrors = RemoteOnly for Web API)? Not only are the error messages omitted from the response data, something invents the phrase "Bad Request" to put in there instead.

Any ideas? Thanks.

Answer 1

Take a look at this MSDN post on the HttpConfiguration.IncludesErrorDetailPolicy:

In your Global.asax:

var config = GlobalConfiguration.Configuration;
config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;

I have used this configuration property to force error messages to include details.

Answer 2

Had the same issue. It's indeed because of the custom errors setting.

In a real world scenario, you would definitely want to use a custom error page in your application, but in order for custom exception messages to work in the WebAPI you need to disable the custom errors page.

How to fix this? Luckily, you can use the <location> element in your web.config to solve this.

Solution:

  <!-- General for the application -->
  <system.web>
    <customErrors mode="RemoteOnly" defaultRedirect="YourCustomErrorPage.aspx"/>
  </system.web>

  <!-- Override it for paths starting with api (your WebAPI) -->
  <location path="api">
     <system.web>
        <customErrors mode="Off" />
     </system.web>
  </location>

I use this method in my own app, works well.

Answer 3

It sounds like it could very well be your customErrors mode to me. WebAPI is running on top of ASP.NET (MVC), so it uses all the same web.config settings.

If it is a test server, you could try turning customErrors off to verify.

<system.web>
    <customErrors mode="Off" />
</system.web>

Answer 4

OWIN

Since the host choice is not mentioned here, I just wanted to add that in case of OWIN you have to use syneptody's solution BUT not in Global.asax, as per this answer and my own tests.

You want to insert IncludeErrorDetailPolicy.Always in the Startup.cs file:

public void Configuration(IAppBuilder appBuilder)
{
    HttpConfiguration Config = new HttpConfiguration(); 
    Config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;
    ...
}

Answer 5

There have been many changes in the Web API code base since beta. Lots of awesomeness. See how to get nightly signed builds here.

The generic HttpResponseMessage<T> is no longer supported. Use HttpRequestMessage.CreateResponse<T>. See this and this.

You'll want to update to at least the current nightly build instead of using the beta if you're planning on sticking with it going forward. So many good improvements particularly for Web API.

EDIT: In my mind, this was actually related to your original question because, while I haven't look into it for a concrete answer, it seems the newer stuff returns responses that don't get intercepted by IIS. It may have to do with the re-working of the error handling / error reporting.

UPDATE 8/14/2012 The current Release Candidate for MVC 4 / Web API is good enough. You don't need to get the nightly build anymore unless you want to stay utterly up-to-date.