My last article in this series discussed the process that a server follows to produce a web page. To simplify things for that article, I considered the generation of the page on its own, without interaction from a larger context. However, one of the major needs for any sizable site is to interact with visitors on an individual basis, responding to actions they take and remembering preferences they've indicated. Web developers must use special methods to provide this degree of interactivity.
Web pages operate on what is called a "stateless" protocol. That is, every time a web page is requested, it is treated as an entirely separate event, without indication of former interaction (with certain exceptions I'll mention below). In order to tie the pages in a site into a seamless experience for the visitor, developers have to emulate states (different behavior based on former interactions) using server code and data passed between the server and the client.
States are emulated like this: when a new visitor requests a page for the first time, along with the page the server sends back a unique identifier for that visitor. The next time the visitor requests a page, the identifier is sent back along with the request. The server recognizes the identifier and makes any necessary adjustments in the generation of the page, then sends the new page (and usually the identifier again as well) back to the visitor. This game of tennis continues as long as the visitor keeps requesting pages and the server keeps recognizing the identifier.
There are several forms this identifier can take. One method is to add a hidden form field (similar to the ordinary form fields where you are asked to type in, say, an email address) that is passed along when a visitor submits a form. However, this has the disadvantage that the user must click on specific buttons or links in order to keep this going. To get around this problem, the server can send a "cookie" to the client. A cookie is a piece of data that the client stores and sends back to the server whenever it requests a page. It can be any type of data, but one of the most common is a session identifier. This allows the server to keep track of the visitor whether the page was requested through a form or a link or just typed into the address bar. It's also possible for the server to recognize the client from data that is already available (such as the IP address or previous page), but this is unreliable and is rarely used by itself for establishing sessions.
With a method for establishing the identities of its clients, the server is then able to serve up pages customized for each client. One such application is client accounts. The methods used to set up a session don't require the visitor to log in or verify their identity, but if the developer adds a login page and stores the credentials on the server, the visitor can then log in from any computer and link their session with their account on the server. This allows them to perform private transactions like buying a product or storing sensitive information without fear that others will be able to access their account. Of course, it's also useful for remembering the visitor's preferences between visits.
You can find the other posts in this series below.
Web Development for the Non-Programmer: Web Applications and Servers
Web Development for the Non-Programmer: Browsers and Programming Langauges
Web Development for the Non-Programmer: Introduction
For the best prices, on the largest selection of faucets, from your favorite brands like Kohler, Danze, and American Standard shop PlumberSurplus.com 24 hours a day, 7 days a week.