Why an avatar that does exactly what it's told still can't get the user what she wants.
A user, blocked from a private dashboard, types the dashboard's exact address directly into the address bar, deliberately trying to skip the login page entirely. The browser, acting exactly as told, asks the server for precisely that address. The server sends back the login page anyway, not the dashboard. The browser did exactly what it was instructed to do. Why didn't getting exactly what was asked for get the user what she actually wanted?
A browser is the user's avatar. It carries out a fixed, narrow set of actions, asking for an address, sending typed-in form values, following a link, and nothing beyond that. It has no way to carry the user's actual identity or permission along with a request unless something else, such as a cookie, is attached to that exact request first. Asking for the dashboard's address told the server only the address. It told the server nothing about who was asking, so the server fell back to its own rule: no proof of login, no dashboard, a redirect to the login page instead.
A browser is the program a user directly interacts with, typing, clicking, scrolling, while a server, somewhere else entirely, is the program that actually does the requested work and decides what to send back.
Calling the browser the user's avatar is a useful way to keep one fact straight: the avatar can only perform the small set of actions it actually has, asking for an address, sending typed values, following a link, regardless of how much more the user might want from a single click.
A request leaving the browser carries only what was actually included in it, an address, maybe some typed values, maybe a stored cookie. It never carries the user's actual wishes, reasoning, or intent directly, only whatever specific pieces of information someone built into that one request.
The server receiving a request has no access to anything happening on the user's side beyond exactly what arrived in that request. It cannot ask a follow-up question or guess at what was really meant, it can only act on the literal request it received.
This track studies the browser's side of that exchange specifically, what an avatar is actually capable of asking for, sending, and showing, before a later track in this curriculum covers what happens on the server's side once a request arrives.
Two requests for the exact same address, with two different results
GET /dashboard HTTP/1.1
Host: example.com
HTTP/1.1 302 Found
Location: /login
GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=abc123
HTTP/1.1 200 OK
Content-Type: text/html
Both requests ask for exactly the same address, /dashboard, using the exact same method, GET. Nothing about the request the browser actually sent differs between the two cases except one detail.
The second request carries a Cookie header, session_id=abc123, attached automatically by the browser because that value was stored from an earlier response. The first request has no such header at all.
A 302 status code, paired with a Location header, is the server's way of telling the browser to ask for a different address instead. The browser receiving this response is what actually causes the visible redirect to the login page.
A 200 status code means the server is sending back exactly what was asked for, with no redirect. This is the result only the request carrying proof of an existing session actually received.
The browser only ever stores and resends session_id=abc123 exactly as it was given. Nothing about it, including whether it still represents a valid, logged-in session, is something the browser itself understands or checks.
The avatar's request and the user's intent are two different things
Typing the dashboard's address directly expresses the user's intent clearly to a person reading it, but the request the browser actually sends contains only that address. The server, reading the request, never receives the intent itself, only the one piece of information the avatar was instructed to ask for.
A missing cookie produces a redirect, not an error
The first request in this lecture's example is not invalid, malformed, or rejected. It succeeds completely, exactly as written, and still results in a login page, because succeeding at delivering the request is not the same thing as succeeding at getting the dashboard.
Whatever was stored earlier gets resent automatically, every time
Once a cookie value is stored, the browser attaches it to matching future requests on its own, without being asked again for that specific request. A user who logged in minutes ago does not have to do anything special for a later request to carry proof of that.
A redirect is followed automatically, without the user clicking anything
Receiving a 302 status with a Location header causes the browser, on its own, to immediately make a brand new request for that different address. Ending up on a login page instead of a dashboard happens without any further action from the user at all.
The server's rule, not the browser's behavior, decided the outcome here
The browser behaved identically in both cases, sending exactly what it was told to send. The entirely different results came from a rule on the server's side, checking for a valid cookie, that the browser itself has no part in and no visibility into.
Assuming the address itself proves who is asking
GET /dashboard HTTP/1.1
Host: example.com
Including the stored proof of an existing session
GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=abc123
When reviewing an AI-described user flow that touches a private page, three things are worth checking. First, does it rely on the browser carrying some kind of stored proof, such as a cookie, on the actual request, rather than assuming an address alone is enough to identify a returning user. Second, does it correctly describe a redirect as something the browser does automatically, rather than as a choice the user makes. Third, does it avoid describing the browser as understanding or evaluating what a cookie means, when in fact only the server does.
Remove the Cookie header from this lecture's second request, and predict what response it would receive instead.
Write what a third request would look like if the user, after seeing the login page, actually logs in successfully partway through.
Explain, in your own words, why a 302 response causes a second request to happen automatically, with no click involved.
Identify which single line differs between the two requests in this lecture's example, and explain why that one line changes everything about the result.
Describe a different situation where a perfectly valid request still receives a result the user did not want, for a reason that has nothing to do with cookies at all.
Assuming a browser understands or evaluates what a cookie value means, when it only stores and resends the exact value it was given.
Treating a redirect as something a user actively does, rather than something the browser does automatically upon receiving a 302 response.
Believing a request that worked, in the sense of receiving any response at all, means it received the result the user actually wanted.
Forgetting that a server has no access to anything beyond the literal contents of one specific request.
Assuming an address by itself can identify a particular returning visitor, when nothing about a plain address carries any proof of identity at all.
You can now explain why a browser sending exactly the request it was told to send can still fail to get the user what she actually wants, and why a redirect happens automatically, with no further action from the user. You can also describe specifically what a request does and does not carry with it, which is the foundation the rest of this track builds on.
