HttpPrimer

Statelessness

HTTP, or Hyper Text Transfer Protocol, (the protocol the web relies on most) is a stateless protocol. Stateless means it does not respond to any single request as though it were related or tied to any prior or forth-coming request. HTTP is built on a request-response model that governs most client-server relationships. Knowing and understanding these fundamental principles about HTTP will bring you a long way with writing PHP scripts that generate dynamic web pages. Since the protocol is closely tied to the web and since PHP is most notable for use in web content generation these things go hand-in-hand.

How HTTP Can Be Stateless but Allow User Sign-In

So how can the web be stateless and still retain state? That's actually a good question, because when the World Wide Web was first implemented the intention was strictly to publish content. The web is already very good at this. If I write a dissertation on Network Security and would like to publish my thesis online it's very easy for me to put that content on a website where anyone with Internet access can view it. However, static content is boring. Anyone can write something and publish it online (that's not why blogs are popular today by the way). When you need to collect information from others or communicate collectively or in pairs, or when you want to run Software as a Service (SaS) over the web like Gmail, Hotmail, or Y!Mail the web seems to lack in many areas.

If the web seems like a horrible way to do things like Instant Messaging, Video/Audio broadcasting/conferencing, etc... that's because it was never designed as a broadcast mechanism and thus requests weren't initially designed to be stateful (that is to say that the webserver can tie one request from a client to any other previous or future request).

The client, however, does make retaining some kind of state possible with things like cookies. HTTP cookies are made up of key/value pairs and sent as a part of the request/response headers in most GET/POST HTTP requests and can be sent by either the client or server or both. In most cases the idea is that the server provides the client with some information that they would like them to retain in future requests by sending one or more cookies in the HTTP response header of a particular request. The client's browser (or User Agent) then stores this cookie on their machine either in memory or on disk and continues to send the same cookie back in each future request (as a part of the request header) made to the domain assigned by that cookie. The server can make use of this information in a number of ways to track the client in subsequent requests, like determine if a user is logged in or authenticated, identifying a user's session information stored on the server, store user preferences or even shopping cart content.

PHP and State

So let's get down to PHP's role in all of this. First, let's start by understanding exactly how cookies work and how PHP can use them to retain some information about a client during subsequent requests. Below is a snapshot I took using netcat (a network utility for reading/writing networking connections using TCP/UDP) in the terminal window on the right and a browser to demonstrate what cookies actually look like in HTTP. Remember HTTP is a plain text protocol. It really doesn't do much of anything fancy behind the scenes.

In this example I'm basically substituting what the webserver and PHP would do when I go to my browser address bar and type in http://localhost/foobar and in this case as you can see what happens is my browser sends a request (since I'm listening in on the port with netcat I can capture and respond to this request myself). The response header I sent back includes a cookie using the Set-cookie: HTTP response header. The cookie is given a name and a value and an expiration date. You'll notice that actually I set this cookie in a previous request as well along with another cookie and so the current request includes them in the client's request header.