Simple HTTP Transactions
Web application development requires a basic understanding of networking and the World Wide Web. In this section, we discuss the Hypertext Transfer Protocol (HTTP) and what occurs behind the scenes when a browser displays a Web page. HTTP specifies a set of methods and headers that allow clients and servers to interact and exchange information in a uniform and predictable manner.
In its simplest form, a Web page is nothing more than an XHTML documenta plain text file containing markup (i.e., tags) that describe to a Web browser how to display and format the document's information. For example, the XHTML markup
My Web Page
indicates that the browser should display the text between the
start tag and the end tag in the browser's title bar. XHTML documents also can contain hypertext data (usually called hyperlinks), which links to different pages or to other parts of the same page. When the user activates a hyperlink (usually by clicking it with the mouse), the requested Web page loads into the user's browser window.
Any XHTML document available for viewing over the Web has a corresponding Uniform Resource Locator (URL). A URL is an address indicating the location of an Internet resource, such as an XHTML document. The URL contains information that directs a browser to the resource that the user wishes to access. Computers that run Web server software make such resources available. When requesting ASP.NET Web applications, the Web server is usually Microsoft Internet Information Services (IIS). As we discuss shortly, it is also possible to test ASP.NET applications using the ASP.NET Development Server built into Visual Web Developer.
Let us examine the components of the URL
http://www.deitel.com/books/downloads.html
The http:// indicates that the resource is to be obtained using the HTTP protocol. The middle portion, www.deitel.com, is the server's fully qualified hostnamethe name of the computer on which the resource resides. This computer usually is referred to as the host, because it houses and maintains resources. The hostname www.deitel.com is translated into an IP address (68.236.123.125), which identifies the server in a manner similar to how a telephone number uniquely defines a particular phone line. The hostname is translated into an IP address by a domain name system (DNS) servera computer that maintains a database of hostnames and their corresponding IP addresses. This translation operation is called a DNS lookup.
The remainder of the URL (i.e., /books/downloads.html) specifies both the name of the requested resource (the XHTML document downloads.html) and its path, or location (/books), on the Web server. The path could specify the location of an actual directory on the Web server's file system. However, for security reasons, the path often specifies the location of a virtual directory. In such systems, the server translates the virtual directory into a real location on the server (or on another computer on the server's network), thus hiding the true location of the resource. Some resources are created dynamically and do not reside anywhere on the server computer. The hostname in the URL for such a resource specifies the correct server, and the path and resource information identify the location of the resource with which to respond to the client's request.
When given a URL, a Web browser performs a simple HTTP transaction to retrieve and display the Web page found at that address. Figure 21.1 illustrates the transaction in detail. This transaction consists of interaction between the Web browser (the client side) and the Web server application (the server side).
Figure 21.1. Client interacting with Web server. Step 1: The GET request.
(This item is displayed on page 1054 in the print version)
(a) The GET request is sent from the client to the Web Server.
(b) After it receives the request, the Web Server searches through its system for the resource.
In Fig. 21.1, the Web browser sends an HTTP request to the server. The request (in its simplest form) is
GET /books/downloads.html HTTP/1.1
The word GET is an HTTP method indicating that the client wishes to obtain a resource from the server. The remainder of the request provides the path name of the resource (an XHTML document) and the protocol's name and version number (HTTP/1.1).
Any server that understands HTTP (version 1.1) can translate this request and respond appropriately. Figure 21.2 depicts the results of a successful request. The server first responds by sending a line of text that indicates the HTTP version, followed by a numeric code and a phrase describing the status of the transaction. For example,
HTTP/1.1 200 OK
indicates success, whereas
HTTP/1.1 404 Not found
informs the client that the Web server could not locate the requested resource.
Figure 21.2. Client interacting with Web server. Step 2: The HTTP response.
(This item is displayed on page 1054 in the print version)
The server responds to the request with an appropriate message and the resource's contents.
The server then sends one or more HTTP headers, which provide additional information about the data that will be sent. In this case, the server is sending an XHTML text document, so the HTTP header for this example reads:
Content-type: text/html
The information provided in this header specifies the Multipurpose Internet Mail Extensions (MIME) type of the content that the server is transmitting to the browser. MIME is an Internet standard that specifies data formats so that programs can interpret data correctly. For example, the MIME type text/plain indicates that the sent information is text that can be displayed directly, without any interpretation of the content as XHTML markup. Similarly, the MIME type image/jpeg indicates that the content is a JPEG image. When the browser receives this MIME type, it attempts to display the image.
The header or set of headers is followed by a blank line, which indicates to the client that the server is finished sending HTTP headers. The server then sends the contents of the requested XHTML document (downloads.html). The server terminates the connection when the resource transfer is complete. At this point, the client-side browser parses the XHTML markup it has received and renders (or displays) the results.