मॉड्यूल 13 · HTTP और वेब के मूल सिद्धांत

HTTP रिक्वेस्ट और रिस्पॉन्स

Q: क्या requests और responses पढ़ने के लिए HTTP/2 और HTTP/3 जानना ज़रूरी है?

नहीं। HTTP/2 और HTTP/3 वही हिस्से (method, target, status code, header fields, body) text lines की जगह binary frames में भेजते हैं, और RFC 9110 हर version के लिए उनका अर्थ परिभाषित करता है। Tools इन्हें पढ़ने लायक रूप में दिखाते हैं; lower-case header names, :method और :path जैसे pseudo-headers, और reason phrase के न होने की उम्मीद रखें।

Q: क्या body, payload और content एक ही चीज़ हैं?

रोज़मर्रा के इस्तेमाल में हाँ: header section के बाद का data। RFC 9110 इसे content कहता है; RFC 9112, जो HTTP/1.1 का text format परिभाषित करता है, wire पर जाने वाले bytes को message body कहता है, जो chunked जैसी transfer coding लगने पर content से अलग होती है। कई tools इसे payload कहते हैं।

Q: क्या GET request में body हो सकती है?

Message में body हो सकती है, लेकिन RFC 9110 GET request में content का कोई सामान्य रूप से परिभाषित अर्थ नहीं देता, और servers, proxies और caches उसे ignore या reject कर सकते हैं। GET का input query string में भेजें। अगर कोई API GET body document करता है, तो उसे risk मानें और इस्तेमाल होने वाले हर client और proxy से होकर टेस्ट करें।

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 17 मिनट · शुरुआती

Web पर हर exchange दो messages की जोड़ी है: client एक HTTP request भेजता है और server एक HTTP response लौटाता है। Request बताती है कि client क्या चाहता है: POST जैसा method, /api/v1/tickets जैसा target, headers और, जब भेजने को data हो, एक body। Response बताता है कि क्या हुआ: 201 जैसा status code, headers और आम तौर पर एक body।

दोनों structured text हैं जिन्हें आप line-by-line पढ़ सकते हैं। Support form submit करें, तो request में {"subject": "Late delivery", "orderId": 9021} जा सकता है, और response 201 Created के साथ नए ticket को अपनी body में लौटाता है।

यह क्यों ज़रूरी है

Screen वही दिखाती है जो front end ने दिखाना तय किया: "Saved" तब भी दिख सकता है जब server ने data reject कर दिया हो। Request और response बताते हैं कि client और server के बीच असल में क्या हुआ, इसलिए उनसे पता चलता है कि defect client में है, server में या दोनों में, और उसे ठीक किसे करना है।

Request: method, target, headers, body

HTTP/1.1 (RFC 9112) में request का layout तय है: एक request line, फिर हर line में एक header field, फिर एक खाली line, फिर optional body। Request line और हर header line carriage return और line feed (CRLF) पर ख़त्म होती हैं।

Method: पहला शब्द, जो माँगा गया action बताता है, जैसे पढ़ने के लिए GET या data भेजने के लिए POST। अगला पाठ हर method को समझाता है।
Request target: आम तौर पर path और optional query string, यहाँ /api/v1/tickets?lang=ar; host name अलग से Host header में जाता है।
Protocol version: HTTP/1.1 request line को ख़त्म करता है।
Header fields: Name: value वाली lines, जैसे Host (request किस host के लिए है), Content-Type और Content-Length (body का format और size), Accept और Authorization। HTTP/1.1 request में ठीक एक Host header होना ज़रूरी है, वरना server को 400 Bad Request देना होगा।
Body: खाली line के बाद का सब कुछ, जो तभी होती है जब भेजने को data हो।

POST /api/v1/tickets?lang=ar HTTP/1.1
Host: support.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 45

{"subject": "Late delivery", "orderId": 9021}

आज़माएँ: API रिक्वेस्ट बिल्डर

Response: status line, headers, body

Server उसी layout में जवाब देता है; फ़र्क़ सिर्फ़ पहली line में है। Status line में protocol version, तीन अंकों का status code और एक reason phrase होता है।

Status code: नतीजा, एक number के रूप में। Client इसी पर action लेता है, इसलिए assert भी इसी पर करें। पहला अंक class बताता है: 1xx informational, 2xx success, 3xx redirection, 4xx request में समस्या, 5xx server पर error।
Reason phrase: इंसानों के लिए text, जैसे Created। RFC 9112 clients से इसे ignore करने को कहता है, हर server इसे अलग शब्दों में लिख सकता है, और HTTP/2 इसे भेजता ही नहीं, इसलिए इस पर कभी assert न करें।
Header fields: response के बारे में जानकारी, जैसे body का format और size, नए resource का Location, Set-Cookie और Cache-Control।
Body: माँगा गया data, किसी error का विवरण, या कुछ नहीं।

Request और उसका response एक ही ढाँचा साझा करते हैं: start line, header fields, खाली line और optional body; फ़र्क़ सिर्फ़ start line में है: method, target और version बनाम version, status code और reason phrase।

रिक्वेस्ट

भाग 1:1POST भाग 2:2/api/v1/tickets?lang=ar भाग 3:3HTTP/1.1
भाग 6:6Host: support.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 45
भाग 7:7
भाग 8:8{"subject": "Late delivery", "orderId": 9021}

रिस्पॉन्स

भाग 3:3HTTP/1.1 भाग 4:4201 भाग 5:5Created
भाग 6:6Date: Thu, 01 Oct 2026 09:30:00 GMT
Content-Type: application/json
Content-Length: 62
Location: /api/v1/tickets/T-1047
भाग 7:7
भाग 8:8{"id": "T-1047", "status": "open", "subject": "Late delivery"}

1–3Request line (रिक्वेस्ट लाइन)
3–5Status line (स्टेटस लाइन)
6–8दोनों messages में एक जैसे

1Method (मेथड)माँगा गया action; POST data भेजता है। हर method के अपने नियम हैं।
2Request target (रिक्वेस्ट टारगेट)Path और optional query। Host name Host header में जाता है।
3Protocol version (वर्ज़न)Status line की शुरुआत और request line का अंत। HTTP/2 और HTTP/3 हर message में version नहीं रखते; उसे connection तय करता है।
4Status code (स्टेटस कोड)तीन अंक; पहला अंक class बताता है। Client इसी के आधार पर action लेता है, इसलिए assert इसी पर करें।
5Reason phrase (रीज़न फ़्रेज़)इंसानों के लिए text: client इसे ignore करता है और HTTP/2 इसे भेजता ही नहीं। इस पर कभी assert न करें।
6Header fields (हेडर)हर line में एक Name: value। Names case-insensitive हैं और अलग-अलग fields के क्रम का कोई अर्थ नहीं।
7खाली lineHeader section को ख़त्म करती है: इसके बाद सब कुछ body है।
8Body (बॉडी)दोनों messages में optional। Content-Type उसका format बताता है, Content-Length bytes में size।

पाठ संस्करण

HTTP/1.1 201 Created
Date: Thu, 01 Oct 2026 09:30:00 GMT
Content-Type: application/json
Content-Length: 62
Location: /api/v1/tickets/T-1047

{"id": "T-1047", "status": "open", "subject": "Late delivery"}

आज़माएँ: HTTP स्टेटस कोड लुकअप

Request body और response body

RFC 9110 body को content कहता है; tools इसे body या payload कहते हैं। Content-Type उसका format एक media type के रूप में बताता है, जैसे JSON के लिए application/json; JSON एक text format है जिसे कई APIs इस्तेमाल करती हैं, और इसमें names और values braces के अंदर होते हैं। Content-Length उसका size bytes में देता है, सिवाय तब जब कोई HTTP/1.1 sender Transfer-Encoding: chunked इस्तेमाल करके body टुकड़ों में भेजे।

Request body में वह data होता है जिसे आप बनाते या बदलते हैं, इसलिए POST, PUT और PATCH requests में आम तौर पर body होती है। GET, HEAD और DELETE requests में आम तौर पर नहीं: RFC 9110 इनमें content का कोई सामान्य रूप से परिभाषित अर्थ नहीं देता।
Response body में वह होता है जो आपने माँगा, जैसे JSON, HTML या कोई file, या किसी error का विवरण; RFC 9457 errors के लिए एक standard format, application/problem+json, परिभाषित करता है (नीचे sample)।
कुछ responses में body कभी नहीं होती: HEAD request का कोई भी response, और हर 1xx, 204 No Content और 304 Not Modified response।
Content-Length bytes गिनता है, characters नहीं। UTF-8 में, जो web text को bytes में बदलने वाली आम encoding है, हर English letter, अंक और punctuation mark एक byte लेता है, हर Arabic letter दो और हर Devanagari character तीन: {"name": "سارة"} 16 characters का है लेकिन 20 bytes का।

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
Content-Length: 132

{"type": "https://example.com/probs/missing-field", "title": "Missing field",
 "status": 422, "detail": "subject must not be empty"}

आज़माएँ: Content-Type वैलिडेटर आज़माएँ: स्ट्रिंग लेंथ काउंटर

Raw HTTP पढ़ना

Raw HTTP यानी message text के रूप में, जैसा ऊपर के samples में है। DevTools में Network panel के Headers tab में Raw toggle होता है, और request body Chrome में Payload tab में या Firefox में Request tab में मिलती है। curl -v भेजी गई start line और header lines के आगे > और मिली lines के आगे < लगाता है। एक तय क्रम में पढ़ें:

Start line: क्या method और target वही हैं जो test चाहता था? Response में status code लें, reason phrase नहीं।
Headers: names case-insensitive हैं और अलग-अलग fields के क्रम का कोई अर्थ नहीं, इसलिए सिर्फ़ names और values की तुलना करें।
खाली line: इससे पहले message के बारे में जानकारी, इसके बाद body।
Cross-checks: status code बनाम body, Content-Type बनाम body का असली format, Content-Length बनाम उसके bytes। हर हिस्सा अकेले में सही दिख सकता है जबकि उनका मेल गलत हो।

आज़माएँ: HTTP हेडर पार्सर आज़माएँ: HTTP रिक्वेस्ट इंस्पेक्टर

Worked example: "Saved", लेकिन address ग़ायब

Shopping app में tester delivery address जोड़ता है तो app "Saved" दिखाता है, लेकिन address list ख़ाली रहती है। API documentation कहता है कि body में city और postalCode चाहिए, success पर 201 Created आता है, और validation error पर problem details body के साथ 422। Tester DevTools खोलकर step दोहराता है और exchange copy करता है।

Request line और headers: documentation के मुताबिक़; Content-Type JSON body से मेल खाता है और Content-Length: 42 उसके 42 bytes के बराबर है।
Request body: postalCode की जगह postal_code। Defect 1, app में।
Status line: fail हुए save के लिए 200 OK; app ने 2xx पर भरोसा करके "Saved" दिखा दिया। Defect 2, API में: expected 422।
Response headers: JSON body के लिए Content-Type: text/plain। Defect 3, API में: header को मानने वाला client शायद error को parse न कर पाए।
Response body: यह missing field का नाम बताती है, जिससे defect 1 का पता चला। तीन defects, दो owners, एक exchange।

POST /api/v1/customers/58/addresses HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 42

{"city": "Riyadh", "postal_code": "12271"}

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 53

{"success": false, "error": "postalCode is required"}

आम गलतियाँ

नतीजे को सिर्फ़ screen या सिर्फ़ status code से आँकना: body में error वाला 200 OK बिना नज़र में आए निकल जाता है।
Status codes और header values की जगह reason phrase पर, या headers के case और क्रम पर assert करना।
Content-Type पर इसलिए भरोसा करना कि body आपको ठीक दिखती है: header को मानने वाला client फिर भी उसे पढ़ने में fail हो सकता है।
Content-Length को characters में गिनना: UTF-8 में Arabic, Hindi और emoji text characters से ज़्यादा bytes लेता है।
Raw exchange के बिना "request fail हो गई" report करना, या उसे असली Authorization और Cookie values के साथ, बिना mask किए, paste करना।

QA का नज़रिया

जब भी screen और data मेल न खाएँ, raw HTTP पढ़ें। Steps दोहराने से पहले Network panel खोलें, action के पीछे की request ढूँढें, और दो सवाल पूछें: क्या client ने वही भेजा जो specification माँगती है, और क्या server ने वैसा जवाब दिया जैसा API documentation कहता है?

Bug report में exchange को text के रूप में, या cURL command और response के रूप में, tokens mask करके लगाएँ, और गलत हिस्से का नाम लिखें: "Expected 422 problem details body के साथ; actual 200 OK Content-Type: text/plain के साथ।" API team से हर endpoint के status codes और error format जल्दी पूछ लें।

अभ्यास

दो raw exchanges पढ़ें और गड़बड़ी ढूँढें

आपका काम

नीचे के दोनों exchanges एक staging environment से लिए गए हैं। चारों messages के हिस्से चिह्नित करें, फिर जाँचें: क्या हर status code अपनी body से मेल खाता है, क्या Content-Type body का सही वर्णन करता है, और क्या Content-Length body के bytes से मेल खाता है?

हर समस्या के लिए expected और actual result लिखें, और बताएँ कि बदलाव किसे करना है, client को या server को।

सामग्री

(1)
PUT /api/v1/profile HTTP/1.1
Host: app.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 23

{"displayName": "نورة"}

HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 70

{"error": "invalid_json", "message": "Request body is not valid JSON"}

(2)
DELETE /api/v1/profile/addresses/3 HTTP/1.1
Host: app.example.com
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 204 No Content
Content-Type: application/json
Content-Length: 30

{"message": "Address deleted"}

चरण

हर message की start line, header fields, खाली line और body चिह्नित करें।
हर body के असली format की तुलना Content-Type से करें।
String Length Counter से हर body के bytes (UTF-8) गिनें और Content-Length से तुलना करें।
हर status code की तुलना उसकी body से करें, फिर तय करें कि हर समस्या किसकी है।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

हिस्से: हर message में start line, header fields और खाली line है। DELETE request में body नहीं है; 204 response में खाली line के बाद ऐसे bytes हैं जिनकी वहाँ अनुमति नहीं (Exchange (2) देखें); बाकी दोनों messages में body है। Content-Type JSON बताता है और हर body सच में JSON है, इसलिए इस जाँच में कुछ नहीं मिलता।

Exchange (1): body {"displayName": "نورة"} 23 characters की है लेकिन 27 bytes की, क्योंकि UTF-8 में हर Arabic letter दो bytes लेता है। Client ने Content-Length: 23 बताया, इसलिए server ने सिर्फ़ {"displayName": "نور पढ़ा और उसे invalid JSON मानकर सही तरह reject किया; उसका 400 response consistent है (70 bytes, जैसा बताया गया)। Defect client में है, जो bytes की जगह characters गिनता है; English नाम वाला test इसे कभी नहीं पकड़ता।

Exchange (2): DELETE request में body नहीं है, जो सही है। लेकिन 204 No Content response में content नहीं हो सकता (RFC 9110), और उसके साथ Content-Length भी नहीं भेजा जाना चाहिए। Client response को खाली line पर ख़त्म मानता है, इसलिए message कभी नहीं दिखता, और दोबारा इस्तेमाल हो रहे HTTP/1.1 connection पर 30 extra bytes अगला response समझे जा सकते हैं। Server को 204 में खाली line के बाद कुछ नहीं भेजना चाहिए, या body के साथ 200 OK भेजना चाहिए।

अक्सर पूछे जाने वाले सवाल

क्या requests और responses पढ़ने के लिए HTTP/2 और HTTP/3 जानना ज़रूरी है?

नहीं। HTTP/2 और HTTP/3 वही हिस्से (method, target, status code, header fields, body) text lines की जगह binary frames में भेजते हैं, और RFC 9110 हर version के लिए उनका अर्थ परिभाषित करता है। Tools इन्हें पढ़ने लायक रूप में दिखाते हैं; lower-case header names, :method और :path जैसे pseudo-headers, और reason phrase के न होने की उम्मीद रखें।

क्या body, payload और content एक ही चीज़ हैं?

रोज़मर्रा के इस्तेमाल में हाँ: header section के बाद का data। RFC 9110 इसे content कहता है; RFC 9112, जो HTTP/1.1 का text format परिभाषित करता है, wire पर जाने वाले bytes को message body कहता है, जो chunked जैसी transfer coding लगने पर content से अलग होती है। कई tools इसे payload कहते हैं।

क्या GET request में body हो सकती है?

Message में body हो सकती है, लेकिन RFC 9110 GET request में content का कोई सामान्य रूप से परिभाषित अर्थ नहीं देता, और servers, proxies और caches उसे ignore या reject कर सकते हैं। GET का input query string में भेजें। अगर कोई API GET body document करता है, तो उसे risk मानें और इस्तेमाल होने वाले हर client और proxy से होकर टेस्ट करें।

संदर्भ

RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
RFC 9112: HTTP/1.1IETF · 2022HTTP/1.1 मैसेज सिंटैक्स: रिक्वेस्ट लाइन, हेडर फ़ील्ड, चंक्ड ट्रांसफ़र और कनेक्शन हैंडलिंग।
RFC 9457: Problem Details for HTTP APIsIETF · 2023मशीन-रीडेबल API एरर के लिए application/problem+json फ़ॉर्मेट (type, title, status, detail, instance)।
Overview of HTTP — MDNMDN Web Docs (Mozilla)HTTP कैसे काम करता है: एक stateless client–server प्रोटोकॉल, जिसमें client request भेजता है और server response संदेश से जवाब देता है।

HTTP रिक्वेस्ट और रिस्पॉन्स

यह क्यों ज़रूरी है

Request: method, target, headers, body

Response: status line, headers, body

Request body और response body

Raw HTTP पढ़ना

Worked example: "Saved", लेकिन address ग़ायब

आम गलतियाँ

QA का नज़रिया

अभ्यास

दो raw exchanges पढ़ें और गड़बड़ी ढूँढें

अक्सर पूछे जाने वाले सवाल

संदर्भ

Mutqan tools से अभ्यास करें

HTTP हेडर पार्सर

HTTP रिक्वेस्ट इंस्पेक्टर

API रिक्वेस्ट बिल्डर

Content-Type वैलिडेटर

स्ट्रिंग लेंथ काउंटर

HTTP स्टेटस कोड लुकअप

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

यह क्यों ज़रूरी है

Request: method, target, headers, body

Response: status line, headers, body

Request body और response body

Raw HTTP पढ़ना

Worked example: "Saved", लेकिन address ग़ायब

आम गलतियाँ

QA का नज़रिया

अभ्यास

दो raw exchanges पढ़ें और गड़बड़ी ढूँढें

अक्सर पूछे जाने वाले सवाल

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics