| Previous | Table of Contents | Next |
then press your Enter key. This causes your browser (client) to attempt to establish a connection with the Web server located at the Web address you gave. Once the connection is established, the browser makes a request of the server. Generally the request is for a file, such as a text file or image file, located on the server. Sometimes the request is for a program that resides on the server. The server receives the request and processes it: if the request was for a program, it executes the program through a special gateway, and gets the result; if the request was for some sort of file, it locates the file. The server then either sends the requested information back to the client (the program output or the file), or it sends back a message explaining why it cannot fulfill the request. Finally, the server terminates the connection.
The last step—termination of the connection—is why HTTP is described as “stateless,” and it’s an important point to consider when designing Web-enabled applications.
The Hypertext Transport Protocol is the communication protocol used by Web servers and Web clients to talk with each other. The protocol is relatively simple, with all transactions following the same basic pattern. Each request—either from client to server, or server to client—consists of three parts:
Here’s an example of a request line from a client to a server:
GET /home.html HTTP/1.0
This is a request to use the GET method, one of two methods by which a client is allowed to ask for a document (the other is POST). The client is requesting the document home.html and is telling the server that it can use HTTP version 1.0.
The client may follow with a header section that contains more text instructions to the server, informing the server of the type of browser it’s using, and what kind of files it is able to accept, such as GIFs (a kind of image file), text, and so on. One blank line marks the end of the header.
Next, if the request were for some sort of program, the client might send some additional information, such as the parameters required for the program. The manner in which it supplies the parameters is dependent upon whether the client is making a GET request or a POST request.
Once the server receives the client’s request, it processes the request, determines if the request is valid, and if it is able to serve the request. Depending on what the server does, it might send back the requested file. If the request were to run a program, the server will send back the program’s output. If the server was unable to serve the request for any reason, it will send back one of several HTTP response codes, such as 500 Internal Server Error, or 503 Service Unavailable.
Uniform Resource Locator (URL)
Uniform Resource Locators, or URLs, are character strings that are used to specify the address of a resource (file, program, and so on) on the Internet. For example:
http://www.corbinian.com/macmillan/article.htm
URLs have a specific syntax. In the above example, the first part, http://, is telling the browser to employ HTTP as the communications protocol, as opposed to gopher, ftp, or some of the other options available. The www is a machine name for the host, and the corbinian.com is the address of the host. This host name points the browser to the computer housing the Web server software that the client wants to communicate with. Once connected, the rest of the URL maps to different resources available to that Web server, and the mapping is dependent on that Web server’s configuration. Generally speaking, most URLs are pointing to some directory or subdirectory on a hard drive (like /macmillan) connected to the host machine, with the final part of the URL, which in this example is article.htm, pointing to some particular file in that subdirectory.
Note:
Contrary to popular belief, the part of the URL in the example that indicates this is the World Wide Web is not the www, but the http://. The www is a machine, and many (but not all) administrators just tend to pick the www name to identify the machine running the Web server. The http, on the other hand, is distinctly a Web protocol, and is the giveaway that this is a Web address.
(The WAS has some powerful features for redirecting incoming URL requests in some unique ways. But more on that later.)
By embedding URLs in Web pages in a hyperlink, users are able to click a hyperlink, which tells the Web server to go get the resource identified by that URL, and to replace the existing display in the client with the new resource. This is how documents on the Web are connected and is the essence of the ”webbiness” of the Web.
The Common Gateway Interface (CGI)
HTTP is intended to serve up static files—that is, unchanging stored text or image files. The CGI was created to add the ability to execute programs. If a Web server is configured to support CGI, then an incoming request can ask for a program to be executed, as opposed to asking for a static file. The request for a program is coded into the URL, by asking for a program by name, and including its subdirectory. If the request Web server is properly configured, it will recognize the subdirectory as a CGI subdirectory, and route the request through the CGI to have the program executed. The program’s output is then sent back to the Web server, which serves the output to the client.
Since the request to run a program is coded into the URL, the hyperlinks that are embedded in Web documents can be used to not only request new text and images to be displayed, but to execute programs, regardless of where the program resides on the network.
| Previous | Table of Contents | Next |