Nearly everything on the web is one exchange, repeated: a client asks for an address, a server answers with a status, headers and usually a body, and the browser decides what to do with it. Most baffling web bugs misread that exchange — state the server never received, a response the browser fetched but refused to let your code read, a check that ran on the wrong side of the wire. This guide is its shape: what an address names, what happens between a URL and a finished page, how state survives a protocol with no memory, and which decisions the client cannot make.
Each chapter opens with the short version. Tap one to read the detail.
What an address actually names
~2 min
Six parts, two of which settle security arguments: an origin is scheme, host and port together, so a different port is a different origin — and the fragment after # never leaves the browser.
One request, one answer, and no memory of you
~2 min
The server keeps nothing between two requests. So the method is a public promise about what repeating one does, and the status code is a contract the rest of the stack acts on without asking you.
Headers decide how the body is read
~2 min
A body is just bytes. The headers say what those bytes are, who they were chosen for, and how long the answer may be reused — and getting the middle one wrong serves one visitor another's page.
Keeping state on a protocol with no memory
~2 min
A cookie is the one piece of browser state that rides on every matching request — which is why its scoping is looser than an origin. Everything else you store never leaves the client unless your code sends it.
The policy, and the thing everyone blames for it
~2 min
The browser will happily send your cross-origin request; what it withholds is the response. The permission headers let a server grant a read, are enforced only inside browsers, and are not an access-control system.
The head is read before anything appears
~2 min
Two lines at the top decide how the rest is interpreted: the doctype picks the rendering mode, and the encoding declaration must be found inside the first 1024 bytes. After that, the element you pick is behaviour, not decoration.
Forms, and the side of the wire validation must live on
~2 min
A form's contract is small and unforgiving: only named controls are submitted, the encoding decides whether a file can travel, and type changes what counts as valid. The browser's own checks are a courtesy to honest users, nothing more.
The tree is not your HTML
~2 min
The browser parses your markup once into a tree; from then on the tree is the truth and view-source stays frozen. Two habits cause most bugs here: assuming a collection is a snapshot, and using innerHTML where text was meant.
How an event travels, and where to listen
~2 min
An event runs down to its target, fires there, then travels back up — three phases, not one. Nearly every event bug confuses where something started with where you are listening, or delegates an event that never bubbles.
The page's timeline, and what a simulated navigation costs
~2 min
DOMContentLoaded means the document is parsed, not that the page is ready; load waits for everything and is usually the wrong hook. And a page can come back from the back button without loading at all.
Asking the server from script
~2 min
fetch resolves for a 500 as cheerfully as for a 200, sends no cookies cross-origin by default, and hands back a body you may read exactly once. Underneath, a service worker can sit as a proxy you install.
Written by Keentune. We are not affiliated with or endorsed by the organizations whose documentation informs this guide, and any linked sources belong to their respective owners.
All exam, test, and product names and trademarks are the property of their respective owners and are used here for identification and reference only. Keentune is independent study practice — not affiliated with, authorized, or endorsed by any of these organizations.