HTTP Protocol and the RequestResponse Cycle

HTTP Protocol and the Request/Response Cycle

A browser is a program that communicates with remote servers (such as a Web server like Apache or a servlet engine like Tomcat) to access and retrieve information. These servers are located in remote locations and could be anywhere on the Internet. Yet

Communications are fast.
Communications are secure.
The server always remembers who you are and keeps track of your information ”even if 1000 other people around the world are hitting the same server at the same time!

Understanding the underlying architecture behind this and the details of how it works is key to building and debugging Web-based applications.

Browsers send and receive information using the Hypertext Transfer Protocol (or HTTP). At the core of HTTP is the idea of a request and a response. The browser issues a request when you type in a URL and press the Enter key. The server at the other end accepts the request and sends a response. Responses are made up of HTML, images, and control information. HTTP commands are generally readable English.

There is nothing mysterious or magic about HTTP. It simply provides a standard way for browsers to exchange information (HTML pages, images, and other control information) with Web servers. The easiest way to demonstrate this is to just try it. For example, Listing 4.1 contains a very simple HTML file.

Listing 4.1 A Sample File for Testing the HTTP Protocol ( `index.html` )

 <html>     <head>         <title>Testing HTTP Protocol Communications</title>     </head>     <body>         <p> This page is for testing HTTP Communications     </body> </html>

Given this simple file, Listing 4.2 demonstrates the HTTP communication that retrieves the file from a Web server.

Note

Note that for this listing (and all listings in this book) lines in bold are commands typed at the command line.

Listing 4.2 Sample of HTTP Communications for Retrieving the `index.html` File

  bash-2.05$ ./telnet -E localhost 8080  Trying 127.0.0.1... Connected to localhost. Escape character is 'off'.  GET /index.html HTTP/1.0  HTTP/1.1 200 OK Content-Type: text/html Content-Length: 186 Date: Thu, 30 May 2002 23:53:30 GMT Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector) Connection: close Last-Modified: Thu, 30 May 2002 23:51:23 GMT ETag: "186-1022802683343" <html>     <head>         <title>Testing HTTP Protocol Communications</title>     </head>     <body>         <p> This page is for testing HTTP Communications     </body> </html> Connection closed by foreign host. bash-2.05$

The HTTP GET command retrieves HTTP headers and the contents of the index.html file.

The telnet program established a TCP connection with a server at localhost (the machine I am typing on) on TCP port 8080, the port where my local installation of Tomcat was listening). After the connection was established, I typed the following HTTP command ( terminated by two successive carriage returns):

  GET /index.html HTTP/1.0

This GET request asked the server (identified as being Apache Tomcat/4.0.3) to find the file /index.html and send it to me in its response. I also specified that I wanted to communicate using HTTP version 1.0 (as opposed to the more recent ”and more complex ”HTTP version 1.1).

The server responded with the control information and the contents of the index.html file. Among other things, the control information included

HTTP/1.1 200 OK
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
Last-Modified: Thu, 30 May 2002 23:51:23 GMT

The control information included the fact that the request was processed correctly (the HTTP/1.1 200 OK response code), the server type, and the time the file was last modified.

USING `TELNET` FOR TCP COMMUNICATIONS TESTING

Why did I use the telnet utility in the previous example instead of using a browser?

The telnet utility simply opens a low-level TCP connection on a specified TCP port. It then enables you to enter HTTP commands directly from the command line. You get to actually see the low-level HTTP communications.

For example, the command

  telnet -E localhost 8080

instructs the telnet utility to establish a TCP connection on TCP port 8080 and simply hold the connection open . (The -E option disables escape characters .)

This is a common way to test communications with a remote HTTP server, and will be used throughout the book when I want to demonstrate low-level HTTP communications.

Using the command-line version of telnet also provides an advantage in this situation over most GUI-based telnet utilities. This is because most GUI-based telnet utilities exit (and close their window!) when the TCP connection is closed by the remote host. By using the command-line utility, you can still see the results of the commands after the command is processed and the connection is closed.

If you're running these tests on a Windows-based computer, a good command-line telnet utility is the one included in Cygwin Tools (http://www.cygwin.com/). Cygwin Tools is free software released under the GNU General Public License (GPL).

The important thing here is to understand the request/response cycle is driven by the HTTP protocol. A request comes in to the server carrying with it information from (and about) the requester. The server processes the request and returns a response.

Note

This request/response cycle is also reflected in the JSP and Servlet specifications. By definition, a servlet has a doGet() method that's executed when an HTTP GET request is processed. (Similar doPut() , doPost() , and other methods exist as well.) This shows again how having an understanding of the underlying HTTP protocol can help you better understand the JSP/servlet technology that underlies Struts.

HTTP Protocol and the RequestResponse Cycle