HTTP, status codes and headers

Once a connection reaches a server, the conversation on top of it is almost always HTTP — the protocol of the web and of nearly every API. As a DevOps person you read HTTP constantly: a status code in a log tells you whether a request succeeded, failed at the client, or crashed the server; a header controls caching, content type, and security. You do not need to implement HTTP, but you must be able to read it fluently. This lesson is HTTP: requests, responses, status codes and headers. (If you took the QA course, this will be familiar — here the emphasis is operational: reading HTTP to diagnose a live system.)

Request and response

HTTP is a simple request/response conversation. The client sends a request; the server sends back a response. A request has:

• A method (verb) — what you want to do: GET (fetch), POST (create/submit), PUT/PATCH (update), DELETE (remove).
• A path — what you are acting on: /transactions/42, often with a query string ?status=pending.
• Headers — metadata: Host, Authorization, Content-Type, and more.
• A body — data sent with POST/PUT (usually JSON).

The response has a status code (below), its own headers, and a body (the HTML, the JSON, the error). That is the whole shape, and every web request you will ever debug is an instance of it.

Status codes: the first thing you read

The status code is a three-digit number saying how the request went, and reading it is the fastest way to understand what happened. They group by first digit:

• 2xx — success. 200 OK, 201 Created, 204 No Content.
• 3xx — redirection. 301 (moved permanently), 302/307 (temporary), 304 Not Modified (use your cache). You will see these when a site redirects HTTP→HTTPS or an old URL to a new one.
• 4xx — the client got it wrong. 400 (bad request), 401 (not authenticated), 403 (forbidden — authenticated but not allowed), 404 (not found), 429 (too many requests — rate limited). A 4xx means the request was rejected on purpose.
• 5xx — the server got it wrong. 500 (internal error — the app crashed), 502 (bad gateway — a proxy could not reach the app behind it), 503 (service unavailable — overloaded or down), 504 (gateway timeout — the app took too long). A 5xx is your problem to fix.

For operations, the crucial split is 4xx versus 5xx. A spike of 4xx usually means clients are doing something wrong (bad requests, expired tokens, hitting a removed endpoint) — or someone is probing you. A spike of 5xx means your system is failing — the app is crashing, a dependency is down, or a proxy cannot reach the backend. When you look at a service's logs or a dashboard, the ratio of 5xx responses is one of the first health signals you check.

Two you will meet often in real infrastructure: 502 and 504 almost always point at the layer between the load balancer/proxy and your app — the app is down (502) or too slow (504), not the proxy itself. Knowing that sends you to the right place immediately.

Headers: the metadata that controls behaviour

Headers are key-value pairs carrying metadata, and several matter operationally:

• Content-Type — the format of the body: application/json, text/html. A wrong content type is a common cause of "the API returned data but the client cannot read it".
• Authorization — credentials, usually Bearer <token> (the API/SSH key ideas again).
• Cache-Control / ETag — how caches (browsers, CDNs) may store the response. Getting these right is much of web performance; getting them wrong causes "I deployed but users see the old version".
• Location — on a 3xx redirect, where to go next.
• Security headers — Strict-Transport-Security (force HTTPS), Content-Security-Policy, X-Content-Type-Options. These harden a site, and you will be asked to set them.
• X-Forwarded-For — when a request passes through a proxy/load balancer, this carries the original client IP (the proxy's own IP is what the app would otherwise see). Important for logging real client addresses.

You do not memorise every header; you learn to look at the headers when debugging and recognise the ones that explain the behaviour you are seeing.

Reading HTTP from the command line

You inspect HTTP directly with curl, and this is a core operational skill:

curl https://riztechacademy.com                    # fetch the body
curl -I https://riztechacademy.com                 # HEAD: just the response headers + status
curl -i https://riztechacademy.com                 # body PLUS the status line and headers
curl -v https://riztechacademy.com                 # verbose: the whole conversation, incl. TLS and request headers
curl -X POST -H "Content-Type: application/json" -d '{"x":1}' https://api.example.com/things

curl -I (headers and status only) is the quick "what is this endpoint doing?" check — you instantly see the status code and key headers. curl -v shows the entire exchange, including which IP it connected to and the TLS handshake, so it doubles as a network debugger (the debugging lesson). When a teammate says "the API is returning an error", the first move is often curl -i against it to see the real status and body, rather than guessing from the UI.

Check your work

Request/response: a request has a method (GET/POST/PUT/PATCH/DELETE), a path (+ query), headers and a body; the response has a status code, headers and a body. Every web debug is an instance of this.

Status codes: 2xx success (200/201/204); 3xx redirect (301/302/304 — HTTP→HTTPS, old→new URLs); 4xx client error on purpose (400/401/403/404/429); 5xx server error — your problem (500 crash, 502 proxy can't reach app, 503 down/overloaded, 504 app too slow). Ops split: 4xx spike = clients/probing; 5xx spike = your system failing. 502/504 point between the proxy and the app.

Headers: Content-Type (body format), Authorization (creds), Cache-Control/ETag (caching — cause of "deployed but users see old version"), Location (redirect target), security headers (HSTS/CSP), X-Forwarded-For (real client IP behind a proxy). Look at headers when debugging.

Read with curl: -I (headers+status only — quick check), -i (body + status/headers), -v (whole exchange incl. TLS — a network debugger), -X POST -d (send data). First move on "the API errors" is curl -i.

Practice

1. Label the parts of an HTTP request (method, path, headers, body) and of a response (status, headers, body).
2. Sort these into 4xx or 5xx and say who is at fault: 404, 500, 401, 502, 429, 503.
3. Explain the operational difference between a spike of 4xx and a spike of 5xx, and where 502/504 point.
4. Use curl -I on a real site and read the status code and three headers; then curl -v and find the IP and TLS lines.
5. Explain how a wrong Cache-Control header can cause "I deployed but users see the old version".
6. Write a curl command that sends a JSON POST with an Authorization header.

Official documentation

• MDN — An overview of HTTP — Requests, responses, methods and headers.
• MDN — HTTP response status codes — The full list, grouped by class.
• curl — Manual / tutorial — Using curl to inspect HTTP.

Next: TLS and certificates, demystified.