HTTP Protocol and the Request/Response CycleA 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
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 Filebash-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
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.
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. |