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

Web Application Basics

Posted by Ravi Varma Thumati on July 15, 2009

  • Interpret HTTP requests
  • Use the .NET Framework to make HTTP requests without a browser
  • Interpret HTML
  • Work with IIS
  • Produce dynamic Web content without using ASP.NET yet

This chapter covers the fundamentals of building a Web-based application. Unlike the development of most desktop applications, in which many of the parts are available locally (as components on the user’s hard disk drive), developing a Web application requires getting software parts to work over a widely distributed network using a disconnected protocol. The technologies underlying ASP.NET have been around for a long time. Of course, ASP.NET makes use of this technology underneath, while making it very approachable at the same time.

Although ASP.NET makes developing Web applications far easier than ever before, you must have a solid understanding of how the plumbing is actually working during the development of an ASP.NET application. A good example of such a time might be when you’re tracking down a stray HyperText Transfer Protocol (HTTP) request or trying to figure out why a section of your page is appearing in the wrong font within a client’s browser. Another such time might occur while you’re writing a custom control for a Web page. Custom controls often require that the rendering code be written manually. That is, you must carefully ensure that the HyperText Markup Language (HTML) tags emitted by your control occur in exactly the right order. For that, you need to understand HTML.

This chapter covers three things necessary to allow you to work with ASP.NET:

  • How HTTP requests work
  • How HTML works
  • How HTTP requests are handled on the Microsoft production Web server platform,Internet Information Services (IIS)

Understanding these three technologies underlying ASP.NET frames the rest of the system. As you study ASP.NET, these pieces will undoubtedly fall into place.

HTTP Requests

The communication mechanism by which Web browsers talk to Web sites is named as the Hyper-Text Transfer Protocol (HTTP); The World Wide Web as we know it today began as a research project at CERN in Switzerland. In those days, the notion of hypertext—documents linked together arbitrarily—was becoming increasingly popular. Applications such as Hypercard from Apple Computer Inc. introduced hypertext applications to a wider audience. Now, if documents could be linked over a network, which would revolutionize publishing. That’s the reason for the HyperText Transfer Protocol, which lies on top of TCP/IP as an application layer.

In its original form, HTTP was meant to transfer hypertext documents. That is, it was originally intended simply to link documents together without consideration for anything like the Web-based user interfaces that are the staple of modern Web sites. The earliest versions of HTTP supported a single GET request to fetch the named resource. It then became the server’s job to send the fi le as a stream of text. After the response arrived at the client’s browser, the connection terminated. The earliest versions of HTTP supported only transfer of text streams and did not support any other sort of data transfer.

The first formal specification for HTTP found itself in version 1.0 and was published in the mid-1990s. HTTP 1.0 added support for more complex messaging beyond a simple text transfer protocol. HTTP grew to support different media (specifi ed by the Multipurpose Internet Mail Extensions). The current version of HTTP is version 1.1.

As a connection protocol, HTTP is built around several basic commands. The most important ones we’ll see in developing ASP.NET applications are GET, HEAD, and POST.

GET retrieves the information identified by the Uniform Resource Identifier (URI) specified by the request. The HEAD command retrieves only the header information identified by the URI specified by the request (that is, it does not return a message body). You use the POST method to make a request to the server that may cause side effects, such as sending information to the server for it to process. You make most initial contacts to a page using a GET command, and you commonly handle subsequent interactions with POST commands.

HTTP Requests from a Browser

As an example, look at the request that is sent from a browser to fetch the helloworld.htm resource from the virtual directory aspnet2sbs running on localhost. (I’ll cover the concept of a “virtual directory” later, but for now just imagine it as the location of a Web application everyone can access.) Here is a sample (fictitious) HTTP server request:

GET /aspnet2sbs/helloworld.htm HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, … , */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; … .NET CLR 3.0.04506.30)

Host: localhost:80

Connection: Keep-Alive

If you would like to see the actual data going back and forth, there are several TCP monitors available. A good one is TcpTrace, found at You’ll find instructions for its use there as well. For simple TCP tracing, you may also use TELNET to send GET Requests to the server, which we’ll look at now.

To send an HTTP request to a server using TELNET, follow these steps:

  • Open the Visual Studio command prompt. To do this, from the Start button select All Programs, Microsoft Visual Studio 2008, Visual Studio Tools, and then finally Microsoft Visual Studio 2008 Command Prompt. The command prompt tool should appear.
  • At the prompt, type the following:

TELNET localhost 80

  • After the TELNET client connects, type the following GET command (assuming you have a virtual directory named aspnet2sbs on your machine, containing a fi le named HelloWorld.HTM, or you may also use a fi le already installed with IIS, such as postinfo.html):

GET //aspnet2sbs/helloworld.htm

  • You should see the file’s contents returned to the command line.

When a browser wants to make an HTTP request, it needs to process the HTTP request including the URI along with other information (such as header information and the requested file name). The header information in the request includes details about the operating environment of the browser and some other information that is often useful to the server.

When the server receives this request, it returns the requested resource as a text stream. The browser then parses it and formats the contents. The following shows the response provided by the server when asked for the HelloWorld.htm fi le. Normally, you don’t see all the header information when viewing the resource through a browser. A good TCP tracing utility will show it to you. When we look at ASP.Net tracing facilities later on, this header information will be visible.

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.1

X-Powered-By: ASP.NET

Date: Thu, 01 Nov 2007 23:44:04 GMT

Content-Type: text/html

Accept-Ranges: bytes

Last-Modified: Mon, 22 Oct 2007 21:54:20 GMT

ETag: “04e9ace185fc51:bb6”

Content-Length: 130



<h1> Hello World </h1>

Nothing really showing here yet, except some HTML…



The first line indicates the protocol (HTTP, version 1.1) and the return code (200, meaning “OK”). The rest of the response (until the first <html> tag) is information about the time of the request, the last time the file was modified, and what kind of content is provided. This information will be useful later when we examine such issues as page caching and detecting browser capabilities. The content following the response header information is literally the HTML file sent back by the server.

Making HTTP Requests without a Browser

In addition to being a framework for building Web applications, the .NET development environment includes classes for making HTTP requests in the raw. The WebRequest class includes a member named GetResponse that will send a request to the address specified by the Uniform Resource Locator (URL). To get a feeling as to how to make direct requests to a Web server without a browser, try compiling and then running this short program that fetches the home page for

Build a simple HTTP requestor

  • Start Visual Studio.NET. Select New, Project from the main menu. In the New Project dialog box, select a Console application and name it WebRequestorApp, as shown in the following graphic.


Visual Studio will generate a blank Console program for you.

  • Add the code necessary to make a Web request to the program. Visual Studio places the entry point of the Console application into a fi le named Program.cs. (This fi le is the code that shows up in the code window by default.) The code you add for making a Web request is shown in bold in the following lines of code:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Net;

using System.IO;

namespace WebRequestorApp


class Program


static void Main(string[] args)


WebRequest req =



WebResponse resp = req.GetResponse();

StreamReader reader =

new StreamReader(resp.GetResponseStream(),






  • Run the application. You may do this by choosing Debug, Start Without Debugging from the main menu. Visual Studio will start up a Console for you and run the program. After a couple of moments, you’ll see some HTML spewed to your screen.

Of course, the HTML isn’t meant for human consumption. That’s what a browser is for. However, this example does show the fundamentals of making a Web request—and you can see exactly what comes back in the response.

In this case, the request sent to the server is much smaller. WebRequest.GetResponse doesn’t include as much information in the request—just the requisite GET followed by the URI, host information, and connection type:

GET /aspnet2sbs/helloworld.htm HTTP/1.1

Host: localhost:80

Connection: Keep-Alive

The fundamental jobs of most browsers are (1) to package a request and send it to the server represented in the URI and (2) to receive the response from the server and render it in a useful way. The response usually comes back as a text stream marked up using HTML tags. Let’s take a look at HTML.

HyperText Markup Language (HTML)

In the course of looking at ASP.NET, we’ll see quite a bit of HTML. Most of it will be generated by the ASP.NET server-side controls. However, it’s important to understand HTML because you may want to write your own server-side control from scratch, and at other times you may need to tweak or debug the output of your ASP.NET application.

Most HTTP requests result in a stream of text coming back to the program issuing the request. The world has pretty much agreed that HTML is the language for formatting documents, and all browsers understand HTML.

The first release of HTML worth using was version 2.0. Version 3.2 introduced new features, such as tables, text fl ow, applets, and superscripts and subscripts, while providing backward compatibility with the existing HTML 2.0 Standard.

The bottom line is that given a competent browser and well-structured HTML, you had the beginnings of a user interface development technology. And because HTML was understood by browsers running on a variety of platforms, the door was open for implementing a worldwide interactive computing platform. The other key that made this happen (besides a mature version of HTML) was the ability of servers to adapt their output to accommodate the requests of specifi c users at runtime.

For example, the following HTML stream will render an HTML page containing a button and a combo box fi lled with options. (This fi le is named SelectNoForm.htm in the collection of examples for this chapter.)



<h2>Hello there. What’s your favorite .NET feature?</h2>

<select name=’Feature’>

<option> Type-Safety</option>

<option> Garbage collection</option>

<option> Multiple syntaxes</option>

<option> Code Access Security</option>

<option> Simpler threading</option>

<option> Versioning purgatory</option>



<input name=’Lookup’ value=’Lookup’></input>




This is a static page. Even though it has a combo box and a button, they don’t do anything worthwhile. You can pull down the combo box and work with it inside the browser. You can click the button, but all the action happens locally. That’s because the server on the other end needs to support dynamic content.

Dynamic Content

The earliest Web sites were built primarily using static HTML pages. That is, you could surf to some page somewhere and read the HTML document living there. While at that time being able to do this was pretty amazing, HTML eventually evolved to be capable of much more than simply formatting text.

For example, HTML includes tags such as <select></select> that browsers interpret as a combo box, called a drop-down list in ASP.NET. The fi rst tag, <select>, is called the opening tag while the second, </select>, is called the closing tag. Tags can contain other tags, which you saw with the <option></option> tags that provide content for the drop-down list. Tags also can have attributes, which are used to modify or tailor the behavior of the tag. Various attributes applied to the <input></input> tag cause browsers to draw text boxes and buttons. HTML provides a special tag, the form, that groups other tags designed to return information to the server for processing.

HTML Forms

HTML includes the <form></form> opening and closing tags for notifying the browser that a section of HTML includes tags representing controls the user will interact with to eventually return information to the server. This is how you specify a Web document will be handling input from the end user (not just output). The contents of the form, which is to say the data contained in the input controls, will be “posted back” to the server for processing. It’s common to combine the words and call this action a postback. This is why the typical HTTP use case for an HTML document is GET, to initially retrieve the document, and then POST (or a modifi ed form of GET), to return data to the server, if any.

The <form> tag usually sandwiches a set of tags specifying user input controls. The following shows the same feature selection page, but with the form tag added (the code is from the file named SelectFeature2.htm in the book’s accompanying examples):



<form action=”http://localhost/HttpHandlers/selectfeature.htm&#8221;


<h2>Hello there. What’s your favorite .NET feature?</h2>

<select name=’Feature’>

<option> Type-Safety</option>

<option> Garbage collection</option>

<option> Multiple syntaxes</option>

<option> Code Access Security</option>

<option> Simpler threading</option>

<option> Versioning purgatory</option>



<input type=submit name=’Lookup’ value=’Lookup’></input>





If you’d like to see this work right away, type this into a file named SelectFeature2.htm and save it into the directory c:\inetpub\wwwroot and surf to the fi le by typing http://localhost/selectfeature2.htm into your browser’s navigation field.

The form tag includes several attributes that you may set to control how the page behaves. In the preceding example, notice the <form> tag sets the action attribute, which indicates the server that will receive the form’s contents. In its absence, the current document URL will be used.

The other attribute used in the HTML is the method attribute. The method attribute specifies the HTTP method used when submitting the form and therefore dictates how the form data are returned to the server. The method employed in the example is GET because it’s the first request to the server.

Assuming you select the last option (“Versioning purgatory”) and then click Lookup, the form’s GET method causes the form’s input control contents to be appended to the URL, like so:


This modifi ed URL, often called a query string, is then sent to the server.

The form’s POST method causes the form contents to be sent to the server in the body of a returned HTTP packet, as you see here:

POST /SelectFeature2.htm HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, … , */*

Accept-Language: en-us

Content-Type: application/x-www-form-urlencoded

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; … .NET CLR 3.0.04506.30)

Host: localhost:80

Content-Length: 42

Connection: Keep-Alive

Cache-Control: no-cache


Adding the form tag to the body of the document gets us part of the way to having an HTTP application that actually interacts with a user. Now we need a little more support on the server end. When you click the Lookup button, the browser will actually force another round-trip back to the server (although in this case, it will only perform an HTTP GET command to refetch the document since we specifi ed this in the form’s method attribute).

At this point, a normal HTTP GET command will only return the document. For a truly interactive environment, the server on the other end needs to modify the content as requests go back and forth between the browser and the server.

For example, imagine that the user does an initial GET for the resource, selects a feature from the combo box, and then clicks the Lookup button. For an interactive application to work, the browser will need to make a second round-trip to the server with a new request that includes the user’s inputs for processing. The server will need to examine the request coming from the browser and fi gure out what to do about it. This is where the server begins to play a much more active role. Depending on the platform involved, there are several different ways in which a server can handle the postback—through such programs as the Common Gateway Interface or Internet Information Services.

Common Gateway Interface (Very Retro)

The earliest Web servers supporting “dynamic Web content” did so through the Common Gateway Interface (CGI). CGI was the earliest standard for building Web servers. CGI programs execute in real time and change their output based on the state of the application and the requests coming in. Each request coming into a Web server running CGI runs a separate instance of a program to respond. The application can run any sort of operation, including looking up data in a database, accepting credit card numbers, and sending out formatted information.

The Microsoft Platform as a Web Server

On the Microsoft platform, it’s too expensive to start up a new process for each request (à la CGI). Microsoft’s solution is to have a single daemon process (which in Windows we call a service ) monitor port 80 for incoming network packets and load DLLs to handle separate requests when the content needs to change. Microsoft’s standard Web platform is based on the Internet Information Services (IIS).

Note: When you create and edit Web applications using Visual Studio 2008, you can load them “from the fi le system” and “from IIS” (as well as by a few other means). If you load your Web application using IIS, then IIS acts as the Web server as you’d expect. But what about loading a Web application from the fi le system? What application is serving HTML (or ASP.NET) documents in that case? As it happens, starting with Visual Studio 2005, a special development Web server can be used to simplify debugging and administration. Based on a Web server named Cassini, it can serve HTML and ASP.NET pages just as effectively as IIS for development purposes. However, keep in mind that for robustness and security IIS is Microsoft’s professional grade Web server and is the intended target for your ASP.NET Web application.

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 monitor port 80 (typically) 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, IIS 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:

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, 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 refer to a virtual directory.

IIS divides its working space into multiple virtual directories. Each virtual directory typically refers to a single application and is used to map a physical directory on your server’s hard drive to an Internet URL. Using virtual directories, one per application, 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. The configuration parameters also include mappings between fi le extensions and optionally configured IIS extension DLLs, called ISAPI DLLs (ISAPI stands for Internet Services Application Programming Interface). (ASP.NET itself is handled by one of these ISAPI DLLs!)

While it’s not critical for initially writing ASP.NET applications, knowing a bit about how IIS works is tremendously important when you need to fully debug, test, and deploy your Web application. The built-in Visual Studio Web server (Cassini) is fine for most things, but it lacks much that IIS offers. True ASP.NET developers understand this and often become quite adept at administering IIS. If you want to get going writing applications straightaway, you may skip the section on IIS, but we’ll be looking at various aspects of IIS operations and administration throughout the book. To begin, here‘s a brief look at ISAPI and how it extends IIS.

The user interface to IIS is available through the Control Panel. To get a feel for how to administer IIS, 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 in a real Web application. IIS 5.x, 6.0, and 7.0 works similarly as far as dividing the server’s application space into virtual directories. IIS 6.0 and 7.0 include many other features such as application isolation and recycling to help control runaway requests and limit memory consumption if something untoward happens during a request.

Running IIS


  • Run IIS. To get to IIS, fi rst go to Administrative Tools. On Windows Vista, you can do this through the Control Panel. Run Internet Information Services. You should see the IIS user interface on your screen. The following graphics show the Features View and the Content View—both running under Vista.


On the left-side of the screen is an expandable tree showing the Web sites and virtual directories available through IIS on your machine. IIS 5.x and 6.0 show the virtual directories on the left pane, with the directory contents on the right-side. The IIS 7 management console includes two views: the Features View and the Content View. The Features View includes various icons for managing specific aspects of IIS for the item selected from the list on the left side. The Content View shows the files contained within the selected item. Let’s explore the Features View and the Content View.

  • View configuration for a specific virtual directory. The Features View lets you see how a specific virtual directory is configured. To find out more about the directory’s configuration, try clicking on the various icons in the Features View. For example, to see how IIS figures out the correct default fi le to show (in the absence of a specific file extension), click on the Default Document icon. You’ll see the list of default file names that IIS will try to load:

You can configure a number of features within IIS, and they’re all represented by the icons presented in the Features View. The feature set 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). Before discussing how IIS 7.0 handles ASP.NET requests, let’s take a look at how IIS 7.0 handles other types of requests for the sake of completeness.


  • View module mappings for a virtual directory. Static fi le 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 specifi c handlers. As you’ll see in a moment, IIS 7.0 prefers to handle most requests via managed code. For those developers who wish to write native code, IIS 7.0 includes a new C++/native core server API. This new API works with IIS 7.0 through the IsapiModule to expose classic ISAPI extension DLLs. Another module, the IsapiFilterModule, replaces the traditional ISAPI fi lter API from earlier releases of IIS. To view the IIS 7.0 module mappings, click on the Module Mappings icon within the Features View. You should see a listing of the IIS 7.0 modules that intercept requests:


  • View fi le mappings for a virtual directory. For those applications that handle requests using managed code, IIS pipes them through the handlers listed on the Handler Mappings page. To view the fi le mappings for a specifi c virtual directory, click the Handler Mappings icon within the Features View. IIS responds by listing the fi le mappings for the directory:


These mappings tell IIS how to handle specifi c requests. As you can see, most requests are handled through managed code via ASP.NET. Notice that at the top of the list, there’s a handler for classic ASP fi les, named ASPClassic. This handler takes care of requests bearing the .ASP fi le extension (earlier versions of IIS piped these requests directly to the ASP.DLL handler).

Note: If for some reason you fi nd yourself with a need to run classic ASP, note that IIS 7.0 does not install ASPClassic by default—you must add this feature deliberately. In the Control Panel, select Programs and Features from the list. Then select Turn Windows Features On and Off. Select Internet Information Services from the dialog box that appears. Expand the World Wide Web Services node, and then the Application Development Features node. Check the ASP box to install classic ASP handling, as shown here:



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: