The Microsoft Web Platform (Internet Information Services)

When the World Wide Web began taking root in the early 1990s, many sites were little more than collections of Hypertext Markup Language (HTML) files and perhaps some image files. Clients with Internet browsers surfed to various sites using Universal Resource Locators (URLs) that took a form like this: http://www.example.com.

After typing the URL and sending the request through a maze of routers, the request finally ended up at a server somewhere. In the earliest days of the Web, the server was probably a UNIX box. Web technologies soon evolved to handle more elaborate requests (not just file requests). Through the development of the Common Gateway Interface and the inclusion of HTML tags representing standard GUI controls (such as combo boxes, push buttons, and text boxes), the Web became capable of handling interactive traffic. That is, a client could carry on a two-way conversation with web servers that extended beyond simple file requests. Of course, this capability led to the great upsurge in web sites during the late 1990s, giving rise to such enterprises as Amazon.com and Google.

The earliest means of supporting interactive capabilities over the Web were made available through the Common Gateway Interface (CGI). CGI worked by handling separate incoming requests with a new process for each request. Although the Microsoft platform supports the CGI, it doesn't work quite as well as on a UNIX box. Starting new processes on a UNIX box is not as expensive as starting new processes on a Windows box. To compensate, Microsoft introduced the Internet Services API and its own new Internet server: Internet Information Services (IIS). The IIS strategy is that it's much faster to load a DLL to respond to an HTTP request than it is to start a whole new process.

IIS and ISAPI

The IIS component is the heart of Microsoft's web platform. Most modern web sites built around the Microsoft platform involve IIS and ISAPI DLLs. All the modern Microsoft web-based programming frameworks are extensions of the IIS/ISAPI architecture. Even classic ASP and the more modern ASP.NET rely on IIS and ISAPI at their core. And as you'll soon see, ATL Server depends upon IIS and ISAPI as well.

Regardless of the programming framework used (raw sockets programming, ASP, ASP.NET, or ATL Server), processing web requests is similar from framework to framework. A component listens to port 80 for HTTP requests. When a request, comes in, the component parses the request and figures out what to do with it. The request might vary from sending back some specific HTML, to returning a graphics file, or perhaps even to invoking a method of some sort.

When programming to the modern Microsoft web-based frameworks, IIS is the component that listens to port 80. IIS handles some requests directly and delegates others to specific ISAPI extension DLLs to execute the request. By default, IIS handles requests for standard HTML files directly. As an alternative, a custom file extension might be mapped to a handwritten ISAPI DLL that executes the request.

Classic ASP and ASP.NET integrate into IIS as ISAPI DLLs. IIS handles requests ASP files (*.asp) by mapping them to an ISAPI DLL named ASP.DLL, which handles the request by parsing the request string, loading the ASP file, parsing the contents of the file, and servicing the request according to the instructions given in the ASP file. ASP.NET files (*.aspx) are handled by an ISAPI DLL named ASPNET_ISAPI.DLL, which brings in the Common Language Runtime to help it process requests.

To set the stage for understanding ATL Server, let's take a look at how ISAPI extension DLLs work.

ISAPI Extension DLLs

Although IIS does a perfectly fine job responding to requests for standard web file types (such as HTML and JPG), its real power lies in the capability to extend your server by writing custom DLLs to respond to requests.

The core ISAPI infrastructure is actually fairly simple. ISAPI extension DLLs implement three entry points:

BOOL WINAPI GetExtensionVersion(HSE_VERSION_INFO* pVer);         DWORD WINAPI HttpExtensionProc(LPEXTENSION_CONTROL_BLOCK lpECB); BOOL WINAPI TerminateExtension(DWORD dwFlags);                   

These three methods are the hooks for writing your web site using custom DLLs. GetExtensionVersion is called when IIS invokes the application for the first time. GetExtensionVersion must set the version number in the HSE_VERSION_INFO structure passed in and then return trUE for IIS to be capable of using your ISAPI DLL.

IIS calls the TerminateExtension entry point when IIS is ready to unload the DLL from its process. If you don't need to do any cleanup, the TerminateExtension entry point is optional.

The heart of the extension is the HttpExtensionProc function. Notice that HttpExtensionProc takes a single parameter: an EXTENSION_CONTROL_BLOCK structure. The structure includes everything you'd ever want to know about a request, including the kind of request made, the content of the request, the type of content, a method for getting the server variables (for example, information about the connection), a method for writing output to the client, and a method for reading data from the body of the HTTP request. Here's the EXTENSION_CONTROL_BLOCK:

typedef struct _EXTENSION_CONTROL_BLOCK {                           DWORD cbSize;             // size of this struct.                 DWORD dwVersion;          // version info of this spec            HCONN ConnID;             // Context number not to be modified!   DWORD dwHttpStatusCode;   // HTTP Status code                     CHAR lpszLogData[HSE_LOG_BUFFER_LEN]; // null terminated log                            // info specific to this Extension DLL      LPSTR lpszMethod;         // REQUEST_METHOD                       LPSTR lpszQueryString;    // QUERY_STRING                         LPSTR lpszPathInfo;       // PATH_INFO                            LPSTR lpszPathTranslated; // PATH_TRANSLATED                      DWORD cbTotalBytes;       // Total bytes indicated from client    DWORD cbAvailable;        // Available number of bytes            LPBYTE lpbData;           // pointer to cbAvailable bytes         LPSTR lpszContentType;    // Content type of client data          BOOL (WINAPI * GetServerVariable)(                                  HCONN hConn, LPSTR lpszVariableName,                              LPVOID lpvBuffer, LPDWORD lpdwSize);                            BOOL (WINAPI * WriteClient)(HCONN ConnID, LPVOID Buffer,            LPDWORD lpdwBytes, DWORD dwReserved);                           BOOL (WINAPI * ReadClient)(HCONN ConnID, LPVOID lpvBuffer,          LPDWORD lpdwSize);                                              BOOL (WINAPI * ServerSupportFunction)(HCONN hConn,                  DWORD dwHSERequest, LPVOID lpvBuffer, LPDWORD lpdwSize,           LPDWORD lpdwDataType);                                        } EXTENSION_CONTROL_BLOCK, *LPEXTENSION_CONTROL_BLOCK;            

When IIS receives a request, it packages the information into the EXTENSION_CONTROL_BLOCK and passes a pointer to the structure into the ISAPI DLL via the HttpExtensionProc entry point. The ISAPI extension's job is to parse the incoming request into a useable form. After that, it's completely up to the ISAPI DLL to do whatever it wants to with the request. For example, if the client makes some sort of request using query parameters (perhaps a product lookup), the ISAPI DLL might use those parameters to create a database query. The ISAPI DLL passes any results back to the client using the pointer to the WriteClient method passed in through the extension block.

If you've had any experience working with frameworks such as classic ASP or ASP.NET, most of this structure will appear familiar to you. For example, when you call Write through ASP's intrinsic Response object, execution eventually ends up passing through the method pointed to by WriteClient.