View
223
Download
0
Category
Preview:
Citation preview
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 1/28
Introduction
Microsoft Active Server Pages, also known as ASP, since its first release in late 1996 provided
web developers with a rich and complex framework for building web applications. As years
passed its infrastructure evolved and improved so much that what is now known as ASP.NET is
no longer something which resembles its predecessor. ASP.NET is a framework for building web
applications, that is, applications that run over the web, where the client-server paradigm isrepresented mostly by a browser forwarding requests for resources of different kinds to a web
server. Before the advent of dynamic server-side resource generation techniques like CGI, PHP,
JSP and ASP, all web servers had to do was accept client¶s requests for static resources and
forward them to the requestor. When dynamic technologies started to grow up web serversbecame invested of greater responsibility, since they had to find a way to generate thosedynamic resources on their side and return the result to the client, a task they were not formerlybuilt for.
From a bird¶s eye view, the interaction between client and server is very simple. Communicationsover the web occur via HTTP (Hyper Text Transfer Protocol), an application level protocol which
relies on TCP and IP to transmit data between two nodes connected to the heterogeneous
network known as World Wide Web.
Each dynamic server-side technology essentially leans on a particular web server
implementation, and ASP.NET is tightly coupled with Microsoft¶s Internet Information Server,
aka IIS.
Different servers chose different ways to generate and serve dynamic resources and what we¶re
going to examine is how IIS does that, together with the path a request follows once on the
server and back to the client.
IIS and ISAPI Extensions
As mentioned, static resources needn¶t to be processed by the server; once a request for such aresource arrives, the server just retrieves its contents from the file system and sends it back to
the client as a stream of byte flowing on the HTTP protocol. Static resources can be images,
Javascript files, css style sheets or plain old html pages. It¶s clear that the server needs to knowhow to distinguish between static and dynamic resource, whereas the second need to be
processed somehow and not just sent back to the client. That¶s where ISAPI extensions appear,
where ISAPI stands for Internet Server Application Programming Interface. ISAPI extensions
are modules implemented as plain old Win32 .dll, on which IIS relies to process specific
resources. Mappings between ISAPI extensions and files are configured via the IIS snap-in
and stored in the IIS metabase, where each file extension can be associated with a particular
ISAPI extension, that is, when a request for such a file arrives, IIS handles it to the
corresponding ISAPI extension, confident that it will be able to handle it.
Figure 1: Configuring ISAPI extensions mappings on IIS 5.0
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 2/28
ISAPI extensions obviously need to respect a common interface through which they can be
called by IIS and provided the necessary data to elaborate the request and generate a
response.
As Figure 1 illustrates, the .asp extension is mapped to the asp.dll ISAPI extension; at the
time of ASP this component was in charge of performing all the tasks required to generate a
response, that is, collecting information about the request, made available into the ASP page via
the Request, Response and other common ASP intrinsic objects, parsing and executing the ASP
page and returning the resulting HTML.
Actually, that was a big improvement compared to a technology like CGI, but ASP.NET takes
this approach much further and introduces abstractions which totally shield the developers fromhaving to care about what happens at this stage.
When installed, ASP.NET configures IIS to redirect requests for ASP.NET specific files to anew ISAPI extension called aspnet_isapi.dll. What this extension does is somewhat
different then the former asp.dll extension, which was essentially responsible just for parsing
and executing the requested ASP page. The steps taken by a generic ISAPI module to process
a request are totally hidden from IIS, therefore ISAPI extension may follow different
paradigms in order to process requests.
Table 1: IIS Application Mappings for aspnet_isapi.dll
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 3/28
Extension Resource Type
.asax ASP.NET application files. Usually global.asax.
.ascx ASP.NET user control files.
.ashx HTTP handlers, the managed counterpart of ISAPI extensions.
.asmx ASP.NET web services.
.aspx ASP.NET web pages.
.axd ASP.NET internal HTTP handlers.
As well as the file extensions listed in Table 1, the ASP.NET ISAPI extension manages other
file extensions which are usually not served to web browsers, like Visual Studio project files,source code files and config files, for example.
The ASP.NET Process Model
So far we¶ve seen that when a request for an ASP.NET file is picked up by IIS, it is passed to
the aspnet_isapi.dll, which is the main entry point for ASP.NET related processing.
Actually, what theISAPI
extension does depends sensibly on the version of IIS
available on
the system, and thus the process model, which is the sequence of operations performed by the
ASP.NET runtime to process the request and generate a response, may vary quite a bit.
When running under IIS 5.X, all ASP.NET-related requests are dispatched by the ISAPI
extension to an external worker process called aspnet_wp.exe. The ASP.NET ISAPI
extension, hosted in the IIS process inetinfo.exe, passes the control to
aspnet_wp.exe, along with all the information concerning the incoming request. The
communication between the two is performed via named pipes, a well known mechanism for IPC
(Inter Process Communication). The ASP.NET worker process performs a considerable number
of tasks, together with the ISAPI extension. They are the main authors of all the stuff that
happens under the hoods of an ASP.NET request. To introduce a topic which will be discussed
later, take note of the fact that each web application, corresponding to a different virtualdirectory hosted on IIS, is executed in the context of the same process, the ASP.NET worker
process. To provide isolation and abstraction from the execution context the ASP.NET model
introduces the concept of Application Domains, in brief AppDomains. They can be considered aslightweight processes. More on this later.
If running under IIS 6, on the other side, the aspnet_wp.exe process is not used, in favour
of another process called w3wp.exe. Furthermore, inetinfo.exe is no longer used to
forward HTTP requests to ISAPI extensions, although it keeps running for serving other
protocols requests. A lot of other details change compared to the process model used byprevious versions of IIS, although IIS 6 is capable of running in compatibility mode and
emulate the behavior of its predecessor. A big step forward, compared to the process model
used when running on top of IIS 5, is that incoming requests are in the former handled at a
lower ± Kernel ± level and then forwarded to the correct ISAPI extension, thereby avoiding
inter process communication techniques which may represent an expensive operation under aperformance and resource consumption point of view. We¶ll delve deeper into this topic in thefollowing paragraphs.
IIS 5.0 Process Model
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 4/28
This is the default process model available on Windows 2000 and XP machines. As mentioned itconsists in the IIS inetinfo.exe process listening by default on the TCP port 80 for
incoming HTTP requests and queuing them into a single queue, waiting to be processed. If the
request is specific to ASP.NET, the processing is delegated to the ASP.NET ISAPI extension,
aspnet_isapi.dll. This, in turn, communicates with the ASP.NET worker process,
aspnet_wp.exe via named pipes and finally is the worker process which takes care of
delivering the request to the ASP.NET HTTP runtime environment. This process is graphicallyrepresented in Figure 2.
Figure 2: The IIS 5.0 Process Model
In Figure 2 is represented an additional element we didn¶t mention yet, the ASP.NET HTTP
Runtime Environment. It¶s not topic of this article and will eventually be explained in a follow up
article, but for the sake of this discussion the HTTP Runtime Environment can be considered as a
black box where all the ASP.NET specific processing takes place, all the managed code lives and
developers can actually put their hands on, from the HttpRuntime straight to the HttpHandlerwho will finally process the request and generate the response. This is even referred to as the
ASP.NET Pipeline or HTTP Runtime pipeline.
One of the interesting points of this process model is that all the requests, once handled by the
ISAPI extension, are passed to the ASP.NET worker process. Only one instance of this process
is active at a time, with one exception, discussed later. Therefore all ASP.NET web applicationshosted on IIS are actually hosted inside the worker process, too. However, this doesn¶t mean
that all the applications are run under the same context and share all their data. As mentioned,
ASP.NET introduces the concept of AppDomain, which is essentially a sort of managed
lightweight process which provides isolation and security boundaries. Each IIS virtual directory
is executed in a single AppDomain, which is loaded automatically into the worker processwhenever a resource belonging to that application is requested for the first time. Once theAppDomain is loaded ± that is, all the assemblies required to satisfy that request are loaded into
the AppDomain ± the control is actually passed to the ASP.NET pipeline for the actual
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 5/28
processing. Multiple AppDomains can thus run under the same process, while requests for thesame AppDomain can be served by multiple threads. However, a thread doesn¶t belong to anAppDomain and can serve requests for different AppDomains, but at a given time a threadbelongs to a single AppDomain.
For performance purposes the worker process can be recycled according to some criteria which
can be specified declaratively in the machine.config file placed in the directoryC:\windows\microsoft.net\Framework\[framework version]\CONFIG. These criteria are the ageof the process, number of requests served and queued, time spent idle and consumed memory.
Once one of the threshold value of these parameters is reached, the ISAPI extension creates a
new instance of the worker process, which will we used from then on to serve the requests. Thisis the only time when multiple copies of the process can be running concurrently. In fact, the oldinstance of the process isn¶t killed, but it is allowed to terminate serving the pending requests.
IIS 6.0 Process Model
The IIS 6 process model is the default model on machines running Windows 2003 Server
operating system. It introduces several changes and improvements over the IIS 5 process
model. One of the biggest changes is the concept of application pools. On IIS 5.X all webapplications, that is, all AppDomains, were hosted by the ASP.NET worker process. To achieve a
finer granularity over security boundaries and personalization, the IIS 6 process model allows
applications to run inside different copies of a new worker process, w3wp.exe. Each application
pool can contain multiple AppDomains and is hosted in a single copy of the worker process. Inother words, the shift is from a single process hosting all applications to multiple processes
hosting each an application pool. This model is also called the worker process isolation mode.
Another big change from the previous model is the way IIS listens for incoming requests. With
the IIS 5 model, it was the IIS process, inetinfo.exe, who was listening on a specific TCP
port for HTTP requests. In the IIS 6 architecture, incoming requests are handled and queued at
kernel level instead of user mode via a kernel driver called http.sys; this approach has severaladvantages over the old model and is called kernel-level request queuing.
Figure 3: The IIS 6.0 process model
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 6/28
Figure 3 illustrates the principal components taking part in the request processing when usingthe II 6 model. Once a request arrives the kernel level device driver http.sys routes it to theright application pool queue. Each queue belongs to a specific application pool, and thus to aspecific copy of the worker process, which next receives the request from the queue. This
approach highly reduces the overhead introduced by named pipes used in IIS 5 model since no
inter process communication is taking place, but the requests are headed to the worker process
directly from the kernel level driver. This has many advantages concerning reliability, too. Sincerunning in kernel mode, the request dispatching isn¶t influenced by crashes and malfunctionshapping at user level, that is, in the worker processes. Thereby, even if a worker processcrashes, the system is still capable of accepting incoming requests and eventually restarts thecrashed process.
It¶s the worker process who is in charge of loading the ASP.NET ISAPI extension, which, in
turn, loads the CRL and delegates all the work to the HTTP Runtime.
The w3wp.exe worker process, differently from the aspnet_wp.exe process used in IIS 5
model, isn¶t ASP.NET specific, and is used to handle any kind of requests. The specific worker
process then decides which ISAPI modules to load according to the type of resources it needs
to serve.
A detail not underlined in Figure 3 for simplicity reasons is that incoming requests are forwarded
from the application pool queue to the right worker process via a module loaded in IIS 6 called
Web Administration Service (WAS). This module is responsible for reading worker process ± web
application bindings from the IIS metabase and forwarding the request to the right worker
process.
References
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 7/28
y Simone Busoli - ASP.NET Internals - The bridge between ISAPI and Application Domains y BrainBell.com ± ASP.NET Application Fundamentals
y Dino Esposito ± Programming Microsoft ASP.NET 2.0 Core Reference y Dino Esposito ± Programming Microsoft ASP.NET 2.0 Applications Advanced Topics
y George Shepherd ± IIS 6.0: New Features Improve Your Web Server's Performance,
Reliability, and Scalability y
Fritz Onion ± ASP.NET Pipeline: Use Threads and Build Asynchronous Handlers in Your Server-Side Web Code y Tim Ewald and Keith Brown ± HTTP Pipelines: Securely Implement Request Processing,
Filtering, and Content Redirection with HTTP Pipelines in ASP.NET
Continue reading and see our next or previous
articlesNext Article >>
About Simone Busoli
Sorry, no bio is available
This author has published 9 articles on DotNetSlackers. View other articles or thecomplete profile here.
Other articles in this category
ASP.NET Internals - The bridge between ISAPI and Application Domains In this article I'm going to describe the bridge between managed and unmanagedworlds and how the tw...
You might also be interested in the following related blogposts
Binding in ASP.NET MVC read more Html Encoding Code Blocks With ASP.NET 4 read more
RELEASED ASP.NET MVC 2 Preview 2 read more IIS7 Resource Kit Rocks! read more Microsoft StreamInsight and BizTalk Server - Preliminary Thoughts read more Web Deployment Tool released to web (RTW) read more How do ASP.NET Application_ Events Work read more
Spec Explorer: A Model-Based Testing tool read more How to completely process and filter all bounced e-mail messages and get anotification via email when it's completed! read more Auto-Start ASP.NET Applications (VS 2010 and .NET 4.0 Series) read
Home Articles
Software
Table of Contents
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 8/28
y Introduction y HTTP y HTTP Clients y The Web Server - IIS y The ASP.NET Framework y Conclusion
Introduction
The purpose of this document is to provide a very thorough explanation of whathappens during an HTTP request to an ASP.NET page being served up throughIIS. It starts out with the basics but then dives in to the gory details, moredetail than is probably needed for basic web page development. However athorough knowledge of this process is invaluable when debugging strangeproblems, developing ASP.NET custom web controls or developing any sort of web framework.
HTTPIt is important to understand that HTTP is the only method that a client (e.g.browser) uses to communicate with a web server. The client runs on onecomputer and the server on another. The client connects a socket to the serverand sends an HTTP request. The server does some processing and returns anHTTP response. That's it. IIS Applications, ASP.NET, .NET HTTP Modules, AJAX,Web Services, etc. are all just abstractions on this concept. A deepunderstanding any web technology requires a good working knowledge of HTTP.
HTTP Request
The good news is that HTTP is quite simple. At heart HTTP has two concepts - arequest and a response. Let's look at a sample HTTP request that would be sentfrom a browser to a web server:
GET /Default.aspx HTTP/1.1Accept: image/gif, image/x-xbitmap, image/jpeg, ...Accept-Language: en-usAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 ...Host: localhostCookie: ASP.NET_SessionId=xshitibm0r1nlpawjvwfzn55Connection: Keep-Alive
The most important line is the first one. It says that we're doing a GET request
for the Default.aspx page in the web root. The URL for this request was"http://localhost/Default.aspx". The only other option besides GET is POST.
There is some confusion about the difference between GET and POST. Some
say that GET is used to get information from the server and POST is used to
send information to the server. Although this describes typical usage it is notstrictly true. GET often sends information to the server through the "query
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 9/28
string". The query string is a list of name-value pairs that are appended to theURL. For example:
GET /Default.aspx?userID=123&password=mydogsname HTTP/1.1
Conversely POST need not send any information to the server and a POST
results in a response being sent from the web server just like GET does. This
POST is equivalent to the GET example above:
POST /Default.aspx HTTP/1.1userID=123password=mydogsname
So the only real difference (as far as HTTP is concerned) is the location in therequest of the name-value parameters. Most web servers set a max size on thequery string though so if large amounts of data need to be sent a POST is
usually used. Also note that POST can still specify a query string after the
page.
The apparent differences (in usage) of GET and POST exist because of the way
a browser initiates them. GET is used when the user types in an URL, clicks a
link, or client-side script navigates the browser. In all these cases the querystring is explicity and manually created. A POST occurs when an HTML FORM
element is "submitted". In this case the browser automatically creates theHTTP header parameters from the INPUT, SELECT and TEXTAREA elements
on the page.
HTTP Response
The response the web server sends to the client is similar, in format, to therequest.
HTTP/1.1 200 OKServer: Microsoft-IIS/5.0Date: Thu, 08 Dec 2005 16:39:39 GMTX-AspNet-Version: 1.1.4322Set-Cookie: ASP.NET_SessionId=xshitibm0r1nlpawjvwfzn55; path=/Cache-Control: privateContent-Type: text/html; charset=utf-8Content-Length: 3579
<html>
<head><title>Home Page</title>
</head><body>
...
The first line let's us know that the request was good, the page was found andno errors occurred. If anything had gone wrong (or a redirection occurred, etc)
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 10/28
we would have seen something else other than "200 OK".
The Content-Type parameter lets us know what kind of data is being returned.In this case we are told to expect plain old HTML. If we had requested animage file we would have seen "image/jpeg", for example.
Content-Length tells the client exactly how much data to expect to be returned.Two CRLFs in a row designate the end of the header and the start of theresponse data (in this case HTML).
Web Session
So if HTTP only sends these simple requests and responses how does a webserver maintain a session for the user? This is not done by keeping a socketconnected to the server. Rather a cookie is used to set and send a session IDnumber. This is the ASP.NET_SessionId cookie in the GET and response
examples. The cookie is set the first time the client makes an HTTP request to
the web server. The client then passes the cookie back to the web server oneach subsequent HTTP request. If the server doesn't receive an HTTP requestfrom a client in a set amount of time (session time-out) the memory reservedfor the session is released and the client will receive a new session ID on thenext request. This usually logs the user out of whatever web application s/hewas signed into.
HTTP Clients
The Web Browser
The web browser (IE, Firefox, etc.) is by far the most common HTTP client, andone that everyone is familiar with. Every time the user clicks a link, types in anURL, or hits refresh an HTTP request occurs. In fact many HTTP requestsusually occur. This is because the browser usually requests an page thatreturns HTML. The HTML is then parsed to discover links to images, script files,stylesheet files, frame or iframe sources, etc. Each time that one of these linksis discovered an entirely separate HTTP request is made to retrieve the item.So, browsing to a page can result in many HTTP requests.
Client-Side Scripting
For an HTTP request to a page that returns HTML it is possible to return code
that will be executed in the browser. This is usually Javascript and is containedbetween <script> tags. Since this code runs inside the browser it is not
possible to access any of the code or memory that exists on the web server(i.e. Session variables). Of course, data that exists on the server side can besent to the client browser in the HTML response. The copy of the data can thenbe accessed by the client-side javascript. It is very important to remember thatclient-side javascript can only have anything happen on the server-side viaHTTP GET or POST.
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 11/28
AJAX
As stated in the Client-Side scripting section an HTTP GET or POST must occur
in order for the browser to get data from or cause anything to happen on theserver. When the browser does either of these (they're the same remember)
the current page is unload and a new page is created from the HTTP HTMLresponse. This results in "browser flash". To avoid this flash and provide whatseems like a more seemless client experience the concept of AJAX wasdeveloped. AJAX stands for Asynchronous Javascript and XML. It allows the javascript coder to invoke special javascript methods that send an HTTPrequest, read the response and provide the data (typically XML) back to themethod callee.
AJAX is often used to invokes a web service method. This involves sending anHTTP POST to the web server that invokes the web service method with the
desired parameter values. The data from the response, typically XML (i.e. theweb service return type is string and is formatted as XML), is then read fromthe response. The XML is then loaded into the browser's XML parser.
AJAX is great for some things but there are number of things to think about.Don't do normal navigation through AJAX because the user loses the ability tobookmark, use the "back" button, etc. You should also deal with the possibilitythat the web server doesn't respond or responds with an HTTP error wheninvoking a web service method with AJAX.
TheWeb Server - IIS
IIS administration is an art unto itself. All modern web servers have come along way from just serving up static web pages. However the interface to the
web server hasn't changed (much). The only thing the web server understandsis HTTP. It receives an HTTP request, does stuff, then returns a response. Thissection will detail the "does stuff" part of the process when an ASP.NET page isrequested.
The first concept that requires a good understanding is the concept of an IISapplication. The best way to understand an IIS application is to think of it like aprocess ("EXE") that is running on the server. This running EXE is then boundto a particular directory on the server. When a page request comes in to theweb server the first thing IIS does is determine what application it needs topass the request off to. This is done by looking at the URL that was specified inthe first line of the HTTP request (see above) and determining the local (e.g."C:\...") directory the page will be found in. The request is then forwarded tothe application that is bound to that directory. The process that is the actualweb server is really nothing more than an application broker for HTTP requests.The only thing of significance the web server does is pass a stream to theapplication that can be used to write the response back to the client.
To illustrate this let's imagine IIS is configured with an application on adirectory - "D:\MyStoreWeb". Since this directory is not under"/Inetpub/wwwroot" it would also be configured as a Virtual Directory. We'll say
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 12/28
that the alias for this directory is configured as "store". Given this the webserver will map the URL "http://serverdnsname/store" to the directory"D:\MyStoreWeb". Note that you can effectively think of an IIS Application andan IIS Virtual Directory as the exact same thing except that a Virtual Directoryis (usually) located outside of the "/Inetpub/wwwroot" directory.
The very first time an HTTP request comes in for any file below"http://serverdnsname/store" (e.g. "http://serverdnsname/store/default.aspx")IIS will start the "store" application. This is equivalent to launching an "EXE" onthe server. This is why the first hit to an application after the server has beenrebooted or "iisreset" has been run is slow. This is also when theSystem.Web.HttpApplication's Application_Start method is
invoked. Usually this is done in the Global.asax file that VS generates. It isimportant to note that static class members properties are global to the entireapplication just like they would be in a full-blown windows process. This meansthat static class members are available to all web request sessions.
You can tell if a folder is an application by opening Internet Services Manager,
finding the folder (or Virtual Directory), right-clicking on it and viewing itsProperties. On the Directory tab there will be a box labelled "Applicationname:". If it is greyed out there is no application. If it is enabled and a name(alias) has been specified there is an application. To remove an application clickthe "Remove" button beside it.
In .NET there is a complicating factor. A "Web.config" file in a web directoryalso starts a new application. Not a full-blown IIS application that you can seein Internet Serives Manager, but enough of one such that new Application andSession objects are created. This causes a problem commonly encounteredwhen you use Visual Studio to create a new "Web Application" project in asubdirectory under an existing IIS application. VS automatically creates both anIIS application as well as new "Web.config" and "Global.asax" files. All of thesemust be removed or application and session information from the "parent"application will be unavailable to the "child" application. In VS 2005 thisproblem goes away because a special web server is used for coding/debuggingand IIS is left alone.
Hopefully this all makes sense because now it gets more complicated. WhatI've stated so far is a simplification of what an IIS application is for the casethat you only have pages that are from a single technology base (like .NET).One of the things that can be configured (individually) for an IIS application iswhat happens for each type of page that is requested. This is done byconfiguring a file extension to be handled by what is called an ISAPI extension.This is done by clicking the "Configuration" button on the application's
"[Virtual] Directory" tab on its "Properties" window. The "App Mappings" tabshows each file extension and what ISAPI dll will handle it. IIS streams thecontents of files not listed here (typically .html, .gif, .jpg, etc.) directly back tothe client. A file request for any of the files listed here is passed to the specifiedISAPI DLL. This DLL then becomes responsible for reading the file (if there evenis one, the file doesn't really have to exist at all!), interpretting the contentsand writing the response. The complication here is that each DLL maintains it'sown application and session objects. So really, a single IIS application can havemany application objects and multiple sessions for a client that accesses pages
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 13/28
of differing technologies. Each ISAPI dll can independently override the IISapplication's session time-out value.
Like a normal windows process an IIS application runs under a windows useraccount. By default this is a low privilege account like the built-in<computername>_IUSR account. In IIS this is configured for the application by
clicking the top "Edit" button in "Directory Security" tab in the appplicatio's"Properties" window. "Windows Authentication" can be used to have webrequests run under a window account that is specified by the client browser.Otherwise the request is considered anonymous and runs under whatever useris configured as the "Account used for anonymous access". A complication hereis .NET. Unless the web request is set to run under "Window Authentication".NET will use a special, low-privilege account called ASPNET. It will ignorewhatever you set as the "Account used for anonymous access" in IIS. To get itto use the account specified here, you need to add the following to yourapplication's "Web.config" file:
<identity
impersonate="true"/>
Enough about IIS applications already! Let's start looking at what happens
when a request for a .NET page (.aspx, .asmx) comes into the web server.
ASP.NET
Loading the Page
So far we have:
1. HTTP request for "/store/Default.aspx" hits the web server (IIS).2. IIS realizes the "store" application handles this request.3. IIS looks at the "App Mappings" configured for the "store" application
and sees that ".aspx" is mapped to "aspnet_isapi.dll".4. IIS passes the request to "aspnet_isapi.dll" and gives it a stream to
write the response back to the client.
What happens next is that "aspnet_isapi.dll" contacts (or starts if this is thefirst .NET request) a process called "aspnet_wp.exe". The request is thenforwarded to this process. Now the hot-potato shuffling of the web request isfinally done. "aspnet_wp.exe", referred to as "ASP.NET" from now on, isactually going to do something!
The first thing that ASP.NET does is look at the location of the requested fileand find the "nearest" Web.config file for it. "Nearest" being the the firstWeb.config it finds as it looks in the directories from the file's directory up tothe IIS application's web root. If the Web.config file has been loaded and a.NET application has been created for it, ASP.NET uses this one, otherwise anew one is created. In .NET this application object is of typeSystem.Web.HttpApplication and is generally accessed via a Page's
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 14/28
Application property.
Next it finds or creates the session object for the web request. This object is of type HttpSessionState and is usually accessed by the Page's Session
property.
The next step is important to understand when debugging. ASP.NET looks inthe application folder's "bin" directory and loads all the DLLs into memory. As itloads each DLL it finds all the namespaces in them and (I'm assuming) storesthem in an easily referenced list. Note that this loading of DLLs only occurswhen the application is starting up (on the first page request).
The next thing ASP.NET checks (OK, I'm sure it's doing a LOT more, but noneof it is relevant here) is if any "HTTP Modules" have been added to theapplication. An HTTP module is a way of intercepting the request at this stage,before ASP.NET goes nuts and starts actually parsing the file, running the codebehind, etc. An HTTP module can take over the response stream and preempt"normal" ASP.NET processing. HTTP modules are added to the application in
the Web.config file, for example:
<httpmodules><add name="WebChartImageStream"
type="Company.Product.Web.Module.HttpModules.ClassName,Company.Product.Web.Module.HttpModules" />
</httpmodules>
The "type" attribute of the add element should be read as:
type="full class name, class namespace"
Anyway, let's ignore HTTP modules or at least pretend that one is notintercepting our web request. The next thing that happens is that ASP.NETactually reads the contents of the requested file. It's going to categorize the fileinto one of two types:
1. A plain, boring, static content page.2. An ASP.NET page with web controls and server-side processing code.
It does this by looking for a line with an @Page directive. If no such line is
found ASP.NET assumes the page has nothing but boring static content andimmediately renders the page contents to the response stream. Otherwise itstarts processing the server side directives. An (ASP.NET 1.1) @Page directive
might look like:
<%@ Page language="c#" Codebehind="Default.aspx.cs"AutoEventWireup="false"
Inherits="Company.Product.Web.Module.DefaultPage" %>
The "language" and "Codebehind" attributes are self-explanatory."AutoEventWireup" can be ignored for now. It's the "Inherits" attribute that isreally important when trying to solve problems. This value specifies the full
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 15/28
namespace-qualified class name that handles this page/file. Everything beforethe last "." is the namespace of the class. Remember the list of namespacesthat ASP.NET loaded from the DLLs in the "bin" directory. ASP.NET will now usethis list to find the DLL that contains the class specified in the "Inherits"attribute. The class can then be instantiated and used to handle the pagerequest. If ASP.NET could not find the namespace, or the class in the
namespace, it will write the following, commonly seen, error to the responsestream:
Parser Error Message: Could not load type'Company.Product.Web.NotDefault'.
So, "could not load type" means "could not find the DLL, the namespace, or theclass". When you get this error first check that the DLL for the page is in theweb app's "bin" directory. Next check that the class name specified in the"Inherits" attribute is correct. If that seems good check the namespacecarefully. Use ILDASM to make sure the DLL in the "bin" really does contain theclass. If all this seems correct then it is probably a dependency issue. A "could
not load type" type error may also occur when the .NET framework cannot finda DLL/namespace/class that the DLL is complaining about references. In thiscase use ILDASM to identify the dependencies and perform the samefile/namespace/class analysis for each dependency. If all else fails make surethe "bin" directory you are looking at is indeed correct for the application -perhaps another IIS application or Web.config file is causing another "bin"directory to be used.
Before going on to parsing the page there is one more thing the frameworkdoes that should be mentioned. This is the creation of the HttpRequest and
HttpResponse objects that are commonly accessed via the Page's
Request and Response properties respectively. The creation of the
HttpRequest includes the populating of the Form (if POST) andQueryString (if "?..." in URL) collections.
Parsing the Page & Creating the Controls
ASP.NET is now ready to start parsing the page's file. A key part tounderstanding this process is to understand that the "Inherits" attribute of the@Page directive specifies a class that must inherit from
System.Web.UI.Page. This class contains a property called Controls that
is of type System.Web.UI.ControlCollection. This collection contains
a list of instances of classes that inherit from System.Web.UI.Control. In
other words, an ASP.NETPage
contains a list of sub-controls.
This Control class has a method called Render that writes HTML back to theresponse stream. So when it comes time (we'll get there!) to send the page'sHTML back to the client ASP.NET iterates through the Control instances andcalls the Render method on each one. Essentially the page doesn't contain anyHTML of it's own - all the HTML is contained in it's sub-controls.
Although it is possible to add controls to a Page's Controls collection
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 16/28
directly this is seldomly done. ASP.NET automatically populates this collectionfor you. To illustrate what it does, let's consider the following example:
<%@ Page language="c#" Codebehind="Default.aspx.cs"AutoEventWireup="false"
Inherits="Company.Product.Web.Module.DefaultPage" %>
<html><head>
<title>Home Page</title></head><body>
<p>Home Page</p><p>User Name:
<asp:textboxid="loginIdTextBox"runat="server"width="50px"></asp:textbox></p>
</body></html>
Since plain old HTML can be rendered directly to the output stream ASP.NETwill parse HTML text blocks into a string that is assigned to an instance of System.Web.UI.LiteralControl. This LiteralControl instance is
then added to the Page's Controls collection. When the parser comes
across an element that has an attribute called "runat" that is set to "server"(referred to as a server-side control) it does not use a LiteralControl.
Instead it looks at the element name to determine what control type toinstantiate. In the case of our example the parser will find the asp:textbox
element. Element names prepended with "asp:" are known by the ASP.NETframework as controls to be found in the System.Web.UI.WebControls
namespace. So ASP.NET will instantiate an instance of the
System.Web.UI.WebControls.TextBox class (notice that ASP.NET iscase-insenstive here). The attributes of a server-side control element areassigned to properties of the class instance.
When ASP.NET is finished parsing our example page the Page's Controls
will contain the following items:
1. LiteralControl instance, .Text = "<html> ... User Name:"
2. System.Web.UI.WebControls.TextBox instance, .ID =
"loginIdTextBox", .Width = "50px"
3. LiteralControl instance, .Text = "</p> ... </html>"
Remember that each Control in the collection has a method called Render.This method renders the control to the response stream (i.e. renders HTMLback to the browser). A LiteralControl simply renders its Text. A
TextBox control obviously does a bit more since it will need to examine its
ID, Width, etc. properties to determine what it should write to the response
stream - e.g. "<input type=text id=loginIdTextBoxstyle=width:50px; ... >".
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 17/28
This Controls collection is now programmatically available in in any of the
Page's event handlers (e.g. Init, Load, etc. more about these later). It
would be possible to iterate through the collection, find the TextBox with and
ID of "loginIdTextBox", cast it to local TextBox variable and manipulate any
of its properties. This is seldomly done though because ASP.NET provides amechanism that allows the controls to be referenced in a much nicer fashion.
This is done by creating a protected class variable of the type implied by the
HTML element ("asp:textbox" =System.Web.UI.WebControls.TextBox). The name of the class variable
must match the ID of the HTML element. After the Controls collection has
been populated ASP.NET iterates through it and sets the protected
appropriate class variable for each Control. LiteralControl instances
are ignored since they don't have an ID. So for our example our "codebehind"class will have the following line:
protected System.Web.UI.WebControls.TextBox loginIdTextBox;
If, for example, we want to set the text of the loginID input box in the Page's
Load event handler we could do the following:
private void Page_Load(object sender, System.EventArgs e){
this.loginIdTextBox.Text = "test";}
Note that ASP.NET does not require a server-side control with an ID to have acorresponding class variable.
Page Lifecycle
Now that we're done the parsing stage we're going to enter the stages that thedeveloper gets to intercept and insert custom code into. First let's recap thestages so far:
1. Load/create .NET Application, Session, Response and Request objectsfor the request.
2. Find page file.3. Find page DLL file.4. Instantiate Page class instance.5. Parse page, populate the Page instance's Controls collection, set the
class control variables.
The next stages are:
6. PreInit7. Init8. Load ViewState9. Load
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 18/28
10. PreRender11. PreRenderComplete12. Render13. Unload
PreInit
Introduced in ASP.NET 2.0 this method can be used to set themesprogrammatically. Note that if the page for this method has a master pageassociated with it the controls for the page will not be available (i.e. will benull) in this stage.
Init
The Init stage begins with the execution of the Page's OnInit method. This
method is virtual so it can be overridden in our Page class derivative.
Load ViewState
To understand what ViewState is and what it is good for we need to rememberthat while the user is looking at an ASPX page nothing about the page is"remembered" on the web server. In other words, after ASP.NET is doneloading a page, setting up all the control objects, and finally writing theresponse stream, all the information about the page/request is released. If theuser causes the page to be POSTed back to the server the entire page object
and all its controls must be entirely rebuilt.
Suppose for example a page contains a server-side data list control with aSortBy property. When the user clicks a column header a POST occurs to set
the SortBy property and thereby render the data list sorted by that column.Now let's say that the user has clicked on the "Name" column. A POST occurs,
the SortBy property is set to "Name" and the response that is written back
contains the data, sorted by name. All is good. Then the user makes somechanges to the filtering criteria for the list, which causes the page to bePOSTed back to the server. The Page object is rebuilt from scratch, including
the controls. This means that the SortBy property will be set to whatever its
default value is. The "Name" sorting has been lost.
In pre-ViewState days (ASP) we would have solved this problem by storing thesort clause in a POST-able HTML element like INPUT (type="hidden"). We
would then have set the value of this element beforePOST
ing, read the value
out of the Request.Form object and manually set the (equivalent of the)
SortBy property. Saving the state of all these properties was time-consuming
and laborious.
What ViewState is then is a mechanism to have control propertiesautomatically be saved and restored across HTTP POSTs. So the control writer,
instead of reading/writing a property from/to a class variable, like so:
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 19/28
public string SortBy{
get{
return this.sortBy;}set{
this.sortBy = value;}
}
would read/write the value from/to ViewState as follows:
public string SortBy{
get{
return this.ViewState["sortby"].ToString();
}set{
this.ViewState["sortby"] = value;}
}
When using the ViewState property of the page values are stored across
HTTP POSTs. An important point to stress is that ASP.NET loads information
from ViewState and sets the appropriate controls' properties between the Init
and Load stages. So if you set a control property in the Init stage it may get
overwritten by a ViewState value and therefore be different in the Load stage.
If you're curious to know how ASP.NET does the magic behind ViewState readon. Otherwise skip to the next section.
In order to save the ViewState information that has been set ASP.NET writes itto the response stream. It does this by adding an HTML INPUT element
(type="hidden") to the page. This element is given the name "__VIEWSTATE".The Page's ViewState object is then serialized as a string of
"control.property= value" pairs(e.g."datalist1.sortby=name&datalist1.userid=123"). This string is then base64-encrypted and given as the value for the "__VIEWSTATE" element. Whenthe page is POSTed back this "__VIEWSTATE" is POSTed with it. ASP.NET can
then retreive its value, decrypt it and set the appropriate control properties.
Load
The Init stage begins with the execution of the Page's OnLoad method. This
method is virtual so it can be overridden in our Page class derivative. However
it is more common, and better practice, to set the Page's Load event handler
in the OnInit method. When creating a new page Visual Studio does this for
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 20/28
you and names the event handler method "Page_Load". This method is therecommended place for doing normal page/control initialization.
PreRender
Overriding thePage.OnPreRender
method or handling thePreRender
event allows for code to be executed just before the page/control is about to berendered.
PreRenderComplete
This method was introduced in ASP.NET 2.0. It's purpose is to provide an eventhandler that can be used to do work immediately after asynchronous eventshave finished. See Asynchronous Calls in a Web Page for more information.
Render
This is the stage where the page and all its sub-controls are rendered to theresponse stream. For a page this method is implemented by the ASP.NETframework and does all the work for you. For a custom control you will need tooverride and implement the Render method to have your control render the
appropriate HTML.
Unload
Now everything about the HTTP request is released starting with the ASP.NETpage and controls and going all the up the stack to the ISAPI extension andpossibly even the socket. Nothing about the request remains except a line inthe web server's log file.
Conclusion
At this point your brain is recoiling from knowing WAY too much about anASP.NET page request. If you actually managed to read the whole documentthrough at once you will probably be suffering from information overload.That's OK, just refer to the document as needed. However, if you're going to bedoing custom web control or web framework development I encourage you toknow as much about this stuff as possible. Reread as necessary until youunderstand it all.
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 21/28
This article describes how the IIS process clients requests and
responses.
Buy proven .NET Trainings on www.ITFunda.Com (Adv)
I ntroduction When request come from client to the server a lot of operation is performed
before sending response to the client. This is all about how IIS Process the
request. Here I am not going to describe the Page Life Cycle and there events,
this article is all about the operation of IIS Level. Before we start with the
actual details, let¶s start from the beginning so that each and everyone
understand it's details easily. Please provide your valuable feedback and
suggestion to improve this article.
What is Web Server ?
When we run our ASP.NET Web Application from visual studio IDE, VSIntegrated ASP.NET Engine is responsible to execute all kind of asp.netrequests and responses. The process name is "WebDev.WebServer.Exe" which actually takw care of all request and response of an web applicationwhich is running from Visual Studio IDE.
Now, the name ³Web Server´ come into picture when we want to host theapplication on a centralized location and wanted to access from many locations.Web server is responsible for handle all the requests that are coming fromclients, process them and provide the responses.
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 22/28
What is II S ?
II S ( I nternet I nformation Server) is one of the most powerful web servers from
Microsoft that is used to host your ASP.NET Web application. IIS has it's own
ASP.NET Process Engine to handle the ASP.NET request. So, when a request
comes from client to server, IIS takes that request and process it and send
response back to clients.
Request Processing :
Hope, till now it¶s clear to you that what is Web server and IIS is and what is
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 23/28
the use of them. Now let¶s have a look how they do things internally. Before wemove ahead, you have to know about two main concepts
1. Worker Process 2. Application Pool
Worker Process: Worker Process (w3w p.exe) runs the ASP.Net application inIIS. This process is responsible to manage all the request and response thatare coming from client system. All the ASP.Net functionality runs under thescope of worker process. When a request comes to the server from a clientworker process is responsible to generate the request and response. In a singleword we can say worker process is the heart of ASP.NET Web Application whichruns on IIS.
Application Pool: Application pool is the container of workerprocess. Application pools is used to separate sets of IIS worker processes thatshare the same configuration. Application pools enables a better security,
reliability, and availability for any web application. The worker process servesas the process boundary that separates each application pool so that when oneworker process or application is having an issue or recycles, other applicationsor worker processes are not affected. This makes sure that a particular webapplication doesn't not impact other web application as they they areconfigured into different application pools.
Application Pool with multiple worker process is called ³Web Garden´ .
Now, I have covered all the basic stuff like Web server, Application Pool,Worker process. Now let¶s have look how IIS process the request when a newrequest comes up from client.
If we look into the IIS 6.0 Architecture, we can divided them into Two Layer
1. Kernel Mode 2. User Mode
Now, Kernel mode is introduced with IIS 6.0, which contains theHTTP.SYS. So whenever a request comes from Client to Server, it will hit
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 24/28
HTT P.SYS First.
Now, HTTP.SYS is Responsible for pass the request to particular Application
pool. Now here is one question, H ow HTT P.SYS comes to know w here to send
the request? This is not a random pickup. Whenever we creates a new
Application Pool, the ID of the Application Pool is being generated and it¶s
registered with the HTTP.SYS. So whenever HTTP.SYS Received the request
from any web application, it checks for the Application Pool and based on the
application pool it send the request.
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 25/28
So, this was the first steps of IIS Request Processing.
Till now, Client Requested for some information and request came to the Kernellevel of IIS means at HTTP.SYS. HTTP.SYS has been identified the name of theapplication pool where to send. Now, let¶s see how this request moves fromHTTP.SYS to Application Pool.
In User Level of IIS, we have Web Admin Services (WAS) which takes therequest from HTTP.SYS and pass it to the respective application pool.
When Application pool receive the request, it simply pass the request to worker
process (w3wp.exe) . The worker process ³w3w p.exe´ looks up the URL of the
request in order to load the correct ISAPI extension. ISAPI extensions are the
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 26/28
IIS way to handle requests for different resources. Once ASP.NET is installed, it
installs its own ISAPI extension (aspnet_isapi.dll) and adds the mapping into
IIS.
Note : Sometimes if we install IIS after installing asp.net, we need to register
the extension with IIS using aspnet_regiis command.
When Worker process loads the aspnet_isapi.dll , it start an HTTPRuntime,
which is the entry point of an application. HTT PRuntime is a class which calls
the ProcessRequest method to start Processing.
When this methods called, a new instance of HTTPC ontext is been
created. Which is accessible using HTTPContext.Current Properties. This
object still remains alive during life time of object request. Using
HttpContext.Current we can access some other objects like Request, Response,
Session etc.
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 27/28
After that HttpRuntime load an H ttpApplication object with the help
of H ttpApplicationFactory class.. Each and every request should pass through
the corresponding HTTPModule to reach to HTTPHandler, this list of module are
configured by the HTTPApplication.
Now, the concept comes called ³HTTPPipeline´ . It is called a pipeline because
it contains a set of HttpModules ( For Both Web.config and Machine.config
level) that intercept the request on its way to the HttpHandler. HTTPModules
are classes that have access to the incoming request. We can also create our
own HTTPModule if we need to handle anything during upcoming request and
response.
8/8/2019 ASP Request
http://slidepdf.com/reader/full/asp-request 28/28
HTTP Handlers are the endpoints in the HTTP pipeline. All request that arepassing through the HTTPModule should reached to HTTPHandler. Then HTTPHandler generates the output for the requested resource. So, when werequesting for any aspx web pages, it returns the corresponding HTML output.
All the request now passes from httpModule to respective HTTPHandler thenmethod and the ASP.NET Page life cycle starts. This ends the IIS Requestprocessing and start the ASP.NET Page Lifecycle.
Conclusion
When client request for some information from a web server, request firstreaches to HTTP.SYS of IIS. HTTP.SYS then send the request torespective Application Pool. Application Pool then forward the request toworker process to load the ISAPI Extension which will create an HTTPRuntimeObject to Process the request via HTTPModule and HTTPHanlder. After that theASP.NET Page LifeCycle events starts.
This was just overview of IIS Request Processing to let Beginner¶s know how
the request get processed in backend. If you want to learn in details pleasecheck the link for Reference and further Study section.
Recommended