• Choose a category
• All
• Classic-Fiction

—Winston Churchill

Each ASP.NET request goes hand in hand with a companion object for its entire lifetime—an instance of the HttpContext class. The HttpContext object wraps up all the HTTP-specific information available about the request. It is then used by the various HTTP modules and used to group references to intrinsic worker objects such as Request, Response, and Server.

In this chapter, we’ll first review the startup process of the ASP.NET application and then move on to examine the various objects that form the context of the HTTP request.

Initialization of the Application

Each ASP.NET request is carried out by an ASP.NET application object. An ASP.NET application consists of an instance of the HttpApplication class that you briefly met in Chapter 2. HttpApplication is a global.asax-derived object that handles all HTTP requests directed to a particular virtual folder.

An ASP.NET running application is wholly represented by its virtual folder and, optionally, by the global.asax file. The virtual folder name is a sort of key that the HTTP runtime uses to selectively identify which of the running applications should take care of the incoming request. The global.asax file, if present, contains settings and code for responding to application-level events raised by ASP.NET or by registered HTTP modules that affect the application.

The particular HttpApplication selected is responsible for managing the entire lifetime of the request it is assigned to. That instance of HttpApplication can be reused only after the request has been completed. If no HttpApplication object is available, either because the application has not been started yet or all valid objects are busy, a new HttpApplication is created and pooled.

Properties of the HttpApplication Class

Although the HttpApplication provides a public constructor, user applications never need to create instances of the HttpApplication class directly. The ASP.NET runtime infrastructure always does the job for you. As mentioned, instances of the class are pooled and, as such, can process many requests in their lifetime, but always one at a time. Should concurrent requests arrive for the same application, additional instances are created. Table 16-1 lists the properties defined for the class.

Table 16-1. HttpApplication Properties

Property

Description

Application

Instance of the HttpApplicationState class. It represents the global and shared state of the application. It is functionally equivalent to the ASP intrinsic Application object.

Context

Instance of the HttpContext class. It encapsulates in a single object all HTTP-specific information about the current request. Intrinsic objects (for example, Application and Request) are also exposed as properties.

Modules

Gets the collection of modules that affect the current application.

Request

Instance of the HttpRequest class. It represents the current HTTP request. It is functionally equivalent to the ASP intrinsic Request object.

Response

Instance of the HttpResponse class. It sends HTTP response data to the client. It is functionally equivalent to the ASP intrinsic Response object.

Server

Instance of the HttpServerUtility class. It provides helper methods for processing Web requests. It is functionally equivalent to the ASP intrinsic Server object.

Session

Instance of the HttpSessionState class. It manages user-specific data. It is functionally equivalent to the ASP intrinsic Session object.

User

An IPrincipal object that represents the user making the request.

The HttpApplication is managed by the ASP.NET infrastructure, so how can you take advantage of the fairly rich, public programming interface of the class? The answer is that properties and, even more, overridable methods and class events can be accessed and programmatically manipulated in the global.asax file. (I’ll return to global.asax in a moment.)

Application Modules

The property Modules returns a collection of application-wide components providing ad hoc services.