HTTP Fundamentals

1What HTTP Is

HTTP (HyperText Transfer Protocol) is an application-layer, request-response protocol: a client sends a request, a server sends back exactly one response. It is built on top of a reliable transport (TCP, or QUIC for HTTP/3 — see the HTTP Versions topic) and is stateless — the server does not, by default, remember anything about a previous request when handling the next one. Every piece of context (who you are, what's in your cart) has to be re-sent or reconstructed via mechanisms like cookies (see the Cookies and Sessions topic).

Client                              Server
  |------- HTTP Request ----------->|
  |<------ HTTP Response -----------|

2Anatomy of a Request

GET /users/42?include=orders HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Authorization: Bearer eyJhbGciOi...

A blank line separates headers from the body — this is how the parser knows headers have ended, even before reading Content-Length bytes of body.

3Anatomy of a Response

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 58
Cache-Control: max-age=60

{"id":42,"name":"Ada Lovelace","orders":[101,102]}

4HTTP Methods

Safe means the method must not change server state (a GET that increments a view counter is a real-world violation of this, not an exception to it). Idempotent means firing the same request N times has the same effect as firing it once — DELETE /users/42 twice still ends with user 42 gone, so it's idempotent even though it's not safe. PATCH is not idempotent in general because a patch like {"balance": "+10"} (relative, not absolute) applied twice produces a different result than applied once — though a PATCH expressed as an absolute field replacement can be idempotent in practice.

5Status Code Categories

The first digit tells a client (or a proxy that never parses the body) how to broadly react without understanding the specific code — this is deliberate: a generic HTTP client can treat any unrecognized 4xx as "my request was wrong" and any unrecognized 5xx as "retry might help" purely from that leading digit.

6URLs, the Request Target

https://api.example.com:443/v1/users/42?include=orders#profile
\___/   \_______________/ \_/\_____________/\_____________/\_____/
scheme        host        port     path          query      fragment

Only scheme, host, and path (plus query) typically reach the server — the fragment (#profile) is resolved entirely client-side and is never sent in the actual HTTP request line; a server has no way to see it.

7Statelessness in Practice

Because HTTP itself has no memory, "session" behavior is always built on top of it, never inside it: a cookie is just a header value the client happens to re-send on every subsequent request, and a JWT is just a token the client re-attaches to Authorization. The protocol never tracks "this is the third request from the same visitor" — every request is judged solely on the headers/body present in that one request.

Client -> Server   SYN            (client proposes a connection)
Server -> Client   SYN-ACK        (server acknowledges, proposes back)
Client -> Server   ACK            (client acknowledges — connection is now open)

GET / HTTP/1.1\r\n
Host: example.com\r\n
\r\n

⚠️ Common Pitfalls

1. Treating GET as always side-effect-free in practice — it's a convention the spec requires, not something the protocol enforces; a poorly built API can still mutate state on GET, which breaks caching, prefetching, and browser back/forward behavior that all assume GET is safe.
2. Confusing "idempotent" with "has no effect the second time" — idempotent means the end state is the same, not that the second call does nothing; DELETE /users/42 called twice still returns some response the second time (often 404), it just doesn't change server state further.
3. Assuming the fragment (#...) reaches the server — it never does; it's resolved purely in the browser, which is exactly why it's used for client-side routing state.
4. Forgetting the response needs Content-Length or chunked encoding — without one of these, an HTTP/1.1 client reading a persistent connection has no reliable way to know where the response body ends.

📋 Quick Reference

Request:  METHOD /path?query HTTP/version\r\n  Headers\r\n  \r\n  [body]
Response: HTTP/version STATUS reason\r\n        Headers\r\n  \r\n  [body]

Safe + idempotent:      GET, HEAD, OPTIONS
Idempotent, not safe:   PUT, DELETE
Neither:                POST, (usually) PATCH

1xx info   2xx success   3xx redirect   4xx client error   5xx server error

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: http_http_fundamentals_theory.md · generated by tools/build_lessons.py