Gyaan

HTTP Deep Dive

beginner http status-codes http-methods headers http2

HTTP is the language clients and servers speak. In simple language — it’s a set of rules for “here’s what I want” and “here’s what you get”. Let’s nail the parts interviewers poke at.

Request & response anatomy

Every HTTP message has the same shape: a start line, headers, a blank line, then an optional body.

POST /orders HTTP/1.1        <- method, path, version
Host: api.shop.com           <- headers
Content-Type: application/json
                             <- blank line separates headers from body
{ "item": "book", "qty": 2 } <- body

The response mirrors it — a status line, headers, blank line, body.

HTTP/1.1 201 Created
Content-Type: application/json
Location: /orders/42

{ "id": 42, "status": "confirmed" }

The methods

Each method is a verb — what we want to do with the resource.

  • GET — read something. No body, shouldn’t change anything.
  • POST — create something new, or “run this action”. Not repeatable safely.
  • PUT — replace a resource entirely at a known URL.
  • PATCH — partially update a resource (just the fields we send).
  • DELETE — remove a resource.

Two words that come up constantly:

Safe means the method doesn’t change server state — GET is safe, we can call it all day and nothing happens. Idempotent (fancy word, plain meaning) means calling it once or ten times lands the same final result. GET, PUT, DELETE are idempotent — deleting order 42 twice still leaves it deleted. POST is not — POST twice and you might create two orders. That’s the whole reason double-clicking “Buy” can be dangerous.

Status codes — the families

The first digit tells us the category. In simple language: 1xx = hold on, 2xx = worked, 3xx = go elsewhere, 4xx = you messed up, 5xx = we messed up.

1xx Informational — request received, still processing. Rare in app code.
2xx Success — 200 OK · 201 Created · 204 No Content
3xx Redirect — 301 Moved Permanently · 302 Found (temp) · 304 Not Modified
4xx Client error — 400 · 401 · 403 · 404 · 409 · 422 · 429
5xx Server error — 500 · 502 · 503

The ones worth memorizing cold:

  • 200 OK — generic success (GET with a body).
  • 201 Created — POST made a new resource; include a Location header.
  • 204 No Content — success but nothing to send back (a DELETE, say).
  • 301 vs 302 — 301 is permanent (browsers cache it, SEO moves), 302 is temporary.
  • 304 Not Modified — “your cached copy is still good” (see ETag below).
  • 400 Bad Request — the request itself is malformed.
  • 401 Unauthorized — we don’t know who you are (missing/bad credentials).
  • 403 Forbidden — we know who you are, you’re just not allowed.
  • 404 Not Found — no such resource.
  • 409 Conflict — the request clashes with current state (duplicate signup, version conflict).
  • 422 Unprocessable Entity — syntax is fine but the data fails validation.
  • 429 Too Many Requests — you’re rate-limited, slow down.
  • 500 Internal Server Error — our code threw and we didn’t handle it.
  • 502 Bad Gateway — a proxy got a garbage response from upstream.
  • 503 Service Unavailable — server is down/overloaded, try later.

The 401 vs 403 and 502 vs 503 pairs are favorite trick questions. 401 = “who are you?”, 403 = “no.” 502 = “the server behind me is broken”, 503 = “I’m alive but can’t serve right now.”

Headers worth knowing

Headers are the metadata bolted onto every request and response.

  • Content-Type — what the body is (application/json, text/html).
  • Accept — what the client wants back (content negotiation).
  • Authorization — credentials, usually Bearer <token>.
  • Cache-Control — caching rules (max-age=3600, no-store).
  • ETag — a fingerprint of a resource. The client sends it back as If-None-Match; if it still matches, the server replies 304 and skips resending the body. Saves bandwidth big time.

HTTP/1.1 vs 2 vs 3

Same HTTP semantics (methods, status codes), different plumbing underneath.

HTTP/1.1 opens one request at a time per connection. Send a request, wait for the response, then the next. That waiting is head-of-line blocking — one slow response stalls everything behind it. Browsers hacked around it by opening ~6 connections per host.

HTTP/2 adds multiplexing — many requests share one TCP connection, interleaved as independent streams. Plus header compression and server push. Big win. But there’s a catch: it still rides on TCP, so a single lost packet stalls all streams (head-of-line blocking moved down to the TCP layer).

HTTP/3 fixes that by ditching TCP for QUIC, a protocol built on UDP. Streams are truly independent, so one lost packet only stalls its own stream. QUIC also folds the TLS handshake into the connection setup, so connecting is faster.

HTTP/1.1
1 request at a time per connection · app-level head-of-line blocking · over TCP
HTTP/2
multiplexed streams · header compression · still over TCP (TCP-level blocking)
HTTP/3
QUIC over UDP · independent streams · TLS baked in · fastest setup

Interview soundbite

HTTP is a request-response text protocol. Methods are verbs (GET reads, POST creates); GET/PUT/DELETE are idempotent, POST is not. Status families: 2xx worked, 3xx go elsewhere, 4xx client’s fault, 5xx server’s fault — know 401 (who are you) vs 403 (not allowed) and 502 vs 503. HTTP/2 added multiplexing over one TCP connection; HTTP/3 moved to QUIC on UDP to kill TCP-level head-of-line blocking.

References