After a successful login POST to /auth, the browser ends up on /dashboard. What instructed it to go there?

Question

Accepted Answer

The /auth response was an HTTP redirect — a 3xx status (typically 302) with a Location: /dashboard header that the browser follows automatically.

* Post/Redirect/Get: a 302 turns the login POST into a clean GET. *
This is the POST-Redirect-GET pattern. Instead of returning the dashboard HTML directly in the POST response, the server replies:
HTTP/1.1 302 Found
Location: /dashboard
Set-Cookie: session=abc123...

The browser sees the Location header and immediately issues a fresh GET /dashboard (now carrying the new session cookie).
Why bother? It stops the browser from re-submitting the login POST if the user hits refresh or back (no accidental double-submits), and it gives a clean, bookmarkable dashboard URL.
Tip: Whenever a form submit lands you on a different, "GET-able" page, look for a 3xx + Location in the POST response — that's the redirect doing its job.
Go deeper:

MDN: 302 Found — how a 3xx + Location header makes the browser auto-GET the new page.
 Post/Redirect/Get (Wikipedia) — the named pattern and why it stops duplicate form submits on refresh.