The most proficient developers are those who possess an intimate understanding of the platforms they program and the tools they use to program them. Because it’s difficult to understand how Web forms work if you lack a more general understanding of Web applications and the protocols that drive them, the next several sections provide a working introduction to the operation of Web apps. They’re for developers who have little or no Web programming experience. If you’re already familiar with HTTP, HTML forms, and other Web-related technologies, feel free to skip ahead to the section entitled “Your First Web Form.” If, however, Web apps are a new frontier for you, you’ll find the following discussion helpful in building an in-depth understanding of the Web Forms programming model.
The Hypertext Transfer Protocol, better known as HTTP, is the protocol that drives the World Wide Web. Invented by Tim Berners-Lee ("father of the Web") and documented in RFC 2068, which is available online at www.w3.org/Protocols/rfc2068/rfc2068, HTTP is arguably the most important network protocol ever invented, with the notable exception of TCP/IP.
HTTP defines how Web browsers and Web servers communicate with each other. It’s entirely text based, and it’s typically transmitted over TCP connections linking Web browsers to Web servers. Suppose the following HTML file is deployed on a Web server, that its name is Simple.html, and that its URL is www.wintellect.com/simple.html:
<html> <body> Hello,?world </body> </html>
If a user types http://www.wintellect.com/simple.html into Internet Explorer’s address bar, Internet Explorer (IE) uses the Internet’s Domain Name System (DNS) to convert www.wintellect.com into an IP address (for example, 126.96.36.199). Then IE opens a socket connection to the server at that address using a well-known port number (port 80) and transmits an HTTP request similar to this one:
GET?/simple.html?HTTP/1.1 Accept:?*/* Accept-Language:?en-us Accept-Encoding:?gzip,?deflate If-Modified-Since:?Wed,?24?Oct?2001?14:12:36?GMT If-None-Match: "50b0d3ee955cc11:a78" User-Agent:?Mozilla/4.0.(compatible;?MSIE.6.0;?Windows?NT?5.1) Host:?www.wintellect.com Connection:?Keep-Alive [blank?line]
The first line of the request is called the start line. It consists of a method name (GET), the name of the resource being requested (simple.html), and an HTTP version number (1.1). GET is one of seven methods defined in HTTP 1.1; it requests a resource from a Web server. The next eight lines make up the message header. Each line, or header, contains additional information about the request, including information about the browser that originated the request (User-Agent). A blank line (a simple carriage return/line feed pair) marks the end of the message header and also the end of the request.
How does the Web server respond to the GET command? Assuming /simple.html is a valid resource identifier and security settings don’t prevent the file from being returned, the server transmits an HTTP response like this one:
HTTP/1.1?200?OK Server:?Microsoft-IIS/5.0 Date:?Wed,?24?Oct?2001?14:12:37?GMT Content-Type:?text/html Accept-Ranges:?bytes Last-Modified:?Wed,?24?Oct?2001?14:00:53?GMT ETag: "d02acf81975cc11:a78" Content-Length:?46 [blank line] <html> <body> Hello,?world </body> </html>
Upon receiving the response, the browser parses the HTML returned by the Web server and displays the resulting Web page. The Content-Type header identifies the returned data as HTML, while Content-Length tells the browser how much HTML was returned. The “200” in the first line of the response is an HTTP status code signifying that the server fulfilled the browser’s request. The HTTP specification defines about 40 different status codes, including the infamous 401 (“Unauthorized”) code indicating that the user isn’t authorized to view this resource.
Conversations such as these form the backbone for communications over the Web. As you surf the Web by typing URLs and clicking hyperlinks, your browser issues one GET command after another. Tools such as NetMon—the network packet-sniffing utility that comes with server editions of Windows—let you spy on the HTTP traffic flying back and forth. You don’t have to be an HTTP guru to write ASP.NET applications, but a knowledge of basic HTTP semantics and a familiarity with commonly used request and response headers are a big help in understanding the ASP.NET object model.
Simple.html is a far cry from a full-blown Web application. It’s a static HTML file that solicits no user input. Real Web applications like the ones located at www.amazon.com and www.ebay.com accept input from their users, and they vary the HTML that they return to Web browsers based on the contents of that input.
At the heart of almost every genuine Web application is an HTML form. An HTML form is the portion of an HTML document that appears between <form> and </form> tags. The HTML in Figure 5-1 describes a simple form representing a Web-based adding machine. The form contains two text input fields for the user to type numbers into and an equals button that submits the form back to the server. Figure 5-2 shows how the form appears in Internet Explorer. As you can see, the browser renders an <input type=“text”> tag as a text input field and an <input type=“submit”> tag as a push button. Similar tags can be used to create check boxes, radio buttons, list boxes, and other basic control types.
<html> ??<body> ????<form> ??????<input?type="text" name="op1" /> ??????+ ??????<input?type="text" name="op2" /> ??????<input?type="submit" value=" ?=? " /> ????</form> ??</body> </html>Figure 5-1
A submit button (<input type=“submit”>) plays a special role in an HTML form. When clicked, it submits the form to a Web server. To be more precise, the browser submits the form along with any input in the form’s controls. How the form is submitted depends on whether the <form> tag includes a Method attribute and the value of that attribute, if present. If the <form> tag lacks a Method attribute or includes a method=“get” attribute, the browser sends an HTTP GET command to the server with the user’s input appended to the URL in the form of a query string:
GET?/calc.html?op1=2&op2=2?HTTP/1.1 ??. ??. ??. Connection:?Keep-Alive [blank?line]
If, on the other hand, the <form> tag includes a method=“post” attribute, the form is submitted to the server using an HTTP POST command. Rather than transmit user input in the URL, with a POST command the browser passes it in the body of the HTTP request:
POST?/calc.html?HTTP/1.1 ??. ??. ??. Content-Type:?application/x-www-form-urlencoded Content-Length:?11 [blank line] op1=2&op2=2
Regardless of whether a GET or a POST command is used, when input from an HTML form is submitted back to the server, we say that a “postback” has occurred. Remember that term because you’ll encounter it repeatedly in this and the next several chapters.
For a first-hand look at HTML forms in action, copy Calc.html to your PC’s \Inetpub\wwwroot directory and call it up in Internet Explorer by typing the following URL:
Now type 2 into each of the form’s text boxes and click the = button. As evidence that a postback occurred, observe what appears in the browser’s address bar (shown in Figure 5-3). If you change the <form> tag to
and repeat the experiment, you won’t see any change in the URL. But the postback occurs just the same, and the Web server can access the user’s input by examining the body of the request.