HTTP - 1.1 — methods, status codes, headers, persistent connections
WHY does HTTP exist, and WHY 1.1?
WHAT problem: Browsers and servers need a common language to ask for and deliver web resources (HTML, images, JSON). Without an agreed format, every site would speak differently.
WHY 1.1 over 1.0: In HTTP/1.0, each request opened a new TCP connection, did one exchange, then closed. A page with 30 images = 30 TCP handshakes (each costing a full round-trip
- slow-start). That is brutally slow. HTTP/1.1 fixes this with persistent connections and
pipelining, plus mandatory
Hostheader (so one IP can serve many sites = virtual hosting).
HOW a request/response is shaped (derive the format)
We DERIVE the message format from requirements, not memorize it.
- We need an action verb + target + version → that's the start line.
- We need metadata (length, type, cookies…) → header lines
Name: Value. - We need a separator so the parser knows headers ended → a blank line (CRLF CRLF).
- Optionally a payload → the body.
Methods (the verbs)
Status codes (the answer)
The first digit is the class — that's the 80/20 you must lock in:
| Class | Meaning | Examples |
|---|---|---|
1xx |
Informational | 100 Continue |
2xx |
Success | 200 OK, 201 Created, 204 No Content |
3xx |
Redirection | 301 Moved Permanently, 304 Not Modified |
4xx |
Client error | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found |
5xx |
Server error | 500 Internal Server Error, 503 Service Unavailable |
Key headers
Persistent connections — the core upgrade
WHY framing matters: If the socket never closes, "the body is whatever comes before EOF" no
longer works. So each response MUST declare its length via Content-Length or use
Transfer-Encoding: chunked. Without this, the client wouldn't know where one response ends and
the next begins.
Pipelining (send next request before previous reply arrives) reduces it further toward , but suffers head-of-line blocking (a slow first response stalls all behind it) — which is exactly the flaw HTTP/2 multiplexing later solves.
Recall Forecast-then-Verify
Before reading the formula: guess — does keeping the connection open save more time when RTT is large or small? Verify: saving RTT, so it scales with RTT — bigger on high-latency links (mobile, satellite). Your intuition that "slow networks benefit most" is correct.
Common mistakes (Steel-man + fix)
Flashcards
What does HTTP/1.1 make the default that HTTP/1.0 didn't?
Which header became mandatory in HTTP/1.1 and why?
Host: — to support virtual hosting (many domains on one IP).What does the first digit of a status code tell you?
Difference between safe and idempotent?
Is POST idempotent?
Why does a persistent connection NEED Content-Length or chunked encoding?
What is head-of-line blocking in HTTP/1.1 pipelining?
404 vs 500 — who is at fault?
How do you OPT OUT of persistence in HTTP/1.1?
Connection: close.What ends the header section of an HTTP message?
Roughly how many RTTs to fetch R resources in 1.0 vs 1.1 (toy model)?
Recall Feynman: explain to a 12-year-old
Imagine ordering food at a counter. You shout your order (method + what you want), the cook shouts back a number that means "done!", "we're out of that!", or "I burnt the kitchen!" (status code). Old HTTP/1.0 made you walk all the way to the counter for every single item — exhausting. HTTP/1.1 says: stay at the counter and keep ordering (persistent connection). But now the cook must tell you "this dish is 13 spoonfuls big" (Content-Length) so you know when one dish ends and the next starts, since you never leave the line.
Connections
- TCP three-way handshake — the cost persistent connections amortize.
- TCP slow start — why reusing a warmed-up connection is faster.
- HTTP-2 multiplexing — fixes head-of-line blocking of 1.1 pipelining.
- TLS handshake — adds even more RTTs, so persistence matters more for HTTPS.
- DNS resolution — happens before the first HTTP request.
- Caching, ETag and conditional GET — uses 304 Not Modified.
- Virtual hosting — enabled by the mandatory Host header.
Concept Map
Hinglish (regional understanding)
Intuition Hinglish mein samjho
Dekho, HTTP ek simple sa "letter" protocol hai jo TCP ke upar chalta hai. Tum server ko bolte ho method (GET = de do, POST = bhej raha hoon), kis resource ka, aur kaunsa version. Server wapas ek status code deta hai — 200 matlab sab badhiya, 404 matlab "jo maanga wo mila hi nahi" (teri galti), 500 matlab "server ke andar hi kuch phat gaya" (server ki galti). Yaad rakho: 4xx tu, 5xx main — isse aadha debugging ho jata hai.
HTTP/1.1 ka asli jaadu hai persistent connection. Pehle (1.0 me) har image ke liye nayi TCP connection banti thi — matlab har baar 3-way handshake, ek poora round-trip barbaad. 30 images = 30 handshakes, bahut slow, khaaskar slow mobile network pe jahan RTT bada hota hai. 1.1 bolta hai: ek hi connection ko khula rakho aur baar-baar use karo. Toy formula: 1.0 me ~2R·RTT lagta tha, 1.1 me ~(R+1)·RTT — yaani (R-1) RTT bach gaye.
Lekin ek catch hai: jab socket band hi nahi hota, to client ko kaise pata chale ki ek response khatam kahan hua? Isiliye har response me Content-Length ya chunked encoding zaroori hai — ye batata hai ki kitne bytes padhne hai. Aur 1.1 me Host header mandatory hai, kyunki ek hi IP pe kai websites host hoti hain (virtual hosting), server ko pata hona chahiye tum kaunsi site maang rahe ho. Pipelining se aur speed milti hai par "head-of-line blocking" problem aati hai — jise baad me HTTP/2 solve karta hai.