Delegating errorMode in httpErrors

  • Published on March 19, 2008 by walterov
  • Updated on February 11, 2009 by walterov

Warning: This functionality is not currently working as expected in IIS 7.0. It is being addressed for the next release. In IIS 7.0 you can lock and unlock HTTP errors for particular sites or for the entire server; but, currently, "lockAllAttributesExcept="errorMode" is not working for httpErrors. Yet you can use the ideas in this article about unlocking particular attributes in other IIS 7.0 configuration sections.  

There are cases when a hoster may need to delegate to its customers specific settings in the “applicationhost.config” file without delegating the entire section, the errorMode setting in the httpErrors section is one of them, another one is the scriptErrorSentToBrowser setting in the ASP section. For troubleshooting purposes, a hoster’s customer may want to show Detailed Errors in remote clients. To enable it, the hoster would need to lock all attributes except errorMode (lockAllAttributesExcept="errorMode") and lock the error element (lockElements="error"). This way customers can change errorMode from "detailedLocalOnly" to "Detailed" and they would get Detailed Errors for all of their errors.

To Delegate the errorMode setting:

1. Allow the delegation of the <httpErrors> section in applicationhost.config via overrideModeDefault by opening "%windir%\system32\inetsrv\config\applicationhost.config" with a text editor and changing the <section name="httpErrors" overrideModeDefault="Deny" /> element as follows:

<section name="httpErrors" overrideModeDefault="Allow" />

2. Use lockAllAttributesExcept and lockElements to only allow the delegation of the errorMode setting, locate the <httpErrors> element and change as follows:

<httpErrors lockAllAttributesExcept="errorMode" lockElements="error" > 

   Your httpErrors section might look like this after the change:

<httpErrors lockAllAttributesExcept="errorMode" lockElements="error"> 
  <error statusCode="401" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="401.htm" />
  <error statusCode="403" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="403.htm" />
  <error statusCode="404" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="404.htm" />
  <error statusCode="405" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="405.htm" />
  <error statusCode="406" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="406.htm" />
  <error statusCode="412" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="412.htm" />
  <error statusCode="500" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="500.htm" />
  <error statusCode="501" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="501.htm" />
  <error statusCode="502" prefixLanguageFilePath="%SystemDrive%\inetpub\custerr" path="502.htm" />
</httpErrors> 

3. Now you as the hoster can use appcmd to set the errorMode setting to "Detailed" or "Custom" (see example below)

%windir%\system32\inetsrv\appcmd set config "Default Web Site" -section:httpErrors -errorMode:Detailed

   or you could ask your customers to put the following statement in their web.config files:

<system.webServer>
   <httpErrors errorMode="Detailed"/>
</system.webServer>

Resources

For more information see:

Comments

"for security purposes you should not unlock the entire httpErrors section"

Can you explain why "error"-Elemts should be locked or what security holes it could create?

If a customer want's to store his own 404/405 pages on his webspace and point to it in his web.config it wouldn't be possible this way.
And even worse also the admin can't configure custom error pages for a certain web anymore, even if a customer asks for.

So if I haven't missed something the suggested config would enforce one unique error pages configuration for the entire server, right?

Oct 16 2008 by werkof

Suggested delegation configuration doesn’t work as it suppose to. Particularly lockElements="error" part. Site administrator can modify any custom error entry, management service saves this modification into site’s web.config. Next time, when admin opens or refresh “Error Pages” page for the site, IIS Manager throw “Lock violation” error, and then shows alert “Could not retrieve the custom errors”. IMHO, the code responsible for committing changes into httpErrors/> section in config files doesn’t check lock settings.

Jan 29 2009 by dmitrig

Thanks dmitrig and werkof, I added a warning explaining the "lockAllAttributesExcept="errorMode" not working as expected issue and removed the security comment to avoid confusions.

Feb 11 2009 by walterov

Hi dmitrig,

Thank you for your feedback. I am happy to report that this issue has been fix in Windows 7 / Windows Server 2008 R2.

Thanks

Nov 02 2009 by wimoy

Submit a Comment

You must Log In to comment.

Microsoft Communities