ASP.NET —

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 most browsers interpret as a combo box. Various attributes applied to the <input></input> tag causes browsers to draw text boxes and buttons.

HTML Forms

HTML includes a <form></form> tag for notifying the browser that a section of HTML includes tags representing controls. This is how you specify a Web document will be handling input from the end user (not just output).

The <form> tag usually sandwiches a set of tags specifying controls. Listing 1-4 shows the feature selection page, but with the form tag added (the file name is SelectFeature2.htm in the accompanying examples):

Listing 1-4

<html>
<body>
<form action="http://localhost/HttpHandlers/selectfeature.htm"
     method="get">
<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>
</select>
</br>
<input type=submit name='Lookup' value='Lookup'></input>
</br>
</form>
</body>
</html>

The form tag includes several attributes that you may set to control how the page behaves. In the above example, notice the <form> tag sets the ACTION attribute, which points back to 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 Listing 1-4 is the method attribute. The method attribute specifies the HTTP method used when submitting the form. The method employed in the example is GET because the software on the server doesn't understand POST yet. GET causes the form contents to be appended to the URL. POST causes the form contents to be sent to the server in a data body.

Adding the form tag to the body of the document gets us part of the way to having a workable HTTP application. 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 (though it will only perform an HTTP GET command to refetch the document).

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 the user does an initial GET for the resource, then selects a features from the combo box and clicks the Submit button. For an interactive application to work, the browser will need to make a second round-trip to the server with a new request. The server will need to examine the request coming from the browser and figure out what to do about it.

Common Gateway Interface

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 watch port 80 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).