HTTP - 1.1 — methods, status codes, headers, persistent connections: Worked examples

4.3.24 · D3 · Coding › Computer Networks › HTTP - 1.1 — methods, status codes, headers, persistent conn

Yeh page HTTP/1.1 — methods, status codes, headers, persistent connections ke liye "flight simulator" hai. Yahan koi naya theory nahi seekhenge; hum parent note ki cheezein stress-test karenge — har tarah ka case throw karke — har status class, har method flavour, degenerate messages (empty body, no length), limiting behaviour (latency formula jab $R \to \infty$ ), ek real-world word problem, aur ek exam-style trap.

Shuru karne se pehle ek vaada: har symbol jo neeche use hua hai, woh parent note mein earn kiya gaya hai ya yahan re-earn kiya gaya hai. Agar koi number aata hai, toh page ke neeche check kiya gaya hai.

The scenario matrix

Is table ko "boxes jinhe exam tick kar sakta hai" ki ek checklist ki tarah socho. Har worked example neeche us cell ke saath label kiya gaya hai jisme woh fit hota hai. Ant tak, har cell mein kam se kam ek worked example hoga.

#	Case class	Kya tricky banata hai	Example jo isse cover karta hai
C1	2xx success + framing	body present → `Content-Length` chahiye	Example 1
C2	3xx conditional / cache	`304` mein koi body nahi — degenerate	Example 2
C3	4xx client error	server theek hai, tumne galti ki	Example 3
C4	5xx server error	blame server par jaata hai	Example 4
C5	Idempotency: PUT vs POST	repeat-N vs repeat-once	Example 5
C6	Degenerate body: chunked / unknown length	bilkul `Content-Length` nahi	Example 6
C7	Limiting behaviour of latency	$R \to \infty$ , RTT large vs small	Example 7
C8	Real-world word problem	ek real page par RTTs count karo	Example 8
C9	Exam twist / trap	`keep-alive` relic, HOL blocking	Example 9

Example 1 — 2xx success with a body (cell C1)

Step 1 — status line choose karo. HTTP/1.1 200 OK. Yeh step kyun? Request succeed hui aur content return kar raha hai, toh hum 2xx class mein hain; 200 OK default success code hai jab body deliver ki jaati hai.

Step 2 — body bytes count karo. Hello, world! = H e l l o , (space) w o r l d !. Yeh $5 + 1 + 1 + 5 + 1 = 13$ characters hain, sabhi single-byte ASCII → 13 bytes. Yeh step kyun? Ek persistent socket par connection kabhi band nahi hoti, toh client body ka end EOF se detect nahi kar sakta. Use exactly batana padega ki kitne bytes padhne hain.

Step 3 — assemble karo.

HTTP/1.1 200 OK\r\n
Content-Type: text/plain; charset=utf-8\r\n
Content-Length: 13\r\n
\r\n
Hello, world!

Yeh step kyun? Blank line (\r\n) "headers done" mark karti hai, aur Content-Length: 13 body ko frame karta hai taaki is socket par agla response clean start ho.

Verify: Blank line ke baad exactly 13 bytes padho: Hello, world! — match karta hai. Units: Content-Length bytes mein hai, aur ASCII 1 byte/char deta hai, toh 13 chars = 13 bytes. ✓

Example 2 — 3xx with NO body (degenerate case, cell C2)

Step 1 — conditional request pehchaano. If-None-Match: "v7" poochta hai: "body tabhi bhejo jab ETag ab "v7" na ho." Yeh step kyun? Yeh ek conditional GET hai — poora point unchanged bytes dobara download karne se bachna hai.

Step 2 — server tags compare karta hai. Current ETag abhi bhi "v7" hai = requested tag → resource unchanged. Yeh step kyun? Condition "None-Match" fail hoti hai (yeh match karti hai), toh server ko fresh body nahi bhejna chahiye.

Step 3 — 304 ke saath reply karo.

HTTP/1.1 304 Not Modified\r\n
ETag: "v7"\r\n
\r\n

Yeh step kyun? 304 ek 3xx redirection/conditional response hai jiska matlab hai "apna cache use karo." 304 definition se koi body carry nahi karta, toh body ke liye koi Content-Length nahi aur bilkul koi body bytes nahi — yeh degenerate "zero-body" case hai.

Verify: Bytes bachaye = poora image size (maan lo $12, 000$ B) jo header-only reply se trade hua. Body length = 0. Sanity: agar tag alag hoti, toh hamein 200 OK + full body milti — yeh branch matter karta hai. ✓

Example 3 — 4xx client error (cell C3)

Step 1 — resource locate karo. Disk par nahi mila, koi redirect configured nahi. Yeh step kyun? Hume "maine galti ki" aur "tumne galat maanga" mein distinguish karna hai.

Step 2 — blame assign karo. Server khud kaam kar raha hai; request target invalid hai. Yeh step kyun? Mnemonic yaad karo: 4xx = "tumne galat kiya", 5xx = "maine galat kiya". Missing resource matlab client ne galat path diya → client-side.

Step 3 — error-body bytes count karo, phir reply karo. Body hai <html><body>404 - page not found</body></html>. Har character count karke — dono <html>/</html>+<body>/</body> tags, digits 404, do spaces, aur hyphen — exactly 46 bytes milte hain, sabhi single-byte ASCII.

HTTP/1.1 404 Not Found\r\n
Content-Type: text/html; charset=utf-8\r\n
Content-Length: 46\r\n
\r\n
<html><body>404 - page not found</body></html>

Yeh step kyun? 404 canonical 4xx "resource absent" code hai. Note karo ki yeh abhi bhi ek body carry karta hai (ek friendly error page), toh iska abhi bhi accurate Content-Length chahiye — isse galat count karo aur socket par agla response misframe ho jaayega.

Verify: <html><body>404 - page not found</body></html> ka character count = 46 (page ke neeche check kiya gaya). Toh Content-Length: 46 correct hai. ✓

Example 4 — 5xx server error (cell C4)

Step 1 — request validate karo. Method, headers, body sab well-formed hain. Yeh step kyun? Agar request khud malformed hoti toh hum 400 (4xx) dete; yeh nahi hai.

Step 2 — failure locate karo. Server ka database crash hua, client ka message nahi. Yeh step kyun? Blame flip hota hai: client ne kuch galat nahi kiya, toh hum 5xx mein hain.

Step 3 — 500 reply karo.

HTTP/1.1 500 Internal Server Error\r\n
Content-Length: 0\r\n
\r\n

Yeh step kyun? 500 generic "maine galat kiya" hai. Agar DB sirf overloaded/restarting hoti toh hum 503 Service Unavailable prefer karte — lekin ek unhandled crash 500 hai.

Verify: Example 3 se compare karo: message ki same shape, opposite blame class. Content-Length: 0 legally "no body" matlab hai — degenerate empty-body case, ek persistent socket par valid hai kyunki length abhi bhi declare ki gayi hai (0 ke roop mein). ✓

Example 5 — idempotency: PUT vs POST repeated (cell C5)

Step 1 — definitions yaad karo. Idempotent = isse $N$ baar karne par same final state milti hai jaise isse ek baar karne par milti. Safe = bilkul koi state change nahi. Yeh step kyun? Poora answer semantic contract par hinge karta hai, message bytes par nahi.

Step 2 — PUT par apply karo (Case A). PUT "quota = 5 set karo" do baar execute hua → quota $5$ hai, phir $5$ par set hua = abhi bhi $5$ . Yeh step kyun? PUT replace karta hai; same value se replace karna doosri baar no-op hai → idempotent, retry karna safe hai.

Step 3 — POST par apply karo (Case B). POST "order pen create karo" do baar execute hua → do order rows, e.g. IDs 101 aur 102. Yeh step kyun? POST append/create karta hai; har call ek naya side effect hai → not idempotent. Isliye browsers POST ke liye "Confirm form resubmission?" popup karte hain lekin GET/PUT silently retry karte hain.

Verify: State ko counts se model karo. Orders $= 100$ se shuru. Ek POST ke baad: $101$ . Duplicate POST ke baad: $102 \neq = 101$ → not idempotent. Quota arbitrary se shuru, ek PUT ke baad $= 5$ , duplicate PUT ke baad $= 5 = 5$ → idempotent. ✓

Example 6 — unknown-length body: chunked encoding (degenerate, cell C6)

Step 1 — dekho kyun Content-Length impossible hai. Header-writing time par total byte count exist nahi karta. Yeh step kyun? Persistent-connection framing rule demand karta hai ya toh Content-Length ya koi aur framing mechanism — hume doosra option use karna padega.

Step 2 — chunked transfer encoding use karo.

HTTP/1.1 200 OK\r\n
Transfer-Encoding: chunked\r\n
\r\n
5\r\n
Hello\r\n
6\r\n
 world\r\n
0\r\n
\r\n

Yeh step kyun? Har chunk ko uske size hexadecimal mein prefix kiya jaata hai, phir bytes aate hain. 0 size ka final chunk end mark karta hai — yeh "EOF tak padho" ko replace karta hai.

Step 3 — decode karo. Chunk 5 → Hello; chunk 6 → world (leading space count hota hai); chunk 0 → done. Yeh step kyun? Client payloads concatenate karta hai → Hello world, aur 0-chunk batata hai ki socket par agla response kahan se shuru hota hai.

Verify: 5 hex = 5 bytes = Hello ✓. 6 hex = 6 bytes = " world" (space+world) ✓. Total decoded body = 11 bytes = Hello world. 0-sized terminating chunk ka matlab hai ki humne kabhi socket close karne par rely nahi kiya. ✓

Example 7 — limiting behaviour of the latency model (cell C7)

Step 1 — do costs yaad karo (RTTs mein). Parent se, $T_{1.0}$ = HTTP/1.0 load time aur $T_{1.1}$ = HTTP/1.1 load time (dono RTTs mein): $T_{1.0} \approx 2 R$ aur $T_{1.1} \approx R + 1$ . Yeh step kyun? Yeh earned formulas hain; hum sirf plug karenge aur limits lenge — koi nayi physics nahi.

Step 2 — picture padho. Neeche diya figure ek line plot hai jisme horizontal axis $R$ hai (resources ki sankhya, 1 se 40) aur vertical axis RTTs mein time hai. Red line jo steeply upar jaati hai woh $T_{1.0} = 2 R$ hai; green line jo aadhi speed se upar jaati hai woh $T_{1.1} = R + 1$ hai. $R = 30$ par ek yellow dashed vertical guide dono lines se milti hai do dots par — ek red dot height $60$ par aur ek green dot height $31$ par — aur ek yellow double-headed arrow unke beech ka gap span karti hai, jis par "saving = 29 RTT" likha hai. Key visual: red line hamesha green line se do baar tezi se chadhti hai, toh yellow gap right jaate-jaate barhta rehta hai.

Figure — HTTP - 1.1 — methods, status codes, headers, persistent connections

Step 3 — $R = 30$ plug karo. $T_{1.0} = 2 \cdot 30 = 60$ RTT, $T_{1.1} = 30 + 1 = 31$ RTT, saving $= 60 - 31 = 29$ RTT. Yeh step kyun? Parent ke "29 RTTs saved" claim ko confirm karta hai aur neeche di gayi limit ko ground karta hai (aur figure mein yellow arrow se match karta hai).

Step 4 — ratio lo, phir $R \to \infty$ . $\frac{T _{1.1}}{T _{1.0}} = \frac{R + 1}{2 R} = \frac{1}{2} + \frac{1}{2 R} R \to \infty \frac{1}{2} .$ Yeh step kyun? $\frac{1}{2 R}$ term vanish ho jaata hai, toh ek bade page ke liye HTTP/1.1 asymptotically 1.0 ke aadhe RTTs cost karta hai — handshake saving dominate karti hai. Figure mein, green line far right par red line ki aadhi height hug karti hai.

Step 5 — RTT ke saath scale karo. Saving $= (R - 1) \cdot RTT$ . Yeh RTT mein linear hai: satellite link par (RTT $= 600$ ms) 29-RTT saving $= 29 \times 600 = 17, 400$ ms $= 17.4$ s; LAN par (RTT $= 1$ ms) yeh $29$ ms hai. Yeh step kyun? Parent ke forecast ko confirm karta hai — slow networks ko sabse zyada faida hota hai.

Verify: $R = 30$ par: ratio $= 31/60 \approx 0.5167$ , limit $0.5$ se thoda upar ✓. Seconds mein saving: $29 \times 0.6 = 17.4$ s ✓ aur $29 \times 0.001 = 0.029$ s ✓.

Example 8 — real-world word problem (cell C8)

Step 1 — resources count karo. $R = 9$ . Yeh step kyun? Model per-resource hai, toh pehle $R$ chahiye.

Step 2 — HTTP/1.0 time. $T_{1.0} = 2 R \cdot RTT = 2 \cdot 9 \cdot 50 = 900$ ms. Yeh step kyun? 9 resources mein se har ek 1 RTT handshake + 1 RTT request/response pay karta hai.

Step 3 — HTTP/1.1 time. $T_{1.1} = (R + 1) \cdot RTT = 10 \cdot 50 = 500$ ms. Yeh step kyun? Ek shared handshake (1 RTT) plus 9 serial request/response RTTs.

Step 4 — speedup. $900/500 = 1.8 \times$ faster; absolute saving $= (R - 1) \cdot RTT = 8 \cdot 50 = 400$ ms. Yeh step kyun? Abstract formula ko ek aisi number se jodata hai jo user feel karta hai.

Verify: $2 \cdot 9 \cdot 50 = 900$ ✓; $(9 + 1) \cdot 50 = 500$ ✓; $900 - 500 = 400$ ✓; $8 \cdot 50 = 400$ ✓ ( $(R - 1) RTT$ formula se match karta hai). Note: real browsers ~6 parallel connections kholte hain, aur TCP slow start plus TLS handshake aur RTTs add karte hain — yeh toy model lower bound hai. ✓

Example 9 — exam twist / trap (cell C9)

Step 1 — Twist A: default yaad karo. HTTP/1.1 mein persistence default hai; opt out karne ke liye Connection: close bhejte hain. Yeh step kyun? keep-alive header ek HTTP/1.0 relic hai; 1.1 mein ise require karna classic trap hai. → Statement FALSE hai.

Step 2 — Twist B: head-of-line blocking apply karo. Pipelined responses request order mein return karni chahiye, toh $Q_{2}$ aur $Q_{3}$ $Q_{1}$ ko overtake nahi kar sakte chahe woh pehle ready ho jaayein. Yeh step kyun? Yeh ordering constraint head-of-line (HOL) blocking hai — HTTP/1.1 pipelining ka defining flaw.

Step 3 — Twist B: har arrival time compute karo.

$Q_{1}$ $900$ ms par finish hota hai.
$Q_{2}$ $10$ ms kaam ke baad ready hai, lekin $Q_{1}$ ke peeche wait karna padta hai; yeh $Q_{1}$ ke baad bheja jaata hai, $900 + 10 = 910$ ms par aata hai.
$Q_{3}$ bhi $Q_{2}$ ke peeche queue karta hai, $910 + 10 = 920$ ms par aata hai.

Toh teeno responses 920 ms tak aa jaate hain, aur do "fast" requests ek slow request ke peeche almost ek second stall rahe. Yeh step kyun? Yeh HOL blocking ki cost quantify karta hai — yahi stall hai jo HTTP-2 multiplexing remove karta hai independent responses ko ek connection par interleave karne deke.

Verify: Serial-in-order total $= 900 + 10 + 10 = 920$ ms ✓. Agar $Q_{2}, Q_{3}$ independent streams hote (HTTP/2), toh har ek $Q_{1}$ ke saath run karte hue $10$ ms ke paas finish ho sakta — toh HOL blocking $Q_{2}$ ko lagbhag $900$ ms ka avoidable wait cost karta hai. ✓

Recall Self-test: cell ka naam batao

Har ek ke liye batao ki woh kaun sa matrix cell hit karta hai. Ek 304 Not Modified bina body ke ::: C2 (3xx conditional, degenerate zero-body) Duplicate POST jo do rows create karta hai ::: C5 (idempotency: not idempotent) Transfer-Encoding: chunked ke saath log stream karna ::: C6 (unknown-length body) Crashed database se 500 ::: C4 (5xx server error) Asymptotic $T_{1.1} / T_{1.0} \to 1/2$ ::: C7 (limiting behaviour)