I'm running IIS 4.0 on Windows NT 4.0 Service Pack 6a (SP6a). I've created a Web site that uses host headers, and I've designed custom error messages for the site. I understand that the custom 404 error messages should appear every time a user requests in the URL a file or directory that doesn't exist on the Web site. However, here's what happens. If the URL refers to a

  • nonexistent folder, such as http:// mydomain/nofolder, the custom error page appears
  • nonexistent file ending in .htm, such as http://mydomain/nofile.htm, error 404 Object not found appears
  • nonexistent file ending in .html, such as http://mydomain/nofile.html, error 404 Object not found appears
  • nonexistent file ending in a custom extension, such as http://mydomain/ nofile.zzz, error 404 Object not found appears

How can I get my custom error page always to appear?

IS handles error processing in a couple of different ways. Usually, when you request a file, folder, or virtual directory that doesn't exist, IIS looks up the target's error 404 Object not found to see whether you've set up custom processing. If you've set up a custom page, IIS presents that page. If you haven't, IIS presents the default message. The exception to this rule is when you call an extension for which you used Application Mappings to map to a .dll or .exe file that processes that extension. For example, Active Server Pages (.asp) files are mapped to asp.dll, and server-side include (.ssi) files are mapped to ssiinc.dll.

In these and other cases in which the file extension is mapped to an application-processing executable file, IIS simply hands off the error-processing task to the application. Consequently, you must code error-handling logic into the application.

In your situation, the nonexistent folder presented the custom message, which tells you that the custom message works when it's called. So the question is, why isn't the custom message called in all other cases? This problem can occur when you've mapped .htm or .html files to asp.dll or ssiinc.dll so that you can put script in standard .html files and IIS can process them. Because IIS is supposed to launch a scripting engine that then attempts to process a nonexistent file, IIS returns error message 404 object not found instead of a standard HTML error, bypassing your custom error message. This behavior is true for your custom file mapping as well.

You can, however, force IIS to check whether a file exists before IIS hands the file off to the application mappings. To force IIS to check, follow these steps:

  1. Right-click a Web site, folder, or virtual directory, then select Properties.
  2. Click the Home Directory tab (for a Web site), the Directory tab (for a folder), or the Virtual Directory tab (for a virtual directory).
  3. Click Configuration.
  4. Select an application mapping from the list, which Figure 1 shows.
  5. Click Edit.
  6. In the Add/Edit Application Extension Mapping dialog box, which Figure 2 shows, select the Check that file exists check box.

When you've selected the Check that file exists check box, IIS checks to make sure that the file (in this case, an .shtml file) exists and that the user has proper permissions to it before IIS passes the file to ssiinc.dll. If the requested file doesn't exist, the usual error processing occurs; if you've created a custom error message, that custom error message will appear.

By default, this feature is disabled, largely for performance reasons. When you enable the feature, IIS opens the file, then hands the file off to the application-mapped executable file, which then also opens the file. The performance penalty for opening each file twice might or might not be acceptable depending on your server's load and capabilities.

However, you receive a security benefit from enabling the Check that file exists feature. If an intruder attempts to send your server an improperly formatted request that invokes a mapped extension, IIS won't pass the improperly formatted request to the called .dll or .exe file because IIS checks to see whether a file exists before application processing begins. In fact, in the article "Improperly Formatted HTTP Request May Cause INETINFO Process to Fail" (http:// support.microsoft.com/support/kb/articles/q234/9/05.asp), Microsoft recommends enabling this feature to prevent such problems. For more information about custom error messages, see the Microsoft articles "PRB: IIS Fails to Display Custom Error Messages for .asp Files" (http://support .microsoft.com/support/kb/articles/q176/ 9/19.asp) and "Configuring Custom Error Messages in IIS 5.0" (http://www.microsoft.com/technet/iis/custerr.asp).