IIS, why you squashing my custom error responses?

I’ve been working on an open source project called Femah recently and came across a rather time consuming error when we pushed a demo application up to Azure.

The work I was doing was around the Femah API, providing some interactive documentation, using some fiddles from  http://dotnetfiddle.net.

It works on my machine

Windows 8.1, IIS 8.5, .NET 4.5, Visual Studio 2012

Yes it does, I can happily cURL this, no problems.

c:\>curl -v -X GET http://localhost/femah.axd/api/featureswitchtypes/notvalid/

and get the following output, notice that custom error message there “Error: Service ‘featureswitchtypes’ does not support parameter querying.” Note: Yes I know that should be a JSON object, working on it!


It doesn’t work on Azure.

We have a test application that references the Femah Nuget package, which you can see here, running the same cURL command against the Azure site this time.

c:\>curl -v -X GET http://localhost/femah.axd/api/featureswitchtypes/notvalid/

Yields this, notice I have no custom error here.


Further more the Content-Type of the response is Content-Type: text/html as opposed to Content-Type: application/json as we saw in a successful response locally.

What is it?

A lot of googling and chasing my tail a little and learning how to enable Failed Request Routing on Azure Websites and I found this


That’s beyondcompare giving up a nice diff between two IIS failed request logs (Azure on the left, localhost on the right), you can see the EventData buffer is replaced with a standard error message for the HTTP code (405) that we’re returning.

So, I finally found this on Stackoverflow, more detail here from Mike Volodarsky which I recommend you read, explains in more detail and how to restrict passthrough of existing errors to a single website.

So, adding the following within the system.webServer element of the web.config of our demo app.

<httpErrors existingResponse="PassThrough" />

Resulted in us seeing our custom errors from the Azure hosted app.


To conclude

This working locally through me, maybe Azure has a different default to harden their IIS configurations, or maybe the loadbalancer (ARR?) is getting a bit too involved. Regardless, there’s a fix and now I have somewhere to look if I come across it again in a years time.