Delicious.
But those aren’t the kind of cookies we are talking about. Instead, we are talking about cookies on the Web.
In order to understand cookies, we first need to eat them know a few things about HTML and HTTP.
HTML and HTTP
Webpages are created using HTML. For example, if we have this HTML:
<!DOCTYPE html> <html> <head> <title>Example</title> </head> <body> <p>I am a paragraph, short and stout.</p> </body> </html>
It looks like this in your browser:
Easy-peezy-cupcake-squeezy.
When we view pages on the Web, we need the website to send us the HTML of the page we want. This is done using HTTP.
You can think of it like sending a letter in the mail. The content of the letter is HTML. The address information is HTTP.
When you visit a page, your browser sends something like this to the website:
GET /path/to/folder/page.html HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Host: www.example.com Connection: keep-alive
This is a HTTP request. The first line contains the URL of what we are requesting. All the other lines are called headers. Headers are in the format Name: value, and they are each on their own line. They give information about various properties.
Upon receiving our request, the website sends back something like this:
HTTP/1.1 200 OK Date: Wed, 10 Aug 2016 16:39:01 GMT Content-Length: 125 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 <!DOCTYPE html> <html> <head> <title>Example</title> </head> <body> <p>I am a paragraph, short and stout.</p> </body> </html>
This is a HTTP response. The first line is the status. In this case there were no problems with the request, which is status code 200. You are probably familiar with status code 404, which is sent when requesting something that cannot be found.
As with the request, the response also contains various headers. After the headers comes the body, which is separated from the headers by a blank line. The body is the actual thing we requested, such as a page or image. Once the browser receives the response, it gets the HTML from the body and shows you the page.
You promised me cookies, you say. Show me the cookies.
Not quite yet. You should probably lay off the cookies, anyway.
To understand why cookies exist, we need to understand state.
State
State is the particular condition something is in at a given point in time. For example, you being hungry is a state. A lamp being on or off is a state.
In contrast, things can also be stateless. They don’t change over time, and are always in the same condition.
HTTP is stateless. It does not remember previous requests or responses, and treats every new request as if it is the first one.
Stateless smateless, you say. Who cares?
Here is the problem: being logged-in to a website is a state, as is being logged-out. But HTTP is stateless. It doesn’t know if you are logged in or not. It is as if you logged out every time you clicked a link.
Let’s say you log in to Facebook. It is somebody’s birthday today, so you go to their profile. Your browser sends an HTTP request to the website. How does the website know who you are logged in as? To it, all the HTTP requests it gets look about the same. It cannot identify where they came from.
Cookies
The solution to this problem is cookies. Though really, what problem are cookies not the solution to? Even the dark side has them!
Cookies were created to allow maintaining state while using stateless HTTP. They are implemented using HTTP headers.
After you log in to a website, the HTTP response from the website looks like this:
HTTP/1.1 200 OK Date: Wed, 10 Aug 2016 16:39:01 GMT Content-Length: 125 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 Set-Cookie: id=494082 <!DOCTYPE html> <html> <head> <title>Example</title> </head> <body> <p>I am a paragraph, short and stout.</p> </body> </html>
Notice there is now a Set-Cookie header. Then, when the browser requests another page:
GET /path/to/folder/page.html HTTP/1.1 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Host: www.example.com Connection: keep-alive Cookie: id=494082
The request now contains a Cookie header.
The Set-Cookie header tells the browser “send me this back later.” Then, every time the browser makes a request to that website, it sends the cookie back with the Cookie header.
The cookie can contain any text the website wants. For this example, it is an id number. The website creates an id number when you log in. It tells the browser to store a cookie with that value. Then, the browser sends it back in all future requests. Every time you visit a new page on the website, it now knows who you are based on your id number. Our login problem is solved.
The website can also remove cookies it created previously. When cookies are created with Set-Cookie there are several options that can be used, including an expiration date. If a website wants to remove a cookie immediately, it includes Set-Cookie with an expiration date in the past, which makes the browser remove it instantly. This is what happens when you log out of websites.
If a cookie is created without an expiration date, it lasts until the browser is closed. This is the way most website logins work by default. When you see checkboxes labeled “keep me logged in,” what they do is set the expiration date far into the future – often effectively infinity (e.g. 1000 days from now). This means the cookie will only expire when you log out of the website, so doing things like closing your browser does not log you out.
How are cookies used?
Cookies are used any time a website tries to maintain state about people visiting it.
The biggest use of them by far is allowing users to stay logged-in to websites. This is known as a session.
They are also used in tracking and analytics, including third-party ads.
Beyond this, many other things websites remember about you is stored in a cookie, such as language settings or visual themes.