Demo: reading real HTTP traffic in the browser
On This Lesson 11 topics
Lesson Overview
For six lessons you have read about requests and responses on paper. In this demo you open the kitchen door and watch real order slips go in and real dishes come out. Your browser records every request it makes, and its developer tools let you inspect each one: the method, the URL parts, the headers, the status, and the body.
The demo follows a short routine, uses one deliberate mistake that almost every beginner makes (looking only at the first request), and ends with an annotation table that is exactly the format of the lab, BEG-052-LAB1. It brings together every earlier lesson in this module and builds on BEG-003's first look at the Network panel.
Menu names, shortcuts, and layout differ between browsers, versions, and operating systems and they change over time. We describe the Chrome-family layout, as documented by Google, and tell you to look for the equivalent elsewhere. If something does not match your screen, search for "open Network tab" with your browser's name.
Learning Objectives
By the end of this lesson you will be able to:
- Open the Network panel, record a page load, and find the request you want.
- Read the method, status, and URL of a request in the request list.
- Find the request and response headers of one request and name three that matter.
- Filter the list to the data (API) requests and read a JSON response.
- Annotate a request in a table: method, URL parts, key headers, status, and body type.
- Avoid the mistake of judging a page from only its first request.
Written Explanation
The routine
- Open the tools first. Chrome's documentation gives
Ctrl+Shift+J(Windows and Linux) orCommand+Option+J(macOS) to open DevTools, then you choose the Network tab. Other browsers have a similar panel, sometimes under another name. DevTools records only while it is open, so open it before the page loads. - Reload the page. The list fills with one row per request, usually starting with the main document.
- Click one row. The Headers tab opens by default. Chrome's reference describes sections for general information (including the status), response headers, and request headers.
- Look at the body. The Response tab shows the body as text. Preview shows a prettier view, which is most useful for images and some other types.
- Filter. Chrome offers type buttons including All, Fetch/XHR, JS, CSS, Img, and Doc. Fetch/XHR keeps the requests that a page's scripts make to load data, which is where JSON usually shows up. There is also a text filter box that matches the URL.
- Show the columns you need. The Method column is optional in Chrome; right-click the table header to show it, along with Status and others.
Because the panel can show cookies and tokens for sites you are logged in to, use a simple public page for practice and never share screenshots with Authorization or Cookie values (see lesson 4).
Reading one request, part by part
When you click a row, find these items and match them to the earlier lessons:
| What to find | Where | Lesson |
|---|---|---|
Method (GET, POST, ...) | Method column, or the request summary | 2 |
| URL: scheme, host, path, query | The request URL in the General section | 6 |
| Status code and class | Status column, General section | 3 |
Request headers (Host, Accept, ...) | Request Headers section | 4 |
Response headers (Content-Type, ...) | Response Headers section | 4 |
| Body | Response tab; the Payload tab shows query parameters and form data sent by the request | 5 |
The Content-Type response header tells you the body type: text/html for a page, application/json for data, image/... for pictures. That is why this header is part of every annotation.
Why a page makes many requests
A single page load usually triggers many requests: one for the HTML, and more for stylesheets, scripts, images, and often calls to a backend that return JSON. Your future backend answers requests of the last kind. The trick is to find those among the others, and the filter does that.
Examples
Example 1: The simplest page (simple)
Open https://example.com in a fresh tab with the Network panel already open, then reload.
- You will see one main document request (and perhaps a few more, depending on your browser).
- Click the first row. Expected: the method
GET, a status in the 2xx class (typically200), a responseContent-Typeoftext/html, and the body in the Response tab as HTML.
A test of understanding: which header told the browser to treat the body as a page rather than as data?
The exact rows and headers you see depend on your browser and on the site's current setup.
Example 2: A redirect (practical)
Type http://example.com (with http) and watch the first rows. Some sites answer the first request with a 3xx status and tell the browser to go to the https address; the next row is then a request to the new URL, usually ending in a 2xx. Click the 3xx row and look in the response headers for a header that holds the new address (a Location header is the usual one). If your browser or the site does not redirect, you will see just one row; that is not an error, it only means the site does not do this.
The lesson: a status in the 3xx class is not a failure, it is an instruction. The lab expects you to say "redirect" for those rows, not "error".
Example 3: Finding the data request (realistic)
Choose a public site that updates its content without reloading the whole page, such as a page with a search box that suggests results while you type, or a news page with a "load more" button. Open the Network panel and use the page: type in the search box or click the button.
- New rows appear when you act. Switch the filter to Fetch/XHR.
- Click a row whose URL looks like data (often with a path such as
/api/...or a query like?q=). - Read its headers: the method is probably
GET, the query parameters carry what you typed, and the responseContent-Typeis probablyapplication/json. - Open the Response tab and read the JSON: objects with keys, arrays of results, numbers, strings. Map one object to a Java class in your head (lesson 5).
This is the exact conversation your backend will have with a front end. Names and layout of real sites change, so I cannot give you a fixed example URL; the steps work on any site that loads data this way.
The planned mistake
A learner opens a page, looks at the first request only, sees a 200 and an HTML body, and concludes "this site has no API". They missed the actual data requests, which only appear in later rows or after a click. The fix: filter by Fetch/XHR, or type a word of the URL in the filter box, and use the page while recording.
The annotation table for the lab
For each request, fill one row. Example (illustrative values; yours will differ):
| Field | Value |
|---|---|
| Method | GET |
| URL parts | Scheme https; host example.com; path /; query none; fragment none |
| Key request headers | Host, Accept |
| Status and class | 200, success (2xx) |
| Key response headers | Content-Type: text/html |
| Body type | HTML document |
Backend Insight
Everything you build later can be checked in this panel. When a front end says "your API is broken", open the Network tab and answer four questions: what method and URL did the browser send, what status came back, what headers were sent and returned, and what was in the body. Most arguments end there, because the panel shows what really crossed the wire rather than what anyone assumed.
It also builds a sense of normality. A healthy page load has a mix of 2xx, some 3xx, and a few cached files. A request with a 4xx or 5xx stands out immediately, and the class tells you whether to look in the front end (4xx: the request was wrong) or the backend (5xx).
Common Mistakes
Mistake 1: Opening DevTools after the page has loaded
- Incorrect: loading the page, then opening the panel and finding it empty.
- Correct: open the panel first, then reload, as BEG-003 taught.
Mistake 2: Judging by the first request only
- Incorrect: "The first row is HTML, so the site makes no API calls."
- Correct: use the Fetch/XHR filter and interact with the page.
Mistake 3: Treating every non-200 as an error
- Incorrect: labelling a
301,302, or304row as an error. - Correct: 3xx means redirect or "use your cached copy"; only 4xx and 5xx are errors.
Mistake 4: Sharing headers that contain credentials
- Incorrect: posting a screenshot with
CookieorAuthorizationvisible. - Correct: practise on public pages and blur or remove sensitive values.
Exercises
Level A: Foundation
A1. List the steps to capture a page load in the Network panel, in order.
Show solution A1
A1. Open DevTools and the Network tab; reload (or use) the page; click a request; read the Headers; read the Response; filter if needed.
A2. Where in the panel do you find the status code, and which header gives the body type?
Show solution A2
A2. The Status column or the General section of the Headers tab. The Content-Type response header gives the body type.
A3. What does the Fetch/XHR filter keep?
Show solution A3
A3. The requests made by scripts to load data (fetch and XHR), where JSON usually appears.
Level B: Application
B1. You see a row: method GET, status 404, URL https://site.example/img/logo.png. Annotate it: class, whose side the problem likely is, and what you would check next.
Show solution B1
B1. Class: client error (4xx). The resource was not found; most likely the URL is wrong or the file was removed. Check the URL spelling and whether the file exists on the server.
B2. A row has status 304. Is that an error? Explain what it means (lesson 3).
Show solution B2
B2. No. 304 Not Modified is in the 3xx class and means the browser's cached copy is still valid and can be reused.
B3. A page seems to show live prices, but the first request is only an HTML file. Describe how you would find the request that fetches the prices and what you would expect its Content-Type to be.
Show solution B3
B3. Reload with the panel open and use the Fetch/XHR filter (or type part of the URL in the text filter), then click the likely row. Expect application/json, though it is not guaranteed.
Level C: Challenge
C1. Write the annotation row for this made-up request: POST https://api.example.com/loans?notify=true, request header Content-Type: application/json, status 201, response header Location: /loans/31, response body {"id":31}. Split the URL parts and name the body type.
Show solution C1
C1.
| Field | Value |
|---|---|
| Method | POST |
| URL parts | Scheme https; host api.example.com; path /loans; query notify=true; fragment none |
| Key request headers | Content-Type: application/json |
| Status and class | 201, success (2xx) |
| Key response headers | Location: /loans/31 |
| Body type | JSON, an object {"id":31} |
C2. A teammate says "my API returns 500 whenever the browser sends GET /books/abc". Using the panel, what would you check to decide whether the server or the request is at fault, and what status would you argue is more accurate?
Show solution C2
C2. Check the request (method, URL, and whether abc is valid for an id), the status, and the response body for an error message. abc is not a valid numeric id, so the fault is in the request: 400 (or arguably 404) is more accurate than 500. A 500 suggests the server crashed while parsing the id, which is a server bug (it should validate input and answer with a 4xx).
Mini Challenge
This is a warm-up for BEG-052-LAB1. Pick one simple public site. Capture and annotate two requests: one HTML document and one other request (an image, script, or data call). Fill in the annotation table for each, then add one sentence on how you could tell which was which from a header.
Check your work: every field is filled; the URL parts are correct; the status class is named; the body type matches the Content-Type; no credentials appear in your notes.
Summary & Next Lesson
Key takeaways
- Open the Network panel first, then reload; one row is one request.
- The Headers tab shows method, URL, status, request headers, and response headers; the Response tab shows the body.
- Filter with Fetch/XHR to find the data (JSON) calls; the first request is rarely the whole story.
- 3xx rows are redirects or cache hits, not errors; 4xx and 5xx are errors.
- Annotate each request with method, URL parts, key headers, status, and body type.
Next lesson
You have finished the lessons of this module. Next comes the lab BEG-052-LAB1, "Read real traffic": capture five requests from a real site and annotate each one with the table from this lesson.
Self-check
- Why open DevTools before loading the page?
- Which filter shows the data requests made by a page's scripts?
- Which header gives the body type?
- Is a
301row an error? - Which four things does the lab ask you to label besides the body type?
Show answers
- DevTools only records while open, so a late opening shows nothing.
- Fetch/XHR.
Content-Type.- No, it is a redirect.
- Method, URL parts, key headers, and status.
References
- Chrome for Developers: Inspect network activity. Supports the shortcut to open DevTools, the need to open it before loading, reloading to populate the log, the Headers tab opening by default, and the Preview and Response tabs.
- Chrome for Developers: Network features reference. Supports the type filters including Fetch/XHR, the text filter, the Headers sections (General, Response Headers, Request Headers), the Payload tab, the optional Method column, and the Status column.
- MDN: HTTP response status codes. Supports the meaning of 3xx, 304, 400, 404, and 500.
Not verified: I did not run the browser demo, so Examples 1 to 3 describe typical results, not captured output. Firefox and Safari menus were not checked.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.