Learning Labs / HTTP Learning Lab
Follow every request. Find the why.
Trace requests, explore responses, and understand caching and browser origin rules.
Lesson 01 / Build your understanding
Read a request
Identify what each part of a request tells the service and distinguish a URL from an origin.
01 / Concept
Start with the idea.
A request combines a target URL, a method, headers, and sometimes a body. In the HTTP/1.1 view, GET /notes/42 HTTP/1.1 is the request line: GET chooses the operation and /notes/42 identifies the resource.
The URL's scheme, hostname, and port define its origin. Changing /notes/42 to /notes does not change the origin; changing studio.example to api.example does. The Host header identifies the target host, while Origin identifies the requesting page in this cross-origin example.
Read the reasoning
Headers describe the message and requested behavior. Accept: application/json requests a response format; Content-Type describes the format of a submitted body. Not every request has a body. The lab uses GET without one.
The readable cards use HTTP/1.1 syntax. HTTP/2 and HTTP/3 encode fields differently, but retain these request and response semantics. The service URLs shown are example fixtures, not destinations to visit.
Key terms
- Resource
- The target of a request, such as a note or note collection.
- Origin
- A scheme, hostname, and port tuple. Paths are not part of the origin.
- Representation
- A resource's data in a chosen format, such as JSON.
02 / Predict
What do you expect?
Follow the notes service.
Change a request, step through the decisions, and explain the outcome.
Service CORS policy Same-origin; CORS does not apply
A missing Allow-Methods header blocks PUT, PATCH, and DELETE here. GET and POST are safelisted methods; their non-safelisted headers still need permission.
Saved response & cache GET note fixtures only
The service currently stores revision 2. A saved revision 1 can still be fresh by its age rule. This cache exercise assumes a reusable saved response, including valid origin permission; it does not model Vary matching or cache invalidation.
Step 1 of 4 / Browser
Build the request
GET targets https://studio.example/notes/42. The page origin is https://studio.example. These origins match, so CORS does not limit reading this response. This request has no body in this fixture.
Step through to compare the actual HTTP result with the browser's read permission. Changing a setting restarts the trace.
What this example includes
The bundled notes service accepts GET and POST on its collection, and GET, PUT, PATCH, and DELETE on individual notes. Each configuration starts with a fresh fixture snapshot; “send twice” demonstrates repeated effects within that snapshot.
The trace uses an HTTP/1.1 text view, a cold preflight cache, one response per request, and no redirect following. Fresh-cache examples assume an eligible saved response. TLS, network timing, automatic retry, cache invalidation, cookie eligibility, and CORS header exposure are outside this exercise.
The credentials checkbox represents include mode. A real browser controls Cookie; script cannot set that header manually. A valid example login is a separate authentication fixture.
05 / Practice
Put the idea to work.
06 / Recap
Take the lesson with you.
- Separate the target URL, method, headers, and body.
- Compare scheme, hostname, and port to determine origin.
- Accept concerns the response; Content-Type concerns the message carrying that header.
Check your prediction and solve a practice challenge to complete this lesson.
References & further reading
Keep your curiosity going.
More Learning LabsLoading more Learning Labs…