Theory
The web forgets you instantly
Here is an awkward truth about the web: HTTP is stateless. Each request stands completely alone; the server does not naturally remember anything about the previous one. So after a student logs in to FestConnect and clicks to the next page, the server has, by default, no memory that they are logged in at all.
That cannot stand, apps must remember who you are, what is in your cart, what you picked. The set of techniques for remembering data across requests is called state management, and this lesson surveys the main ones.
Theory
Two places to keep state
State can live in two places, and the split is the key to the whole topic.
Client-side state is stored in the visitor's browser or URL, and travels back and forth with each request: cookies (small key-value data the browser stores and re-sends), the query string (values in the URL after a ?), hidden fields, and view state (a page's own control values, preserved across postbacks).
Server-side state is stored on the server and merely referenced by the browser: session state (data for one particular user) and application state (data shared by all users).
At a glance
| Technique | Where stored | Reach and typical use |
|---|---|---|
| Cookie | Browser (client) | Small per-user data across visits (e.g. 'remember me') |
| Query string | The URL (client) | Pass a value between pages (e.g. ?eventId=12); visible, not for secrets |
| View state | The page itself (client) | Preserve a page's control values across its own postbacks |
| Session | Server, per user | Who is logged in, a cart; lasts the user's session |
| Application | Server, shared | Data common to everyone (e.g. a visitor counter) |
Formula
Client-side vs server-side state
Client-side (cookies, query string, view state): the data rides along in the browser or URL. It costs the server no memory, but it is visible or reachable by the user, so never put secrets or things the user must not tamper with there.
Server-side (session, application): the data stays safely on the server; the browser only holds a small id that points to it. It is more secure and can hold more, but it uses server memory. Choose by sensitivity and size: small and harmless can go client-side; private or important belongs server-side.
Practical
Session (per user) and a cookie
// SERVER-SIDE: remember the logged-in student for this user's session
Session["studentName"] = txtName.Text;
// ...on a later page, read it back:
string who = Session["studentName"] as string;
// CLIENT-SIDE: store a small preference in a cookie for 30 days
var prefs = new HttpCookie("theme", "dark");
prefs.Expires = DateTime.Now.AddDays(30);
Response.Cookies.Add(prefs);
// Read a value passed in the URL (?eventId=12)
string eventId = Request.QueryString["eventId"];Quiz
You need FestConnect to remember which student is logged in as they move between pages, kept securely on the server. Which technique fits best?
- The query string, putting the student's name in every URL
- Session state, which stores per-user data on the server for the duration of their session
- A cookie holding the student's password
- Application state, because it is shared by all users
Show the answer
Session state, which stores per-user data on the server for the duration of their session
Session state stores data for ONE particular user on the SERVER and persists across their requests for the length of their session, which is exactly right for 'who is logged in'. Option A is poor: the query string puts data in the URL, which is visible, easily edited, and clutters every link, wrong for identity. Option C is dangerous: never store a password in a cookie; cookies live in the browser and can be read or stolen. Option D is wrong: application state is SHARED by all users, so it cannot hold one specific user's identity, it would be the same value for everyone. Per-user and private -> server-side session.
Think first
Cookie or session: how do you choose?
Both a cookie and session can remember something per user. When do you reach for each? Then tap.
Show the answer
Choose by WHERE the data must live and how sensitive it is. A COOKIE stores the data in the browser, so it survives even after the user closes the site and comes back later (until it expires), and it costs the server no memory, but the user can see and edit it, so it suits small, non-secret preferences like 'remember my theme' or 'remember me'. SESSION stores the data on the SERVER, keyed to that user; the browser only holds a tiny session id, so the real data is private and tamper-resistant, and it can hold larger, richer objects, but it uses server memory and normally lasts only until the session times out or the user leaves. Rule of thumb: harmless, small, and should-persist-across-visits -> cookie; private, important, or larger, and only for this visit -> session. Often they work together: a session id itself is carried in a cookie. Match the mechanism to the data's sensitivity and lifetime.
Summary
Key takeaways
- HTTP is stateless: each request is independent, so apps use state management to remember data across requests.
- Client-side state rides in the browser or URL: cookies (small persistent data), query string (values in the URL), view state (a page's control values across postbacks).
- Server-side state stays on the server: session (per user) and application (shared by all users).
- Client-side costs no server memory but is visible or editable; never put secrets there.
- Server-side is private and can hold more, at the cost of server memory.
- Use session for per-user identity, a cookie for small persistent preferences, the query string only for non-secret values.
- Memory hook: cookies and query string live on the client; session and application live on the server.