Microsoft ASP.

NET 4 Step by Step

Part I

Fundamentals
In this part:
Web Application Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
ASP.NET Application Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
The Page Rendering Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Custom Rendered Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Composite Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Control Potpourri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Chapter 1

Web Application Basics

After completing this chapter, you will be able to

Interpret HTTP requests.

Use the Microsoft .NET Framework to make HTTP requests without a browser.

Interpret HTML.

Work with Internet Information Services (IIS).

Produce dynamic Web content without using Microsoft 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 users 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, but ASP.NET puts them
together in a way that makes Web development very approachable.
This chapter covers three topics necessary for you to understand to work with ASP.NET:

How HTTP requests work

How HTML works

How HTTP requests are handled on IIS, the Microsoft production Web server

Even though ASP.NET makes developing Web applications far easier than it was earlier,
having a solid understanding of how the individual components actually work is important
and can help you make sense of all parts of Web application development. For example,
when you are tracking down a stray HTTP request or trying to figure out why a section of
your page is appearing in the wrong font in a clients browser, its helpful to know how HTTP
and HTML work together to deliver the page to the client. And when you write a custom
control for a Web page, because custom controls often require that you write the rendering
code manually and ensure that the HTML tags emitted by the control occur in exactly the
right order, you need to understand HTML.
Understanding of the three technologies underlying ASP.NET frames the rest of the system.
As you study ASP.NET, these pieces will undoubtedly fall into place.

Part I

Fundamentals

Important To install the code samples for this book, you must have Administrator rights on
your computer. If you are using your own computer, you probably have Administrator rights. If
you are using a computer in an organization and you do not have Administrator rights, please
consult your computer support or IT staff. See the Code Samples section in the Introduction for
more information.

Important The code samples for this chapter on the companion CD require IIS support to
execute. See the Code Samples section in the Introduction for important information on
running the examples for this chapter.

HTTP Requests
The communication mechanism with which Web browsers talk to Web sites is named
Hypertext 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 arbitrarilywas becoming increasingly popular. Applications such as
Hypercard from Apple Computer introduced hypertext applications to a wider audience. If
documents could then be linked over a network, that would revolutionize publishing. Thats
the reason for the development of HTTP, 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 was the servers
job to send the file as a stream of text. After the response arrived at the clients 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 was 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 (specified 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 you see in developing ASP.NET applications are GET and POST, but other important
HTTP commands not as commonly used within ASP.NET include HEAD and PUT.
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 might cause side effects, such as when you send
information to the server for it to process. PUT is also used to send information to the server,

Chapter 1 Web Application Basics

but in the sense of documents and records versus request parameters, as is typically the case
for POST when related to HTML page requests. You make most initial contacts to a page using
a GET command, and you commonly handle subsequent interactions using POST commands.

HTTP Requests from a Browser

For example, look at the request that is sent from a browser to fetch the helloworld.htm
resource from the virtual directory aspnet4sbs running on localhost. (I cover the concept
of a virtual directory later; for now just imagine a virtual directory as the location of a Web
application that everyone can access.) Here is a sample (fictitious) HTTP server request:
*(7DVSQHWVEVKHOORZRUOGKWP+773
$FFHSWLPDJHJLILPDJH[[ELWPDSLPDJHMSHJLPDJHSMSHJ  
$FFHSW/DQJXDJHHQXV
$FFHSW(QFRGLQJJ]LSGHIODWH
8VHU$JHQW0R]LOODFRPSDWLEOH06,(:LQGRZV171(7&/5
+RVWORFDOKRVW
&RQQHFWLRQ.HHS$OLYH

If you would like to see the actual data going back and forth, several TCP monitors are
available. A good one is TcpTrace, found at http://www.pocketsoap.com/tcptrace/. You can
find instructions for its use there as well.
To issue a request to a Web server, the browser creates the HTTP request using 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 useful to the server. It then sends the request to the
server identified by the host HTTP header. 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 code shows the response provided by the server when asked for a simple
HelloWorld.htm file. Typically, you dont see all the header information when viewing the
resource through a browser, but a good TCP tracing utility such as TcpTrace shows it to you.
When you look at the tracing facilities of ASP.NET later on, this header information is visible.
+7732.
6HUYHU0LFURVRIW,,6
;3RZHUHG%\$631(7
'DWH7KX1RY*07
&RQWHQW7\SHWH[WKWPO
$FFHSW5DQJHVE\WHV
/DVW0RGLILHG0RQ2FW*07
(7DJHDFHIFEE
&RQWHQW/HQJWK
KWPO!
ERG\!
K!+HOOR:RUOGK!
1RWKLQJUHDOO\VKRZLQJKHUH\HWH[FHSWVRPH+70/
ERG\!
KWPO!