From URL to Page: What Happens When You Open a Web Address?

_Locale: en-US · Lesson: WEBF-001 · Public order: 28_

Outcome and working artifact

This lesson produces a Web Navigation Journey Record v1: a decision artifact that separates observations, assumptions, limits, and required evidence. The goal is a transferable model, not memorized tool names.

Given an unfamiliar web-navigation scenario, explain a bounded request/response and rendering flow, place each responsibility at browser/network/server boundaries, and state what the model does not prove.

Boundary model

Typing a URL looks like one action, but responsibility crosses several boundaries: URL interpretation, optional name resolution, connection setup, HTTP exchange, resource discovery, and browser rendering. The useful model is not a mandatory packet trace. It is a bounded map that says what may happen, who owns each step, and which observations would confirm the path taken in one concrete navigation.

Keep three labels throughout the work: observed, bounded inference, and needs verification. When evidence is unavailable, record unknown. A product name or a passing happy path is not a substitute for evidence.

1. A URL is an instruction, not the page

The browser parses scheme, host, port, path, query, and fragment. A fragment is normally handled by the client and is not sent as part of the HTTP request target. The URL identifies what to navigate to; it does not guarantee where bytes will come from.

2. Name resolution is conditional

The host may already have a usable address in a local or intermediary cache. A resolver may be consulted, but a fresh DNS lookup is not a universal first step. Record name resolution as a responsibility and annotate whether it was observed, cached, or unknown.

3. The response may come through intermediaries

A browser can reuse a connection, consult an HTTP cache or service worker, follow a redirect, or reach a CDN or proxy before an origin. 'The browser talks directly to the origin' is therefore a claim that needs evidence, not a default truth.

4. One document can trigger many fetches

After receiving HTML, the browser parses it and may discover stylesheets, scripts, fonts, images, and module dependencies. Those resources can have different cache states, origins, priorities, and failure modes.

5. Protocol success is not product correctness

A 200 status says that an HTTP request received a successful response in protocol terms. It does not prove that the right user data was shown, that scripts ran, that accessibility is sound, or that the final interface satisfies its requirement.

Five-step method

1. Parse the URL and separate browser-only state from the network request target.
2. List conditional pre-request work: policy checks, cache lookup, service-worker handling, name resolution, connection and TLS state.
3. Record the HTTP request and every redirect as separate exchanges instead of compressing them into one arrow.
4. Trace the document response, parsing, dependent resources, script execution, layout, paint, and later updates as distinct responsibilities.
5. Finish with non-claims: identify what the trace cannot establish without DevTools, server logs, cache evidence, or application-level checks.

Worked case

A learner opens https://docs.example.test/start#install. The first response is a 302 to /guide; the redirected HTML is served from an intermediary cache, while one stylesheet is freshly fetched and an image is reused locally. The fragment selects a heading after the document is available. The defensible explanation records the redirect, the observed cache states, and the separate resource requests. It does not invent a fresh DNS lookup or claim that the origin served the HTML. If DevTools only shows the current navigation, those limits belong in the record.

Decision and evidence matrix

Failure probes and repair

• Every navigation performs a fresh DNS lookup.
• Every request reaches an origin server directly.
• A 200 response proves the application is correct.
• This split-curriculum page does not claim ownership of the complete WEB-000 Web Mental Model.

For each statement, narrow the claim, create a counterexample, and name the observation that could confirm or reject it.

Transfer challenge

Change the scenario so that one assumption in the worked case no longer holds. Rebuild the Web Navigation Journey Record v1 without copying the earlier decision, then explain what changed in the input and what stayed stable in the decision rule.

What this does not prove

This lesson does not claim certification, production guarantees, or coverage of every implementation. Its conclusion is valid only within the scenario boundary, dated sources, and recorded observations.

Self-check

• [ ] Did I separate responsibilities from framework or tool names?
• [ ] Did I state at least one failure probe and its predicted observable?
• [ ] Are fact, inference, and design choice visibly separated?
• [ ] Did I record non-claims and missing evidence?
• [ ] Did I complete transfer in a changed context without a prepared answer?

Sources and freshness boundary

Sources were reviewed for the frozen Bible as of 2026-09-19. A review_due date triggers a versioned requalification; it does not authorize silent in-place edits.

• S-MDN-WEB — High-level client/server, DNS and HTTP navigation model. (https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works; review: 2026-12-31)
• S-WHATWG-DOC — HTML Document and URL semantics; not a universal browser implementation trace. (https://html.spec.whatwg.org/multipage/dom.html; review: 2026-12-31)