Cookies and Sessions

Lecture Notes for CS 142
Fall 2010
John Ousterhout

Stateless applications

Web application servers are generally "stateless":
- Each HTTP request is independent; server can't tell if 2 requests came from the same browser or user.
- Web server applications maintain no information in memory from request to request (only information on disk survives from one request to another).
Statelessness not always convenient for application developers: need to tie together a series of requests from the same user.

Cookie basics:
- The first time a browser connects with a particular server, there are no cookies.
- When the server responds it includes a Set-Cookie: header that defines a cookie.
- Each cookie is just a name-value pair.
- In the future whenever the browser connects with the same server, it includes a Cookie: header containing the name and value, which the server can use to connect related requests.
What's in a cookie?
- Name and data.
  - Data size limited by browsers (typically < 4 KB).
  - A server can define multiple cookies with different names, but browsers limit the number of cookies per server (around 50).
- Domain for this cookie: server, port (optional), URL prefix (optional). The cookie is only included in requests matching its domain.
- Expiration date: browser can delete old cookies.

Cookies are used by the server to implement sessions:
- A pool of data related to an active connection (one browser instance).
Typically the cookie for an application contains an identifier for a session.
Web frameworks like Rails do most of the work of managing sessions and cookies:
- Rails provides session, a hash-like object in which you can store anything you like
  - Data will be available in all future requests from the same browser.
- Rails automatically checks for a session cookie at the start of each request:
  - Cookie exists? use it to find session data
  - No cookie? Create new session, new cookie
- End of each request: save session data where it can be found by future requests.