Nov 172015

I recently worked with an endpoint in an MVC project that intentionally returns a 409 conflict HTTP status code when a user posts a model with an Id that already exists in the database.  Upon encountering this conflict, the server is supposed to return the 409 status, but the client also expects to receive the conflicting record in the response body.  When running this code in the debugger and hitting the endpoint on localhost via Postman, the 409 status is returned and the existing record is shown in Postman as it is passed in the body.  However, this was not the behavior encountered when hitting this endpoint on a site deployed to Azure.

I deployed the same code that I ran in debug to a WebApp in Azure.  When I did a post to this same endpoint in the Azure site, the 409 status was returned.  However, instead of seeing the conflicting record in the response body, I received this error:

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

This was strange, considering the fact that I had just seen the conflicting record returned when posting to the same endpoint on a server running in debug on my machine.  After some research, I learned that Azure is suppressing the body on purpose to mask error details (e.g. stack traces) from being shown to consumers of the API.

I found a way to ensure that the body is returned from the site on Azure when a 400 or 500 series status is encountered.  It is to be used with caution because you could expose more information than you want about 500 status, such as stack trace information.  To ensure that the body is returned in these cases, add these lines to your web.config: