Methods, Status Codes and the Second Request
A redirect, and what a status code obliges the client to do
Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.
What you'll be able to do
- ▸Read a status code by its class before its number
- ▸Explain what a 3xx obliges a client to do and what it does not
- ▸Say why caching and conditional requests are part of HTTP rather than bolted on
Before this lesson — it builds directly on:
HTTP has to work between a client and a server written by people who have never met, in different languages, decades apart. That only works if the meanings are fixed in advance.
So the method says what kind of operation this is, and the status code says what happened, and both are drawn from a small agreed set. A client that has never heard of a particular status code can still handle it correctly by reading the first digit — which is exactly why the classes exist rather than a flat list of numbers.
- Safe
- A method that does not change anything. GET and HEAD are safe, which is what lets a cache serve one from memory and a browser prefetch one speculatively.
- Idempotent
- A method where doing it twice has the same effect as doing it once. PUT and DELETE are idempotent; POST is not, which is why a browser warns before re-submitting one.
- Conditional request
- A request carrying a validator — a date or an ETag — that asks the server to send the body only if it has changed. A 304 answers 'it has not' with no body.
✓ Concept check — before you open the packets
These test the idea, not the trace. You should be able to answer them from the explanation above.
Now that you understand the concept, observe how it appears in the packet exchange.
The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.