Error Handling (ATL Server)
Error handling is an important part of any application. Consider your error handling strategy carefully to help you debug your application during development, troubleshoot problems once deployed, and keep your site's users informed.
Rejecting Bad Requests
One of the most important areas of error handling in a Web application is rejecting bad requests. On a high volume Web site, the number of erroneous requests can be high. To ensure that such requests have minimal impact on server performance, you should analyze and reject bad requests as early as possible. Look at each stage of your site's architecture and remove as many requests as possible before passing the request to the next stage.
The first step to rejecting bad requests is configuring Internet Information Services (IIS). Use Directory Security to reject requests from unauthorized users or to block users based on IP address if that is appropriate to your site. Decide which HTTP methods your site needs to handle and allow only those to pass through to your ISAPI DLL. Use the IIS App Mappings property page to limit the methods that are associated with your ISAPI DLL to the ones that you actually expect to use.
Once your ISAPI DLL has been invoked, you can filter out further requests. At this stage, it is a good idea to keep the processing simple and applicable to the whole site. For example, consider removing large requests at this stage. For details, see Limiting the Size of a Request. Balance the processing cost of checking every request with the cost of passing bad requests on to your request handler DLL.
Once the request reaches your request handler DLL, you can choose to reject requests before or after the request and response objects have been initialized. See Initializing Request Handlers for information about the possible points at which you can add your error checking code during initialization.
Handling Errors Early
Maintaining the performance of your Web site in the presence of bad requests is not the only reason to identify and handle errors as early as possible. In many cases, it is important to identify errors before any data has been sent to the client. In particular, if you want to send a distinguished HTTP error status code to the client, you must identify the error before you send HTTP headers to the client. ATL Server helps you in this goal by buffering the response by default. This means that you can build your responses in an intuitive way without committing to sending the data to the client until you are done.
Generating a Response
For an example of generating an error response and a discussion of the related issues, see Creating an Error Response in the ATL Server Tutorial. For a complete sample demonstrating the same principles with slightly different features, see the ShowErrors section of the WebFeatures Sample.