How ASP.NET Web Pages are Processed on the Web Server


3 Νοε 2013 (πριν από 4 χρόνια και 6 μήνες)

85 εμφανίσεις

How ASP.NET Web Pages are Processed on the Web Server

Scott Mitchell


Have you ever wondered, precisely, what happens on the Web server when a request for an ASP.NET Web pa
comes in? How does the Web server handle the incoming request? How is the HTML that is emitted to the client
generated? What mechanisms are possible for us developers to work with an incoming request in its various stages
of processing? In this article
we'll take a rather detailed look at how ASP.NET Web pages are processed on the Web

Step 0: The Browser Makes an HTTP Request for an ASP.NET Web Page

The entire process begins with a Web browser making a request for an ASP.NET Web page. For exampl
e, a user
might type into their browser's Address window the URL for this article,
. The Web browser, then, would
make an HTTP request to the 4Guys Web server, asking for the particular file

Step 1: The Web Server Receives the HTTP Request

The sole task of a Web server is to accept incoming HTTP requests and to return the requested resource in an HTTP
response. The 4Guys Web server runs Microsoft's Internet Information Services (
IIS) Web server. The first things
IIS does when a request comes in is decide how to handle the request. Its decision is based upon the requested file's
extension. For example, if the requested file has the

extension, IIS will route the request to be h
andled by



There are numerous file extensions that map to the ASP.NET engine, some of which include:

, for ASP.NET Web pages,

, for ASP.NET Web services,

, for ASP.NET configuration files,

, for custom ASP.NET HTTP handlers,

, for remo
ting resources,

And others!

In the IIS administration screens, you can configure the extension mappings. The screenshot below shows the
configuration screen for IIS 5.0.

You could, for example, add your own custom extensions here. That is, you could h
ave requests for

routed to the ASP.NET engine.

The diagram below illustrates the steps 0 and 1 of a request for an ASP.NET Web page. When a request comes into
the Web server, it is routed to the proper place (perhaps

for classic ASP

page requests, perhaps the
ASP.NET engine for ASP.NET requests) based on the requested file's extension.

Step 2: Examining the ASP.NET Engine

An initial request for

will reach IIS
and then be routed to the ASP.NET engine, but what happens next? The ASP.NET engine is often referred to as the
ASP.NET HTTP pipeline, because the incoming request
passes through a variable number of
HTTP modules

on its
way to an
HTTP handler

HTTP modules are classes that have access to the incoming request. These modules can inspect the incoming
request and make decisions that affect the internal flow of the reque
st. After passing through the specified HTTP
modules, the request reaches an HTTP handler, whose job it is to generate the output that will be sent back to the
requesting browser. The following diagram illustrates the pipeline an ASP.NET request flows thro

There are a number of pre
built HTTP modules that are included in the HTTP pipeline by default. These modules

, which handles ret
urning and caching the page's HTML output, if needed

, which loads in the session state based on the user's incoming request and the session method
specified in the


FormsAuthentication, which attempts to authenticate the user based

on the forms authentication scheme, if

And others!

In fact, you can see a precise list of what modules are used by default by going to the

(located in the

directory) and searchi
for the

element. The following shows the default



<add name="OutputCache" type="System.Web.Caching.OutputCacheModule" />

<add name="Session" type="System.Web.SessionState.SessionStateModule" />

dd name="WindowsAuthentication"
type="System.Web.Security.WindowsAuthenticationModule" />

<add name="FormsAuthentication"
type="System.Web.Security.FormsAuthenticationModule" />

<add name="PassportAuthentication"
nticationModule" />

<add name="UrlAuthorization"
type="System.Web.Security.UrlAuthorizationModule" />

<add name="FileAuthorization"
type="System.Web.Security.FileAuthorizationModule" />

<add name="ErrorHandlerModule"


PublicKeyToken=b03f5f7f11d50a3a" />


HTTP handlers are the endpoints in the ASP.NET HTTP

pipeline. The job of the HTTP handler is to generate the
output for the requested resource. For ASP.NET Web pages, this means rendering the Web controls into HTML and
returning this HTML. For a Web service, it would involve executing the specified method
and wrapping its return
values into an appropriately formatted SOAP response. (For more on Web services, be sure to read:
An Extensive
Examination of Web Services

Different ASP.NET resources use different HTTP hand
lers. The handlers used by default are spelled out in the

section. Entries in this section refer to classes that are either HTTP
handlers themselves or are HTTP handler
. An HTTP handler factory merely returns a suit
able HTTP
handler instance when invoked.

The following shows a snippet of the

element in the default



<add verb="*" path="*.vjsproj" type="System.Web.HttpForbiddenHandler" />

<add verb="*" path="*.java
" type="System.Web.HttpForbiddenHandler" />

<add verb="*" path="*.jsl" type="System.Web.HttpForbiddenHandler" />

<add verb="*" path="trace.axd" type="System.Web.Handlers.TraceHandler"

<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFact
ory" />

<add verb="*" path="*.ashx" type="System.Web.UI.SimpleHandlerFactory" />



Realize that you can create your own HTTP modules and HTTP handlers, and then plug them into the pipeline for

Web sites on the Web server by modif
, or you can add them to a particular Web
application by modifying that application's

file. A thorough discussion on using HTTP modules and
handlers is far beyond the scope of this article, but realize that you can accomplish
some neat things using modules
and handlers. For example, you can use HTTP modules to provide a custom URL rewritter, which can be useful for
automatically fixing 404 errors to using shorter and user
friendlier URLs. (See

A URL Rewriting
Engine for .NET

for an example of using HTTP modules for URL rewriting.) Another cool use of modules is
compressing the generated HTML

For a good discussion on HTTP modules and handlers be sure to read Mansoor Ahmed Siddiqui's article:
Handlers and HTTP Modules in ASP.NET

Step 3: Generating the Output

The final step is fo
r the suitable HTTP handler to generate the appropriate output. This output, then, is passed back
through the HTTP modules and then back to IIS, which then sends it back to the client that initiated the request. (If
the client was a Web browser, the Web br
owser would receive this HTML and display it.)

Since the steps for generating the output differ by HTTP handler, let's focus in on one in particular

the HTTP
handler that is used to render ASP.NET Web pages. To retrace the initial steps, when a request
comes into IIS for an
ASP.NET page (i.e., one with a

extension), the request is handed off to the ASP.NET engine. The request
then moves through the modules. The request is then routed to the
, since in the

section we have the mapping:



<add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory" />




class is an HTTP handler factory. It's job is to provide an instance of an HTTP
handler that can handle the request. What

does is find the compiled class that represents
the ASP.NET Web page that is being requested.

If you use Visual Studio .NET to create your ASP.NET Web pages you know that the Web pages are compo
sed of
two separate files: a

file, which contains just the HTML markup and Web controls, and a


file that contains the code
behind class (which contains the server
side code). If you don't use Visual
Studio .NET, you likely use a

block to hold the server
side code. Regardless of what
approach you use, when the ASP.NET Web page is first visited after a change to the HTML or Web control content,
the ASP.NET engine creates a class that derives from the

class. This dynamically created
class is then compiled.

Not coincidentally, the

class implements
, thereby indicating that it suffices as an HTTP
handler. What the

does, then, is check to see if a compiled vers
ion of the requested
ASP.NET Web page's class exists. If not, it dynamically creates this class and compiles it. This class, then, has a
particular method invoked which generates the page's complete HTML markup. It's this HTML markup that is then
to the client. (Have you noticed that when visiting an ASP.NET Web page after making changes to the
HTML or Web control content, there is a bit of a delay? This delay is due to the ASP.NET engine needing to
recreate and recompile the ASP.NET page's corresp
onding class.)

Realize that the

class might need to first be generated and compiled by the

before it can be invoked to gener
ate the HTML. The process of page rendering

involves obtaining the HTML markup for the requested ASP.NET Web page

is a bit beyond the scope of this
article, but is discussed in good detail in Dino Esposito's article,
The ASP.NET Page Object Model


In this article we looked at an overview of how ASP.NET Web pages are processed on the Web server. It involves a
number of st
eps, starting with a request from a client, and culminating with the requested ASP.NET Web page's
class generating the page's rendered HTML. In between, the request bounces through IIS and into the ASP.NET
engine, where it proceeds through a module pipelin
e down into the corresponding HTTP handler.

Happy Programming!

Scott Mitchell