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

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

Level 1 — Recognition

Goal: kya tum pieces ko naam de aur classify kar sakte ho?

Exercise 1.1

Is response start line ko dekho aur teen fields aur status class identify karo:

HTTP/1.1 404 Not Found

Recall Solution 1.1

Ek response start line ki shape hoti hai HTTP/1.1 SP status-code SP reason-phrase, jahan SP ek single space hai (is page ke upar define kiya gaya hai).

Field 1 — version: HTTP/1.1
Field 2 — status code: 404
Field 3 — reason phrase: Not Found

Pehla digit class hota hai. Yahan pehla digit 4 hai, isliye class hai 4xx = client error — jo resource tumne maanga woh exist nahi karta. Server khud theek hai.

Exercise 1.2

Har method ke liye likho Safe? (Y/N) aur Idempotent? (Y/N): GET, POST, PUT, DELETE, HEAD.

Recall Solution 1.2

Yaad karo: safe = server state mein koi change nahi; idempotent = ise $N$ baar karne ke baad wahi final state rehti hai jaise ek baar karne se.

Method	Safe?	Idempotent?
GET	Y	Y
HEAD	Y	Y
PUT	N	Y
DELETE	N	Y
POST	N	N

Note karo ki har safe method automatically idempotent hoti hai (agar kuch change nahi kiya, toh repeat karne se bhi kuch nahi badlega). Ulta sach nahi hai: PUT state change karta hai phir bhi idempotent hai.

Exercise 1.3

In headers mein se kaunsa har HTTP/1.1 request mein mandatory hai, aur kyun? User-Agent, Host, Content-Length, Accept.

Recall Solution 1.3

Host mandatory hai. Ek server IP kai domains host kar sakta hai (virtual hosting — dekho Virtual hosting), isliye request mein batana padta hai ki kaunsi site target kar rahe ho. Baaki teen optional hain. Content-Length tab hi aata hai jab body ho.

Level 2 — Application

Goal: message format aur status rules ko concrete inputs par apply karo.

Exercise 2.1

https://shop.io/cart ke liye ek complete, correct raw HTTP/1.1 GET request likho jisme user agent curl/8.0 ho aur JSON accept kiya ja raha ho. Literal \r\n markers use karo.

Recall Solution 2.1

Structure: METHOD SP request-target SP HTTP/1.1, phir header lines, phir ek blank line.

GET /cart HTTP/1.1\r\n
Host: shop.io\r\n
User-Agent: curl/8.0\r\n
Accept: application/json\r\n
\r\n

Aakhri akela \r\n "headers khatam" ka signal deta hai. GET mein koi body nahi hoti, isliye message wahan khatam ho jaata hai. Scheme (https) aur host Host header mein jaate hain, request-target mein nahi — target sirf path /cart hota hai.

Exercise 2.2

Ek server persistent connection par yeh response bhejta hai. Client ko kitne bytes ki body padhni chahiye, aur use kaise pata chalega ki response khatam ho gaya?

HTTP/1.1 200 OK\r\n
Content-Type: text/plain\r\n
Content-Length: 5\r\n
\r\n
Hello

Recall Solution 2.2

Client bilkul 5 bytes ki body padhta hai (H, e, l, l, o).

Persistent connection par socket response ke baad band nahi hoti, isliye "EOF tak padho" possible nahi hai. Content-Length: 5 header client ko exactly batata hai ki yeh response kahan khatam hota hai aur agla response us socket par kahan se shuru hoga. Yahi framing ki wajah hai ki persistence ko length header (ya chunked encoding) ki zaroorat hoti hai.

Exercise 2.3

Har situation ko best status code se match karo: (a) User ek aisi page request karta hai jo permanently naye URL par move ho gayi hai. (b) Cached copy abhi bhi fresh hai; last fetch ke baad kuch nahi badla. (c) User logged in nahi hai aur ek protected page access karne ki koshish karta hai. (d) Server ne ek unhandled exception throw ki.

Recall Solution 2.3

(a) → 301 Moved Permanently (3xx redirect).
(b) → 304 Not Modified (3xx; conditional GET succeed hua — dekho Caching, ETag and conditional GET).
(c) → 401 Unauthorized (4xx client error — authentication chahiye).
(d) → 500 Internal Server Error (5xx server error).

Split rule: 4xx = "tumne galti ki," 5xx = "maine galti ki." (c) client ki side par hai (koi credentials nahi); (d) server ki galti hai.

Level 3 — Analysis

Goal: reason karo ki system aisa kyun behave karta hai; costs compute karo.

Exercise 3.1

Ek page ko $R = 12$ resources chahiye. RTT $= 40$ ms. Parent ke toy latency model ka use karte hue $T_{1.0} = 2 R \cdot RTT, T_{1.1} = (R + 1) \cdot RTT,$ $T_{1.0}$ , $T_{1.1}$ , aur milliseconds saved compute karo.

Neeche di gayi figure dono models ko $R$ badhne ke saath plot karti hai. Orange curve ( $2 R \cdot RTT$ ) teal curve ( $(R + 1) \cdot RTT$ ) se do guni tezi se badhti hai, kyunki HTTP/1.0 har resource ke liye fresh handshake pay karta hai jabki HTTP/1.1 sirf ek handshake pay karta hai aur phir har resource ke liye ek RTT. $R = 12$ par plum bar dono curves ke beech ka vertical gap hai — woh gap hi woh 440 ms hai jo tum neeche compute karte ho, aur yeh har extra resource ke saath exactly ek RTT se badh jaata hai.

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

Recall Solution 3.1

$R = 12$ , RTT $= 40$ ms substitute karo. $T_{1.0} = 2 \cdot 12 \cdot 40 = 960 ms$ $T_{1.1} = (12 + 1) \cdot 40 = 13 \cdot 40 = 520 ms$ $saved = 960 - 520 = 440 ms$ Closed form se cross-check karo: saving $= (R - 1) \cdot RTT = 11 \cdot 40 = 440$ ms. ✓ Yeh exactly upar ki figure mein plum bar ki height hai.

Saving is wajah se aati hai ki 12 ki jagah sirf ek TCP handshake hota hai (dekho TCP three-way handshake), persistent connection ki wajah se.

Exercise 3.2

Usi link par ( $R = 12$ , RTT $= 40$ ms), maan lo pipelining client ko bina wait kiye saare requests fire karne deta hai, toh poori batch ka cost lagbhag $2 \cdot RTT$ hota hai (ek handshake RTT + ek RTT pipelined burst ke liye). Pipelined 1.1 kitna tez hai 3.1 ke serial 1.1 se, aur kaunsa flaw abhi bhi bacha rehta hai?

Recall Solution 3.2

$T_{pipe} \approx 2 \cdot RTT = 2 \cdot 40 = 80 ms$ Serial 1.1 $520$ ms tha, toh pipelining aur $520 - 80 = 440$ ms bachata hai.

Bacha hua flaw head-of-line blocking hai: replies ek TCP stream par order mein waapas aane chahiye, isliye ek slow response uske peeche queue mein baaki saare responses ko rok deta hai. Yahi woh limitation hai jise HTTP-2 multiplexing remove karta hai.

Exercise 3.3

Explain karo ki kyun kisi response mein agar koi Content-Length nahi hai aur koi Transfer-Encoding: chunked header bhi nahi hai, toh connection ko HTTP/1.1 mein bhi uske baad close hona hi padega.

Recall Solution 3.3

Bina length header ya chunked framing ke, client ke liye yeh jaanne ka ek hi tarika hai ki body khatam ho gayi — socket band hona (EOF) — yeh purana HTTP/1.0 rule hai. Lekin EOF ka matlab hai TCP connection chali gayi. Isliye server connection open nahi rakh sakta: koi tarika nahi hoga yeh batane ka ki yeh body kahan khatam hoti hai aur agla response kahan se shuru hota hai. Isliye ek unframed response Connection: close imply karta hai. Persistence aur framing ek doosre se alag nahi ho sakte.

Level 4 — Synthesis

Goal: requirements se correct, complete messages/flows banao.

Exercise 4.1

Ek raw HTTP/1.1 request design karo jo JSON body {"name":"Ada"} ko api.dev/users par bhejkar naaya user create kare. Exactly wahi headers include karo jo server ko body correctly parse karne ke liye chahiye persistent connection par. Woh byte count batao jo tumne length header mein daala hai.

Recall Solution 4.1

Data submit karke resource create karna = POST (idempotent nahi, safe nahi — repeat karne par duplicate users ban jaate hain). Body hai {"name":"Ada"}. Bytes ek ek character gino (payload mein koi spaces nahi hain): { " n a m e " : " A d a " } = 14 characters, 14 bytes (sab single-byte ASCII hain).

POST /users HTTP/1.1\r\n
Host: api.dev\r\n
Content-Type: application/json\r\n
Content-Length: 14\r\n
\r\n
{"name":"Ada"}

Content-Type server ko batata hai bytes ko kaise interpret karna hai; Content-Length: 14 batata hai kitne bytes padhne hain persistent socket par agla request aane se pehle.

Exercise 4.2

Ek client ek cached page ko refresh karna chahta hai sirf tab jab woh change hui ho. Uski cached copy mein ETag: "v9" tha. Likho (a) conditional request aur (b) do possible responses (changed vs unchanged), har ek mein status code name karo. "Changed" case ke liye nayi body Hi Ada! use karo aur uska Content-Length compute karo.

Recall Solution 4.2

(a) Conditional request If-None-Match use karta hai jisme stored ETag hota hai:

GET /page HTTP/1.1\r\n
Host: site.io\r\n
If-None-Match: "v9"\r\n
\r\n

(b) Do outcomes:

Unchanged — server ka current ETag abhi bhi "v9" hai:
```
HTTP/1.1 304 Not Modified\r\n
ETag: "v9"\r\n
\r\n
```
Koi body nahi — client apna cache reuse karta hai. Isse bandwidth bachti hai (Caching, ETag and conditional GET ka yahi point hai).
Changed — naaya ETag, poori body bheji jaati hai. Body hai Hi Ada!; count karo: H i (space) A d a ! = 7 bytes (space actually ek real character hai is body mein, upar ke JSON se alag). Toh Content-Length: 7:
```
HTTP/1.1 200 OK\r\n
ETag: "v10"\r\n
Content-Length: 7\r\n
\r\n
Hi Ada!
```

Level 5 — Mastery

Goal: poore stack ko integrate karo aur limits/edge cases par reason karo.

Exercise 5.1

Ek browser https://blog.io fresh open karta hai (cold cache). Un saare round-trip-costing steps ko order mein list karo jo HTML ka pehla byte aane se pehle hote hain, relevant vault topics ko name karte hue. Phir batao ki in mein se kaunse steps HTTP/1.1 ki persistent connection doosri request par actually eliminate karti hai.

Recall Solution 5.1

HTTPS page ke liye cold-start sequence:

DNS resolution — blog.io ko IP mein convert karo (~1 RTT, aksar cached hota hai).
TCP three-way handshake — 1 RTT, data flow hone se pehle.
TLS handshake — encryption setup karo (TLS 1.2 ke liye 1–2 RTT; TLS 1.3 ke liye ~1).
TCP slow start — congestion window chhoti shuru hoti hai, isliye handshakes ke baad bhi early responses throughput-limited hote hain.
HTTP GET request → HTML ka pehla byte (1 RTT).

Doosri request par usi persistent connection ke through, HTTP/1.1 steps 2, 3, aur 4-restart eliminate karta hai — TCP handshake, TLS handshake, aur fresh slow-start ramp sab reuse ho jaate hain. Yahi reuse persistence ki poori value hai. DNS (step 1) alag hai aur independently cached hota hai.

Exercise 5.2

Edge case: ek server persistent connection par ek response bhejta hai jisme dono Content-Length: 20 aur Transfer-Encoding: chunked hain. Spec ke mutabik, kaunsa jeetega, aur dono bhejana kyun dangerous hai?

Recall Solution 5.2

Jab dono present hain, Transfer-Encoding: chunked jeetata hai aur Content-Length ko ignore karna chahiye. Chunked framing ka apna explicit end marker hota hai (ek zero-length final chunk), isliye length redundant ho jaati hai.

Kyun dangerous hai: agar ek front-end proxy Content-Length honor kare jabki back-end Transfer-Encoding honor kare (ya ulta), toh dono disagree karte hain ki message kahan khatam hota hai. Ek attacker "leftover" bytes mein ek hidden request smuggle kar sakta hai — yeh HTTP request smuggling hai. Fix: dono kabhi mat bhejo; proxy par ek ko strip kar do.

Exercise 5.3 (capstone)

Do designs 100 ms-RTT link par 30 chhote resources move karte hain. Design A = HTTP/1.0 (har baar nayi connection). Design B = HTTP/1.1 persistent + serial. Dono times toy model se compute karo, saving bhi, aur phir ek sentence mein explain karo ki ek teesra design (HTTP/2 multiplexing) kya improve karega jo Design B abhi bhi nahi kar sakta.

Recall Solution 5.3

$R = 30$ , RTT $= 100$ ms. $T_{A} = 2 R \cdot RTT = 2 \cdot 30 \cdot 100 = 6000 ms$ $T_{B} = (R + 1) \cdot RTT = 31 \cdot 100 = 3100 ms$ $saved = 6000 - 3100 = 2900 ms = (R - 1) \cdot RTT = 29 \cdot 100 ✓$ Design B abhi bhi requests ek ordered stream par serially bhejta hai, isliye ek slow resource queue ko block kar deta hai (head-of-line blocking). HTTP-2 multiplexing single connection par independent streams ko interleave karta hai, isliye koi ek response baaki sab ko nahi rok sakta.

Recall Self-test wrap-up

Persistent connections par framing kis level ne test kiya? ::: Level 2 (Ex 2.2) aur Level 5 (Ex 5.2). Persistent vs 1.0 ki RTT saving ka closed-form kya hai? ::: $(R - 1) \cdot RTT$ . Body {"name":"Ada"} ka byte count kya hai? ::: 14 bytes. Kya cheez pipelining ke baad bhi bachti hai lekin HTTP/2 multiplexing ke under khatam ho jaati hai? ::: Head-of-line blocking.