I am using Windows Azure Websites to host a node.js application. So far everything is great except for my custom errors. In my node app I have an error handler that renders a custom 404 and custom 500 error page just fine on my local machine. However, as soon as I publish to azure it overrides the response when I set the statusCode to anything except 200.
If I don't pass the 500 or 404 statusCode to the response then this does not happen, but I do want the status codes to make it to the browser. Locally I get my custom error page just fine:
However, on azure websites it only returns a single line of text:
The page cannot be displayed because an internal server error has occurred.
I tried creating my own web.config to override the default one with custom errors disabled but that didn't seem to have any effect. Here is my web.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<customErrors mode="off" />
</system.web>
<system.webServer>
<handlers>
<add name="iisnode" path="app.js" verb="*" modules="iisnode"/>
</handlers>
<rewrite>
<rules>
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}"/>
</rule>
<rule name="DynamicContent">
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
</conditions>
<action type="Rewrite" url="app.js"/>
</rule>
</rules>
</rewrite>
<iisnode
debuggingEnabled="true"
devErrorsEnabled="true"
debuggerPathSegment="debug"
nodeProcessCommandLine=""%programfiles(x86)%\nodejs\node.exe""
logDirectory="..\..\LogFiles\nodejs"
watchedFiles="*.js;iisnode.yml;node_modules\*;views\*.jade;views\*.ejb;routes\*.js" />
</system.webServer>
</configuration>
I'm not sure if iisnode
(the extension for iis that routes requests to node.js) is responsible for overriding my error pages or if iis itself is responsible. Any suggestions?
<staticContent>
section in my web.config. Removing that fixed it for me: #22550079 – Rowenarowland<staticContent>
element yourself or is that new in Azure Websites default web.config? If it's part of the default web.config then I'd like to update this answer to reflect your correction. – Relieve