Processing an Incoming Request

In this section we take you through what happens to an incoming HTTP request. First, the client (e.g., Internet Explorer, Netscape Navigator, Opera, and so on) sends a request to your server. IIS receives this request and checks application mapping settings for the request. IIS keeps all this data in its metabase, and this data must be configured correctly for your Web application to work as desired. Both overmapping and undermapping settings can cause problems (security risks through overmapping and functionality breakage through undermapping).

If the request isn t mapped to an ATL Server ISAPI extension, then IIS will do whatever the extension mapping indicates. Let s assume that in this case it s an ATL Server request (because that s the scenario we re interested in).

If the request maps to your ISAPI extension, then your ISAPI extension will be invoked and it will check the incoming request to see what type of request it is. Typically you ll map SRF files and DLLs to your ISAPI extension, so we focus on these two mappings.

Say that the request is for an SRF file. Your ISAPI extension will open the SRF file to determine the name of the application DLL and the handler. The ISAPI extension will then check if the application DLL is in the cache. If the DLL isn t in the cache, then the ISAPI extension will load the application DLL and cache all the entry points.

Now the ISAPI extension will call into the entry point of your application DLL in order to obtain an instance of the appropriate handler. Once this has been done, HandleRequest can be called on the IRequestHandler interface of this handler.

The handler parses any query parameters and form variables that have been passed to it. It then calls ValidateAndExchange . If ValidateAndExchange fails, then the handler returns an error to your ISAPI extension. If ValidateAndExchange succeeds, the handler gets the name of the requested SRF file and queries the ISAPI extension to see if this SRF file is in the cache (stencil cache). If the stencil isn t in the cache, then the handler loads and parses this SRF file, and adds it to the cache. Once this is done, the handler can render the stencil.

Let s go back to the situation where your ISAPI extension received the request and checked what sort of request it was. In the previous case, we assumed that it was an SRF request, but what happens if it s a request for an application DLL directly? In this case the ISAPI extension checks if the application DLL is in the cache. If it isn t, the ISAPI loads it and caches the entry points. It will then call into the entry point and obtain an instance of the appropriate handler (designated by query parameters in the request). It proceeds by calling HandleRequest on the IRequestHandler interface.

This process may become clearer if you look at a diagram for a given request. Figure 5-1 shows the ISAPI flow control, and Figure 5-2 shows the application DLL flow control.

Figure 5-1. ISAPI flow control

Figure 5-2. Application DLL (request handler) flow control