Database Applications and the Web - HTTP: the Hypertext Transfer Protocol
(Page 3 of 9 )
The three-tier architecture provides a conceptual frameworkfor web database applications. The Web itself provides the protocols and network that connect the client and middle tiers of the application: it provides the connection between the web browser and the web server. HTTP is one component that binds together the three-tier architecture.
HTTP allows resources to be communicated and shared over the Web. Most web servers and web browsers communicate using the current version, HTTP/1.1. A detailed knowledge of HTTP isn’t necessary to understand the material in this book, but it’s important to understand the problems HTTP presents for web database applications. (A longer introduction to the underlying web protocols can be found in Appendix D.)
HTTP example HTTP is conceptually simple: a web browser sends a request for a resource to a web server, and the web server sends back a response. For every request, there’s always one response. The HTTP response carries the resource—the HTML document, image, or output of a program—back to the web browser.
An HTTP request is a textual description of a resource, and additional information or headers that describe how the resource should be returned. Consider the following example request:
GET /~hugh/index.html HTTP/1.1
Host: goanna.cs.rmit.edu.au
From: hugh@hughwilliams.com (Hugh Williams) User-agent: Hugh-fake-browser/version-1.0 Accept: text/plain, text/html
This example uses aGET method to request an HTML page /~hugh/index.html from the server goanna.cs.rmit.edu.au with HTTP/1.1. In this example, four additional header lines specify the host, identify the user and the web browser, and define what data types can be accepted by the browser. A request is normally made by a web browser and may include other headers.
An HTTP response has a response code and message, additional headers, and usually the resource that has been requested. Part of the response to the request for /~hugh/index.html is as follows:
HTTP/1.1 200 OK
Date: Thu, 04 Dec 2003 04:30:02 GMT
Server: Apache/1.3.27 (Unix)
Last-Modified: Fri, 21 Nov 2003 22:26:07 GMT ETag: "a87da0-2128-3fbe90ff"
Accept-Ranges: bytes
Content-Length: 8488
Content-Type: text/html
<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
...
The first line of the response tells the browser that the response is HTTP/1.1 and confirms that the request succeeded by reporting the response code200and the messageOK. In this example, seven lines of additional headers identify the current date and time, the web server software, the last date and time the page was changed, an entity tag (ETag) that is used for caching, an instruction to the browser on how to request part of the document, the length of the response, and the content type. After a blank line, the resource itself follows, and we’ve shown only the first few lines. In this example the resource is the requested HTML document, /~hugh/index.html.
State Traditional database applications are stateful. Users log in, run related transactions, and then log out when they are finished. For example, in a bank application, a bank teller might log in, use the application through a series of menus as he serves customer requests, and log out when he’s finished for the day. The bank application has state: after the teller is logged in, he can interact with the application in a structured way using menus. When the teller has logged out, he can no longer use the application.
HTTP is stateless. Any interaction between a web browser and a web server is independent of any other interaction. Each HTTP request from a web browser includes the same header information, such as the security credentials of the user, the types of pages the browser can accept, and instructions on how to format the response. The server processes the headers, formulates a response that explains how the request was served, and returns the headers and a resource to the browser. Once the response is complete, the server forgets the request and there’s no way to go back and retrieve the request or response.
Statelessness has benefits: the most significant are the resource savings from not having to maintain information at the web server to tracka user or requests, and the flexibility to allow users to move between unrelated pages or resources. However, because HTTP is stateless, it is difficult to develop stateful web database applications: for example, it’s hard to force a user to follow menus or a series of steps to complete a task.
To add state to HTTP, you need a method to impose information flows and structure. A common solution is to exchange a token or key between a web browser and a web server that uniquely identifies the user and her session. Each time a browser requests a resource, it presents the token, and each time the web server responds, it returns the token to the web browser. The token is used by the middle-tier software to restore information about a user from her previous request, such as which menu in the application she last accessed.
Exchanging tokens allows stateful structure such as menus, steps, and workflow processes to be added to the application. They can also be used to prevent actions from happening more than once, time out logins after a period of inactivity, and control access to an application.
Next: Thickening the Client in the Three-Tier Model >>
More MySQL Articles
More By O'Reilly Media
|
 This article is excerpted from chapter one of the book Web Database Applications with PHP and MySQL, written by Hugh E. Williams & David Lane (O'Reilly, 2004; ISBN: 0596005431). Check it out at your favorite bookstore. Buy this book now.
|
|
/ 39 
