ASP.NET —

Internet Information Services

All Web application environments work fundamentally the same way. No matter what hardware/software platform you use, some piece of software is required on the server to watch port 80 for incoming HTTP requests. When a request arrives, it's the server's job to somehow respond to the request in a meaningful way. On the Microsoft platform, Internet Information Services is the watchdog intercepting HTTP requests from port 80-the normal inbound port for HTTP requests. Internet servers use other ports as well. For example, HTTPS (Secure HTTP) happens over port 443. However, right now we're mostly interested in normal Internet traffic over port 80.

When a browser makes a call to a server running on the Microsoft platform, IIS intercepts that request and searches for the resource identified by the URL. IIS divides its directory space into manageable chunks called virtual directories. For example, imagine someone tries to get to a resource on your server using this URL:

http://www.aspnetstepbystep.com/examples/showfeatures.htm

The domain "aspnetstepbystep" is fictitious and used here for illustration. However, if there were a server registered using this name, the URL would identify the entire resource. Within this URL, http://www.aspnetstepbystep.com identifies the server and will direct the request through a maze of routers. Once the request reaches the server, the server will look for the showfeatures.htm resource in some directory-type entity named examples. If the server is running IIS, examples refers to a virtual directory.

IIS divides its working space into multiple virtual directories. Each virtual directory typically refers to a single application. That way, IIS can serve multiple applications. Each virtual directory includes various configuration properties, including such things as security options, error handling redirections, and application isolation options (among others). The configuration parameters also include mappings between file extensions and ISAPI DLLs.

Internet Services Application Programming Interface DLLs

On the Microsoft platform, creating a process space is an expensive proposition (in terms of system resources and clock cycles). Imagine trying to write a server that responds to each request by starting a separate program. The poor server would be bogged down very quickly, and your e-commerce site would stop making money.

Microsoft's architecture prefers using DLLs to respond to requests. DLLs are relatively inexpensive to load, and running code within a DLL executes very quickly. The DLLs handling Web requests are named ISAPI DLLs (ISAPI stands for Internet Services Application Programming Interface).

While we won't dive all the way into the inner workings of ISAPI DLLs, we'll take a cursory look at their architecture so you can see how they relate to ASP.NET.

ISAPI DLLs handling normal HTTP requests define an entry point named HttpExtensionProc. Although ISAPI extension DLLs define more entry points than HttpExtentsionProc, it is by far the most important method in an ISAPI DLL. The important point to realize about ISAPI extension DLLs is that they all implement this singular function when responding to HTTP requests. However, they may all respond differently.

  • The HttpExtensionProc method takes a single parameter-an EXTENSION_CONTROL_BLOCK structure. EXTENSION_CONTROL_BLOCK includes the entire context of a request. We don't need to see the whole structure here. However, we will see the managed equivalent in ASP.NET when we look at the HttpContext class.

Upon receiving a request, IIS packages the information into the EXTENSION_CONTROL_BLOCK. IIS then passes the structure into the ISAPI DLL through the HttpExtensionProc entry point. The ISAPI extnsion DLL is responsible for parsing the incoming request and doing something with it. The ISAPI extension DLL is completely at liberty to do whatever it wants to with the request. For example, the client might make a request that includes parameters in the query string (perhaps the client is looking for a customer lookup or something similar). The ISAPI extensio DLL uses those query string parameters to create a database query specific to the site. If the site is a commerce site, the database query might be for the current inventory. After processing the request, the ISAPI DLL streams any results back to the client.

You may have had some experience working with classic ASP, in which case much of this structure will appear familiar to you. For example, calling Write through ASP's intrinsic Response object eventually ends up executing the method pointed to by WriteClient.

We've explored the inner structure of an ISAPI DLL. Let's see how these DLLs fit into IIS.

Internet Information Services

The user interface to IIS is available through the Control Panel. To get a feel for how to administer IIS 5.1, let's take a short tour. It's important to have some facility with IIS because ASP.NET relies on it to service Web requests. IIS 5.x and 6.0 work similarly as far as dividing the server's application space into virtual directories. IIS 6.0 includes many other features such as application isolation and recycling, which is out of the scope of this discussion.

Running IIS

  1. Run IIS.

    To get to IIS, first go to Administrative Tools. On Windows XP Professional, you can do this through the Control Panel. Run Internet Information Services and you should see the IIS user interface on your screen:

    Graphic
  2. View configuration for a specific virtual directory.

    On the left-hand side of the screen is an expandable tree showing the Web sites and virtual directories available through IIS on your machine. To find out more details about how the directory is configured, right-click on the directory and select Properties from the context menu. You'll see the Properties dialog box:

    Graphic

    As you can see, the Properties dialog box is fairly extensive, covering all aspects of how the directory is accessed from the outside world. We won't spend a lot of time here because ASP.NET takes care of most of these issues (rather than leaving them up to IIS).

  3. View file mappings for a virtual directory.

    Click the Configuration button to see the file mappings. IIS responds by showing you another dialog box listing the file mappings for the directory:

    Graphic

    These mappings tell IIS which DLL should handle the request. Static file types such as HTM are transmitted directly back to the client. However, dynamic pages whose contents can change between posts require further processing, so they are assigned to specific ISAPI DLLs. There's not a lot of variety in the kinds of DLLs listed above. In fact, most of the file types in this directory are handled by a file named ASPNET_ISAPI.DLL. We'll talk about that DLL in much greater detail soon. Notice the other DLL in the list: ASP.DLL. This is the DLL for handling classic Active Server Pages requests.