Simple HTTP Transactions

Before exploring how CGI operates, it is necessary to have a basic understanding of networking and how the World Wide Web works. In this section, we examine the inner workings of the Hypertext Transfer Protocol (HTTP) and discuss what goes on behind the scenes when a browser makes a request and then displays the response. HTTP describes a set of methods and headers that allows clients and servers to interact and exchange information in a uniform and predictable way.

A Web page in its simplest form is an XHTML document, which is a plain text file that contains markings (markup or elements) that describe the structure of the data the document contains. For example, the XHTML

My Web Page

indicates to the browser that the text between the

start tag and the end tag is the title of the Web page. XHTML documents also can contain hypertext information (usually called hyperlinks), which are links to other Web pages or to other locations on the same page. When a user activates a hyperlink (usually by clicking it with the mouse), the Web browser "follows" the hyperlink by loading the new Web page (or a different part of the same Web page) from the Web server that contains the Web page.

Each XHTML file available for viewing over the Web has a URL associated with it. A URL contains the protocol of the resource (such as http), the machine name or IP address for the resource and the name (including the path) of the resource. For example, in the URL

http://www.deitel.com/books/downloads.html

the protocol is http, the machine name is www.deitel.com. The name of the resource being requested, /books/downloads.html (an XHTML document), is the remainder of the URL. This portion of the URL specifies both the name of the resource (downloads.html) and its path (/books), which helps the Web server processing the request to determine where the resource is located on the Web server. Note that an XHTML document ends with the .html file extension. The path could represent an actual directory in the Web server's file system. However, for security reasons, the path often refers to a virtual directoryan alias or fake name for a physical directory on disk. In this case, the server translates the path into a real location on the server (or even on another computer), thus hiding the true location of the resource. In fact, it is even possible that the resource is created dynamically and does not reside anywhere on the server's computer. As we will see, URLs also can be used to specify the user's input to a program on the server.

Now we consider how a browser, when given a URL, performs a simple HTTP transaction to retrieve and display a Web page. Figure 19.4 illustrates the transaction in detail. The transaction is performed between a Web browser and a Web server.

Figure 19.4. Client interacting with server and Web server. Step 1: The get request, GET /books/downloads.html HTTP/1.1.

Figure 19.4. Client interacting with server and Web server. Step 2: The HTTP response, HTTP/1.1 200 OK.

In Step 1 of Fig. 19.4, the browser sends an HTTP request to the server. The request (in its simplest form) looks like the following:

GET /books/downloads.html HTTP/1.1 Host: www.deitel.com

The word GET, an HTTP method, indicates that the client sends a get request and wishes to retrieve a resource. The remainder of the request provides the name and path of the resource (/books/downloads.html) and the protocol's name and version number (HTTP/1.1). After the Web server receives the request, it searches through the system for the resource.

Any server that understands HTTP (version 1.1) will be able to translate this request and respond appropriately. Step 2 of Fig. 19.4 shows the results of a successful request. The server first sends a response indicating 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;

HTTP/1.1 404 Not found

informs the client that the requested resource was not found on the server in the specified location.

The server then sends one or more HTTP headers, which provide information about the data being sent to the client. In this case, the server is sending an XHTML document, so the HTTP header reads

Content-Type: text/html

The information in the Content-Type header identifies the MIME (Multipurpose Internet Mail Extensions) type of the content. Each document from the server has a MIME type by which the browser determines how to process the data it receives. For example, the MIME type text/plain indicates that the data contains text that should be displayed without attempting to interpret any of the content as XHTML markup. Similarly, the MIME type image/gif indicates that the content is a GIF image. When this MIME type is received by the browser, it attempts to display the data as an image.

The headers are followed by a blank line, which indicates to the client that the server has finished sending HTTP headers. The server then sends the contents of the requested document (e.g., downloads.html). The connection is terminated when the transfer of the resource is complete (in this case, when the end of the document downloads.html is reached). The client-side browser interprets the XHTML it receives and renders (or displays) the results.