……………………………………………….Expertise in .NET Technologies

How Web Servers Execute ASP.NET Files

Posted by Ravi Varma Thumati on September 9, 2009

When a site visitor requests a Web page address, the browser contacts the Web server specified in the address URL and makes a request for the page by formulating a HTTP request, which is sent to the Web server. The Web server on receiving the request determines the file type requested and passes processing to the appropriate handler.ASP.NET files are compiled, if necessary, into .NET Page classes and then executed, with the results sent to the client’s browser.

Compilation means that on first load ASP.NET applications take longer to display than previous versions of ASP, but once compiled they are noticeably faster.

Client-Server Interaction

ASP.NET applications are a mixture of client side markup and code, and server side processing. When an ASP.NET Web form page is downloaded to the visitor’s Web browser, additional code is included to previous ASP versions. This extra code enables richer form functionality, including server and client side events, validation, and the ability to maintain form value state. The server determines the visitor’s browser type and sends markup to match the browser’s abilities.

Some client interactions will be dealt with within the visitor’s browser, while others will require information to be posted to the server for processing and the altered page returned.

As form responses are received, the form values are maintained in a new facility of ASP.NET “State Bags” and are compressed into a hidden form element containing the page “Viewstate”. This allows the form elements that the visitor has interacted with to maintain the same values as when the page was submitted. As illustrated in Figure 1.1, the browser can request information from and send information to the server using two HTTP methods, GET and POST.

 Figure 1.1 How the Client and Server Communicate pages execution_clientside  

GET is simply the method in which the browser compiles a URL. A typical URL in this context will consist of a protocol, for example, HTTP for hypertext or FTP for file transfer, a fully qualified domain name, such as “” followed by a path, such as “/articles/”, and then the page to GET, such as “default.aspx” or “index.html”. You can add information as parameters, called a QueryString. This is separated from the rest of the URL with a question mark (?), and the parameters take the form of keywords and values such as “keyword=value,” for example, “article=5”. Multiple parameters are separated with ampersands, so if we have two parameters, x and y, they would be presented like x=5&y=10. So, a full GET request including QueryString could be


When a browser sends information using the POST method, the parameters are compiled in the same way. But sent separately in the HTTP header, and so are not seen in the URL portion of the browser like GET requests are. Forms often use POST for this very reason.

Other information goes into the HTTP request header, such as what browser the user is using and so on. As you will see later, your ASP can pick up this header information and the QueryString parameter values.

Server-Side Processing

When the server receives this request, it will find the page that was requested using the path information specified, and the relevant system will process the page. In the case of Classic ASP, there was not much to this process, although a certain amount of caching happened. As you will see in Figure 1.2, with ASP.NET the process is a fair amount more involved but provides for much faster processing and delivery.

Figure 1.2 the Server-Side Compilation and Delivery Process pages execution_serverside 

The server will process the ASP.NET page using a special .dll especially for ASP.NET. As with previous versions of ASP, ASP.NET has a large collection of objects that deal with processing certain functions such as the HTTP request, databases, the file system, and forming the response.

When the response is complete, it is flushed back out to the user’s browser, usually as HTML but not necessarily, and the browser renders this page as it arrives as the page on screen.

Compiling and Delivering ASP.NET Pages

The process of compiling and delivering ASP.NET pages goes through the following stages:


  • IIS matches the URL in the request against a file on the physical file system (hard disk) by translating the virtual path (for example, /site/index.aspx) into a path relative to the site’s Web root (for example, d:\domains\thisSite\wwwroot\site\index.aspx).
  • Once the file is found, the file extension (.aspx) is matched against a list of known file types for either sending on to the visitor or for processing.
  • If this is first visit to the page since the file was last changed, the ASP code is compiled into an assembly using the Common Language Runtime compiler, into MSIL, and then into machine-specific binary code for execution.
  • The binary code is a .NET class .dll and is stored in a temporary location.
  • Next time the page is requested the server will check to see if the code has changed. If the code is the same, then the compilation step is skipped and the previously compiled class code is executed; otherwise, the class is deleted and recompiled from the new source.
  • The compiled code is executed and the request values are interpreted, such as form input fields or URL parameters.
  • If the developer has used Web forms, then the server can detect what software the visitor is using and render pages that are tailored to the visitor’s requirements, for example, returning Netscape specific code, or Wireless Markup Language (WML) code for mobiles.
  • Any results are delivered back to the visitor’s Web browser.
  • Form elements are converted into client side markup and script, HTML and JavaScript for Web browsers, and WML and WMLScript for mobiles.

Collecting Data Using HTML Forms

 HTML uses the Hypertext Transfer Protocol (HTTP) to transmit Web pages. When you enter a URL of a page in your browser, it sends an HTTP message to the server, requesting the desired page. This message is typically known as the Request message. If the desired page has a *.html or *.htm extension, the Web server simply retrieves the page from the server’s disk and sends it back to your computer (client) via a new HTTP message, known as the Response message. It is your browser that interprets the mark-up codes in the Response object and presents the page on your monitor.

In an HTML document, you can use an HTML form element to collect data from the user. Typically, other HTML elements like buttons, checkboxes, or textboxes are imbedded in an HTML form. It also provides an HTML Submit button in the form. With one click of the Submit button, the browser packages the user’s given data in a Request message and then sends it to the server. An HTTP message has two parts: the HTTP Header and the HTTP Body. Thus, the browser can package the user-given data in the Request object in one of two ways. It may augment the URL with the name-value pairs of submitted data.

Alternatively, it can package the submitted data inside the body part of the Request message. Which of the alternative methods will it use? The answer depends on the specifications in the HTML form element. A typical form tag is shown in Figure 3.1.The Method parameter is used to specify the mode of data transmission. If it is “Get”, the browser sends the data in the header section of the HTTP message. If it is “Post”, the data are sent in the body section. The Action parameter can be used to request a specified html or other documents like .asp or .aspx files.

Figure 3.1 Major Parameters (Attributes) of an HTML Form Element pages execution_clientside1


To demonstrate the data-passing mechanism using the Get method, we will present a simple example. Consider the Sample1.html document which included a HTML form named myForm. It has a Submit button, and a textbox. The user will enter a hobby and click the Submit button. On click of the Submit button, the browser will request the html document named Sample1.html and pass the submitted data to the server in the augmented URL.

In this particular example, the browser will actually request the same html document (named Sample1.html). Figure 3.3 shows the URL of the requested form as submitted by the browser to the Web server. You will see that the browser has augmented the URL, and the new URL is /…./sample1.html?txtHobby=Fishing. That means the data are submitted as a name=value pair in the URL itself. The first such pair is prefixed with a question mark.




 <form Action=”Sample1.html” Method=”Get”>

Your Hobby? <input size=10>

<input Value=”Submit”>




If we specify Method=“Post” in the form tag, the data are packaged as namevalue pairs in the body section of the HTTP message. Unfortunately, we cannot have a peak inside the body section, and thus it cannot be shown. Once the data are submitted, what do we do with it? Well, that is where the server-side scripting comes into the scenario.

 Server-Side Processing in ASP.NET

An ASP.NET file has an *.aspx extension. Typically, it contains HTML elements, server-side codes and client-side codes. As shown in Figure 3.4, when a user requests an ASPX page, the server retrieves it from the disk and then sends it to the ASPX Engine for further processing. The ASPX Engine compiles the server side codes and generates the page class file. It then instantiates the class files and executes the instructions to develop the response object. During the execution stage, the system follows the programmatic instructions (in the server-side code) to process the data submitted by the user. Finally, the server transmits the response object to the client. In short, the major steps in processing a request for an ASPX page are as follows:

  • The server receives a request for a desired ASPX page.
  • The server locates the page in the disk.
  • The server gives the page to the ASP.NET Engine.
  • The ASP.NET Engine compiles the page and generates the page class. If the class had already been loaded, it simply provides a thread to the running class instead of regenerating the class. During compilation, it may require other code classes, such as code-behind classes and component classes. These are assembled during this step.
  • The ASP.NET instantiates the class performs necessary processing, and it generates the Response object.
  • The Web server then sends the Response object to the client.

 Figure 3.4 Major Steps in Serving an ASPX Page pages execution_serverside1


One Response to “How Web Servers Execute ASP.NET Files”

  1. It’s rare to get a specialist in whom you may have some trust. In the world in the present day, nobody genuinely cares about showing others exactly how in this subject matter. How fortuitous I am to have actually found a wonderful blog as this. It is people like you exactly who make a genuine difference nowadays through the concepts they reveal.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: