(This is the second post in a series covering the fundamentals of HTTP. If you feel lost, consider reading the first article)

HTTP is a stateless protocol. Every request is a unique snowflake, unrelated in any way to the last. When you finish one resource download and start another, it has no relation to the previous request. This has a number of advantages, such as the ability to grow your server with many unrelated worker nodes.

But what happens when you want to do things like create a persistent connection across multiple page visits? This is needed for applications providing user logins or shopping carts.

As most developers know, the solution is to use user sessions or cookies. If you use a web framework such as Rails, Django or Express, you are probably already using a session store that abstracts all the low level details away from you. Many developers learn how to use their framework’s cookie features and never learn the internals of HTTP cookies. What’s going on in there?

The solution is quite straight forward.

Cookie Creation

Let’s say we have a simple note taking application that allows the users to post notes to a page and view them at a later time (if they check the page from the same browser). The user fills out an HTML form and clicks the submit button.

At this point, the server will create a unique token in the database to identify the user in the future and know that they are the one who created that note. It also needs to share this information with the client so that the browser knows how to identify itself to the site in the future.

The “Set-Cookie” Response Header

The user will want to come back and view this note at a later time. Furthermore, the server must have some means of knowing which individual owns which note. The application does this by handing the client a secret token with an identifiable name. This is the cookie. It is given to the user in the ‘Set-Cookie’ response header.

A cookie contains some combination of the following:

• A name (required)
• A value (Required. Usually a secret identification token for lookups in the session database on the server.)
• An expiration date
• A URL path that the cookie can be used within
• The domain that the cookie can be used within
• Whether or not the cookie needs a secure (HTTPS) connection or not
• Whether the cookie is “HTTP only” or not. This relates to javascript and whether or not the server wants it to be accessible to client side apps. This one matters for preventing things like session hijacking.

Here is what the response would look like in our example:

Now that the note resource has been created, the server sends back a ‘NOTE-SESSION’ cookie for retrieval later.

The “Cookie” Request Header

Once given a cookie, a browser will store it on disk and hand it back to the server whenever it makes a request in the future. For instance, if the user wished to view their notes later on by visiting www.example.com/notes, the request might look like this:

Once a cookie is set, the browser hands the cookie back to the server on all future requests for identification purposes.

Armed with this information, the server now has a way of looking up the user’s unique notes in the database. Any request that does not have a valid ‘Cookie’ header will be considered a new user.