HTTP is a stateless protocol – the server is not required to retain information or status about each user for the duration of multiple requests.
For smart web applications, however, this isn’t good enough. You want to login into an application and have it remember you across requests. A good example is maintaining a "shopping cart" at some merchandise website, which you gradually fill as you browse through the products that interest you.
A cookie is just an arbitrary string sent by the server to the client as part of the HTTP response. The client will then return this cookie back to the server in subsequent requests. The information stored in the cookie is opaque to the client – it’s only for the server’s own use. This scheme allows the client to identify itself back to the server with some state the server has assigned it. Here’s a more detailed flow of events:
- The client connects to the server for the first time, and sends a normal HTTP request (say, a simple GET for the main page).
- The server wants to track the client’s state and in its HTTP response (which contains the page contents) attaches a Set-Cookie header. This header’s information is a set of key, value pairs, where both keys and values are strings that make sense for the server, but for the client are a black box.
- In subsequent requests the client makes to the server, it adds a Cookie header in the HTTP requests it sends, with the cookie information the server specified in previous responses.
Implementation-wise, the client stores the latest cookie received from various servers (which are easily identifiable by their URLs). Even if the next time the client accesses the server is a few days after the previous request, it will still send this information (assuming the cookie hasn’t expired), and the server will be able to identify it. This is why I can point my browser to Amazon today, not having visited it for some weeks, and the website will greet me with "Hello, Eli".
The above is a necessarily simplified explanation of cookies – I have no intention of repeating the contents of the RFC here. There are a lot of details I’ve left out like expiration time, filtering of cookies by paths, various size and amount limits the user agents (web browsers, etc.) are forced to abide, and so on. However, it’s a sufficient amount of details for the needs of this article, so let’s see some code.