Codewise
Menu
Return to Case 02

Request Investigator · DevTools companion

See two requests in your own browser

This educational page loads as one HTML document, then JavaScript sends a separate same-origin request for product data. The endpoint is read-only, uses fixed demo data, and intentionally returns a controlled error.

Educational product page

Desk Lamp

This shell came from the HTML document. Its product data is requested separately by JavaScript.

Waiting for the separate data request… If JavaScript is unavailable, use the static sample evidence below.

Use the Network panel

Find and compare the two requests

  1. Open this page in a regular browser tab.
  2. Open Developer Tools. In Chrome, use the browser menu → More tools → Developer tools; other browsers provide a similarly named developer-tools panel.
  3. Select Network. If the list is empty or you opened it after the page loaded, reload once to capture both requests. Reloading creates a new document request and a new data request.
  4. In the request list, use the Doc filter—or inspect the Type column—to find devtools-page-data with type document. Then use Fetch/XHR to find product-data with type fetch. Filter names vary slightly between browsers.
  5. Select each row and compare its full URL, type, status, response body, and response headers. For product-data, inspect WWW-Authenticate, X-Codewise-Demo, and X-Request-ID.
  6. Use Send the data request again when you want another fetch without reloading the document. The button repeats only product-data.
  7. State what succeeded, what failed, what remains unknown, and which server-side evidence would help next.

Checkpoint

Make a boundary statement

Before opening the note below, answer two questions in your own words:

  • What does the document row prove, and what does the fetch row prove?
  • What server-side cause can the Network panel not establish by itself?
Reveal the browser-evidence boundary note

The browser can observe that the HTML document succeeded and a later JavaScript-initiated request reached a same-origin endpoint that returned 401 with a challenge and fixed demo response. It cannot prove that a real session lookup occurred: this endpoint deliberately returns 401 and does not read a cookie, user account, or session store.

Case 02 adds a clearly labeled illustrative authentication record so you can practise correlating browser evidence with a server-side record. That simulated record is not produced by this live demo.

Cannot use DevTools or JavaScript? Inspect static sample evidence
Expected demo Network evidencetext
GET /learn/request-investigator/devtools-page-data
Type: document
Status: 200 OK
Content-Type: text/html

GET /api/request-investigator/product-data
Type: fetch
Status: 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: DemoSession realm="codewise-devtools"
X-Codewise-Demo: request-investigator
X-Request-ID: cw-devtools-401

The document and fetch are separate HTTP exchanges. A successful document does not establish that the later request succeeded. The 401 identifies the endpoint's response, but this demo alone does not establish a real server-side authentication root cause.

References & further reading

References & further reading2 sourcesPrimary standards and official documentation used for this lesson.
  1. Inspect network activity (opens in a new tab)

    Chrome for Developers

    Network-panel controls and request inspection in Chrome DevTools.

  2. RFC 9110: HTTP Semantics — 401 Unauthorized (opens in a new tab)

    IETF

    The response status and authentication-challenge requirement used by the controlled endpoint.