HTTP on the Wire: Methods, Status Codes & Headers

In one line

HTTP is a text conversation: the client sends a request line, headers, and an optional body; the server answers with a status line, headers, and a body. Read one raw exchange and every API, proxy, and load balancer becomes easier to debug.

0/5 · 0%

Think of it like this

HTTP is like ordering at a counter with a form. The REQUEST says what you want (method + path), adds details on sticky notes (headers), and sometimes attaches a parcel (body). The RESPONSE comes back with a verdict stamp (status code), its own sticky notes, and the goods.

Key ideas

01
A request: GET /api/products?q=mug HTTP/1.1, then headers like Host: shop.example.com (which site on this IP; required in HTTP/1.1 and how one load balancer serves many domains), Accept: application/json, Authorization: Bearer ..., then a blank line and the optional body.
02
METHODS and their meaning: GET (read, no body, safe and idempotent), POST (create or trigger an action; NOT idempotent, so retrying may create duplicates), PUT (replace a resource; idempotent), PATCH (partial update), DELETE (idempotent), HEAD (headers only, handy for health checks), OPTIONS (what's allowed; used by browser CORS preflight). Idempotency matters for retries in load balancers, service meshes, and clients (Observability course, retry storms).
03
STATUS CODES by class: 1xx informational (101 Switching Protocols for WebSockets); 2xx success (200 OK, 201 Created, 204 No Content); 3xx redirects (301 permanent, 302/307 temporary, 304 Not Modified for caching); 4xx CLIENT errors (400 bad request, 401 not authenticated, 403 not allowed, 404 not found, 409 conflict, 429 too many requests); 5xx SERVER errors (500 bug, 502 Bad Gateway = the proxy got a bad/no response from upstream, 503 unavailable/overloaded, 504 Gateway Timeout = upstream too slow).
04
502/503/504 tell you WHERE to look: they're usually generated by a proxy or load balancer (Nginx, ALB, ingress) about its UPSTREAM. 502 → upstream crashed or closed the connection; 503 → no healthy upstream or it's shedding load; 504 → upstream exceeded the proxy's timeout (Phase 5).
05
Important headers: Content-Type and Content-Length, Location (redirect target), X-Forwarded-For / X-Forwarded-Proto / Forwarded (the original client added by proxies), User-Agent, Retry-After (with 429/503), and request IDs such as traceparent (Observability course, trace propagation).

Code & diagrams

a raw exchange with curl -vbash

Lines starting with > are what curl sent; < are what the server returned.

$ curl -sv http://localhost:8080/api/products/42 -o /dev/null
> GET /api/products/42 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.9.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 87
< Cache-Control: max-age=60
< Date: Sun, 27 Sep 2026 06:10:02 GMT

status codes by who produced themdiagram

Rendering diagram…

Explain it without notes

What's the difference between 401 and 403?

Why is it dangerous for a proxy to automatically retry POST requests?

Practice

Users see intermittent 504s from the ALB on /reports, while other endpoints are fine. What do you check?

Trade-offs

↔
Precise status codes help clients and monitoring (alerts on 5xx vs 4xx), at the cost of more design thought than returning 200 with an error in the body. Always prefer correct codes; SLOs usually count 5xx as errors and 4xx as client mistakes.

Done when you can

I can read a raw request/response in curl -v output
I know which methods are idempotent and why that matters for retries
I can tell from 502/503/504 which hop to investigate