The web remembers you

how does your shopping cart stay full? you need to remember your state but HTTP is stateless! HTTP is only a simple request-response protocol.

how do you take the 2nd HTTP request and link it to the first one? (when you add a 2nd item to your shopping cart after the first one?)

OVERVIEW - this lecture will talk about: sessions, login, cookies, personalization, single sign-on

let’s talk about TCP SESSIONS for a few min. this is just a parallel for the rest of the lecture, not the actual topic. you gotta find the server, set up a TCP connection, and then work with HTTP to get data. IN THE PAST: 1 TCP connection per HTTP request. people observed that the cost of setting up / tearing down each TCP connection was too high, since there were a lot of requests happening. NOW: you set up a TCP connection and leave it up for multiple HTTP requests. HOW LONG to keep the TCP connection alive? can’t have it for too long, because it’s not free. it doesn’t cost any bandwidth when you have a connection up but are not sending anything. it costs bandwidth if you are sending stuff. HOWEVER, it costs storage (buffer) for it being connected a long time - you have to keep buffers around for re-ordering data.

SESSIONS (user session is how a website saves everything in your cart) a server must track many sessions at once PUT A SESSION PROTOCOL on top of a stateless HTTP. this is implemented at app-layer, session-variables server session model: sessions like files, or call-stack frames: you have attr/value pairs like name=mike; numEmails=20.

Server issues: when to create + close sessions? // how to link HTTP requests to a session? // how to link sessions to users? // how to store session data?

http request triggers a session init or a load session from storage http response to client triggers the deallocation of a session

Ending a session: we can’t rely on logout timeouts are needed for almost all apps

Request-to-session mapping! one approach: URL encoding: http://google.com/search?q=hello servers usually have really long session IDs so that it’s hard to hack into someone else’s session by typing in a new one and get it right. Also, the server will put in a barrier url in place so that you’d have to log in first before accessing a different session.

check out lecture notes for exact client ←---> server login authentification

COOKIES small files on client machine carry state between HTTP requests attr/val pairs, just like URL params set by server, not requested sent by client, but never edited either side can delete / ignore cookies cookies have expiration dates - but they’re advisory