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

HTTP हेडर्स

Mutqan Soft QA टीम द्वारा · · 18 मिनट · शुरुआती

HTTP headers नाम वाले fields हैं जो हर request और response के साथ चलते हैं और message का data ले जाने की बजाय message का वर्णन करते हैं। जैसा requests और responses वाले lesson में देखा, ये start line और body के बीच Name: value lines के रूप में आते हैं; RFC 9110 इन्हें header fields कहता है। ये बताते हैं कि body किस format में है, कौन माँग रहा है, जवाब कितनी देर cache हो सकता है और क्या याद रखना है।

उदाहरण के लिए, जब किसी shop का app customer की पसंदीदा भाषा save करता है, तो request में Content-Type: application/json (यह body JSON है), Accept: application/json (जवाब JSON में दो) और Authorization: Bearer … (मैं यह हूँ) होते हैं। Response इसमें Cache-Control: no-store (copy मत रखो) और Set-Cookie: lang=ar (यह याद रखो) जोड़ता है। इनमें से कुछ भी screen पर नहीं दिखता, फिर भी हर line तय करती है कि feature काम करता है या नहीं और सुरक्षित है या नहीं।

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

कई defects सिर्फ़ headers में रहते हैं। सही JSON body पर Content-Type: text/html का label उन clients को तोड़ देता है जो label पर भरोसा करते हैं। Cache-Control: public के साथ भेजा गया personal profile किसी shared cache, जैसे CDN (content delivery network), में store होकर अगले user को मिल सकता है। Secure के बिना session cookie unencrypted HTTP पर जा सकती है। हर बार screen ठीक दिखती है और UI test pass हो जाता है।

Headers failure को जल्दी समझाते भी हैं: Content-Type बताता है कि body parse क्यों नहीं हुई, WWW-Authenticate कि refuse हुई call कौन-सा authentication चाहती थी, Cache-Control और Age (cached copy कितने seconds पुरानी है) कि fix हुआ page अब भी पुराना क्यों दिखता है।

Headers कैसे लिखे और पढ़े जाते हैं

Field names case-insensitive होते हैं: Content-Type और content-type एक ही header हैं, और HTTP/2 व HTTP/3 हर name lowercase में भेजते हैं, इसलिए DevTools अक्सर content-type दिखाता है। Value case-sensitive है या नहीं, यह header पर निर्भर है: application/json जैसे media types नहीं होते; access tokens और cookie values होते हैं।

एक header एक से ज़्यादा बार आ सकता है। Accept जैसे list वाले headers में recipient lines को एक comma-separated line में जोड़ सकता है; RFC 9110 Set-Cookie को exception बताता है: हर line में एक cookie, कभी merge नहीं। Headers groups में बँटते हैं:

  • Request headers client और उसकी ज़रूरत बताते हैं: Host (HTTP/1.1 में ज़रूरी), User-Agent, Accept, Accept-Language, Authorization, Cookie।
  • Response headers जवाब का वर्णन करते हैं: Set-Cookie, Location, WWW-Authenticate, Retry-After, Server।
  • Content headers किसी भी दिशा में body का वर्णन करते हैं: Content-Type, Content-Length, Content-Encoding। Cache-Control भी दोनों दिशाओं में चलता है, हर दिशा में अलग अर्थ के साथ।

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

पाँच headers जो लगभग हर test में मिलते हैं

नीचे का exchange एक test shop में customer की पसंदीदा भाषा save करता है। पाँचों headers में से हर एक अलग सवाल का जवाब देता है।

भाषा की पसंद save करते समय: Content-Type दोनों दिशाओं में body का label है, Accept और Authorization request के साथ जाते हैं, और response Cache-Control: no-store व एक Set-Cookie के साथ लौटता है।

Request

PUT /api/v1/me/preferences HTTP/1.1
Host: test.shop.example.com
भाग 1:Content-Type: application/json
भाग 2:Accept: application/json
भाग 3:Authorization: Bearer eyJhbGciOi...
Content-Length: 18

{"language": "ar"}

Response

HTTP/1.1 200 OK
भाग 1:Content-Type: application/json; charset=utf-8
Content-Length: 55
भाग 4:Cache-Control: no-store
भाग 5:Set-Cookie: lang=ar; Path=/; Max-Age=31536000; Secure

{"language": "ar", "updatedAt": "2026-10-01T09:30:00Z"}
  1. 1Content-Typeहर message की body का label: जाते समय JSON, लौटते समय charset के साथ JSON। इसे bytes से match करना चाहिए; server जो format स्वीकार न करे, उस पर 415।request और response
  2. 2AcceptClient जवाब में क्या लेगा। कुछ match न हो तो 406, या server का default format, जैसा contract कहे।request
  3. 3AuthorizationScheme और credentials। न हों या invalid हों तो WWW-Authenticate के साथ 401। हर report में value mask करें।request
  4. 4Cache-Controlno-store: कोई cache copy नहीं रख सकता, personal data के लिए सही नियम। no-cache तो revalidation के साथ store करने देता है।response
  5. 5Set-Cookielang=ar एक साल के लिए store करता है; browser उसे Cookie में वापस भेजता है। Secure उसे unencrypted HTTP से दूर रखता है।response
  • Content-Type: इस message की body का media type, charset जैसे optional parameters के साथ। Receiver इसी से body parse करता है, इसलिए इसे असली bytes से match करना चाहिए; जो server format स्वीकार नहीं करता, उसे 415 Unsupported Media Type लौटाना चाहिए।
  • Accept: वे media types जो client लेगा, चाहें तो weights (q=0.8) के साथ। कोई उपलब्ध न हो, तो RFC 9110 server को 406 Not Acceptable लौटाने या header अनदेखा करके अपना default भेजने देता है; contract में लिखा होना चाहिए कि कौन-सा।
  • Authorization: एक scheme और credentials, जैसे Bearer <token> (sign-in पर मिला token) या Basic <credentials> (colon से जुड़े user name और password)। Credentials न हों या invalid हों तो 401 Unauthorized मिलता है, और RFC 9110 के अनुसार उसमें WWW-Authenticate header ज़रूरी है। Basic credentials Base64-encoded होते हैं, encrypted नहीं: जो देखे, पढ़ सकता है।
  • Cache-Control: caches के लिए directives (RFC 9111)। max-age=600: 600 seconds तक fresh, इसलिए cache इसे server से पूछे बिना reuse कर सकता है। no-cache: store हो सकता है, पर हर reuse से पहले revalidate होना चाहिए। no-store: store नहीं होना चाहिए। private: सिर्फ़ private cache, जैसे browser, store कर सकता है। HTTP caching वाला lesson इसे गहराई से लेता है।
  • Set-Cookie: browser से cookie store करने को कहता है, जिसे browser बाद की matching requests के Cookie header में लौटाता है। Max-Age, Secure और HttpOnly जैसे attributes तय करते हैं कि cookie कितनी देर रहे, कहाँ जाए और कौन उसे पढ़ सके; cookies और sessions वाला lesson इन्हें टेस्ट करता है।
पाठ संस्करण
PUT /api/v1/me/preferences HTTP/1.1
Host: test.shop.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 18

{"language": "ar"}

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 55
Cache-Control: no-store
Set-Cookie: lang=ar; Path=/; Max-Age=31536000; Secure

{"language": "ar", "updatedAt": "2026-10-01T09:30:00Z"}

आज़माएँ: Content-Type वैलिडेटर आज़माएँ: HTTP हेडर बिल्डर

Headers में क्या टेस्ट करें

Headers contract का हिस्सा हैं, इसलिए वे test basis और expected results में आते हैं।

  • Response checks: documented Content-Type, और body सच में उसी format में; contract वादा करे तो 201 Created के बाद Location; personal data और credentials पर Cache-Control: no-store; हर Set-Cookie पर तय attributes।
  • Request tests, एक बार में एक बदलाव: Authorization के बिना या expired token के साथ (WWW-Authenticate के साथ 401); JSON को Content-Type: text/plain से भेजना (415, या documented 400); Accept में ऐसा format जो API नहीं देता (406, या documented default)। Duplicate header या बहुत बड़ी value पर 400 या 431 Request Header Fields Too Large आ सकता है; 500 या crash defect है।
  • Leaks और security headers: Server: Apache/2.4.41 (Ubuntu) या X-Powered-By: PHP/7.4.3 attackers को बताते हैं कि किन versions की कमज़ोरियाँ खोजें; OWASP HTTP Headers Cheat Sheet X-Powered-By को हटाने, और Server को हटाने या कुछ न बताने वाली value देने की सलाह देती है। तय security headers, जैसे Strict-Transport-Security (जो browsers से site को सिर्फ़ HTTPS पर खोलने को कहता है), सिर्फ़ उन sites पर जाँचें जो आपकी हैं या जिन्हें टेस्ट करने की लिखित अनुमति है।

आज़माएँ: API हेडर वैलिडेटर आज़माएँ: सिक्योरिटी हेडर एनालाइज़र

Worked example: एक profile response

एक tester test environment पर एक shop के web app का profile endpoint जाँचता है। Status 200 है और body सही, इसलिए UI test pass होता है, फिर भी raw exchange में headers के चार defects हैं, और हर एक की अलग report बनती है, क्योंकि हर एक अलग जगह ठीक हो सकता है: application code, session settings या web server configuration।

  • JSON पर Content-Type: text/html: header को मानने वाले clients उसे JSON की तरह parse नहीं कर पाते, और browser उसे HTML की तरह दिखाता है, जो किसी field में user input आते ही script injection का risk है। Expected: application/json।
  • Personal data पर Cache-Control: public, max-age=3600: CDN या company proxy जैसा shared cache profile को एक घंटे तक रखकर किसी और को दे सकता है। Expected: no-store।
  • Set-Cookie session cookie को Secure और HttpOnly के बिना फिर से set करता है: वह unencrypted HTTP पर जा सकती है और page scripts उसे पढ़ सकती हैं। Expected: session cookie के तय attributes।
  • Server और X-Powered-By exact versions बताते हैं। Expected: हटाए जाएँ या generic हों।
  • Fix के बाद confirmation testing request दोहराती है और headers compare करती है, और चारों checks API regression suite में जुड़ते हैं।
GET /api/v1/me HTTP/1.1
Host: test.shop.example.com
Accept: application/json
Cookie: sid=9f2c41d7e0

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 62
Cache-Control: public, max-age=3600
Set-Cookie: sid=9f2c41d7e0; Path=/
Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.4.3

{"id": 58, "name": "Test User", "email": "user58@example.com"}

आज़माएँ: HTTP हेडर पार्सर आज़माएँ: कैश हेडर एनालाइज़र आज़माएँ: कुकी एनालाइज़र

आम गलतियाँ

  • Status code और body जाँचना, पर response headers कभी नहीं।
  • Automated tests में header names case-sensitive तरीके से compare करना, जिससे HTTP/2 पर जाते ही suite बिना किसी defect के टूट जाता है।
  • no-cache को "cache मत करो" समझना: यह revalidation के साथ store करने देता है। Store करने से रोकने वाला directive no-store है।
  • यह मान लेना कि request में सिर्फ़ आपके टाइप किए headers हैं: browsers और API clients User-Agent, Cookie और दूसरे headers जोड़ते हैं।
  • असली Authorization या Cookie values को reports या screenshots में paste करना: जो इन्हें copy करे, वह उस user की तरह काम कर सकता है। इन्हें mask करें।

QA का नज़रिया

Headers review, testing और fix के बाद, तीनों मौकों पर सामने आते हैं। Contract review में पूछें कि हर endpoint कौन-से headers माँगता और लौटाता है, unsupported Accept या Content-Type पर क्या जवाब आता है, और हर response कितनी देर cache हो सकता है; चुप contract ही आपकी पहली finding है। Testing के दौरान हर API result के साथ raw request और response रखें।

Fix हुए हर header defect को regression check में बदलें। DevOps से पूछें कि web server, gateway या CDN क्या जोड़ते या हटाते हैं, क्योंकि कोई header code में सही होकर रास्ते में बदल सकता है। हर evidence में credentials mask करें।

अभ्यास

Address बदलने वाली request के headers review करें

आपका काम

एक test shop का mobile app किसी order का delivery address बदलता है। Contract कहता है: bodies सिर्फ़ JSON; unsupported Content-Type पर 415 और unsupported Accept पर 406; authentication HTTPS पर Basic से; personal data वाले responses में Cache-Control: no-store।

नीचे सिर्फ़ headers review करें; response body सही है। हर problem को expected value और risk के साथ लिखें, फिर तीन negative tests लिखें, हर एक में एक request header बदलकर। Mutqan Base64 Decoder Authorization value को decode करता है।

सामग्री
PATCH /api/v1/orders/88121/address HTTP/1.1
Host: test.shop.example.com
Content-Type: text/plain
Accept: application/xml
Authorization: Basic dGVzdGVyMTpUZXN0LVBhc3MtMTIz
Content-Length: 41

{"city": "Jeddah", "postalCode": "23436"}

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 59
Cache-Control: no-cache
Set-Cookie: lastCity=Jeddah; Path=/; Max-Age=31536000
Server: nginx/1.18.0

{"orderId": 88121, "city": "Jeddah", "postalCode": "23436"}
चरण
  1. Headers को request और response में बाँटें।
  2. हर Content-Type को उसकी body और contract से मिलाएँ; Accept जाँचें।
  3. Credentials decode करें; caching, cookie और information headers जाँचें।
  4. तीन negative tests लिखें, हर एक में एक request header।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

Request headers: Host, Content-Type, Accept, Authorization, Content-Length। Response headers: Content-Type, Content-Length, Cache-Control, Set-Cookie, Server। इनमें Host, दोनों Content-Length values (41 और 59 bytes) और response का Content-Type सही हैं।

JSON पर Content-Type: text/plain: app गलत label भेजता है (expected application/json), और server ने 415 लौटाने की बजाय उसे स्वीकार कर लिया। Risk: जैसे ही server contract लागू करेगा, app टूट जाएगा। ये दो defects हैं, इसलिए दो reports।

Accept: application/xml पर 200 के साथ JSON मिला। RFC 9110 दोनों व्यवहार allow करता है, पर इस contract ने 406 चुना है, इसलिए 200 defect है। Risk: XML माँगने वाला client जवाब नहीं पढ़ पाता। यह भी पूछें कि app XML माँगता ही क्यों है।

Basic value decode होकर tester1:Test-Pass-123 बनती है: Base64 encryption नहीं है। Risk: request देखने वाला कोई भी tester1 बनकर sign in कर सकता है। इसे सिर्फ़ HTTPS पर भेजें, हर evidence में mask करें, और shared report में दिखा password बदलें।

Cache-Control: no-cache no-store वाला नियम तोड़ता है: reuse से पहले revalidate करे तो cache address रख सकता है। Expected: no-store।

Set-Cookie: lastCity=Jeddah address का हिस्सा एक साल तक Secure के बिना रखता है, इसलिए वह unencrypted HTTP पर जा सकता है: पूछें कि यह ज़रूरी है या नहीं, और हो तो Secure जोड़ें। Server: nginx/1.18.0 वह version बताता है जिसकी कमज़ोरियाँ attackers खोजेंगे। Expected: हटाया जाए या generic हो।

Negative tests, हर एक valid request (Content-Type और Accept में application/json, valid credentials) से शुरू होकर एक header बदलता है: (1) Authorization के बिना → Basic वाले WWW-Authenticate के साथ 401, address नहीं बदलता; (2) वही JSON body Content-Type: application/xml के साथ → 415, address नहीं बदलता; (3) Accept: image/png → 406, 500 कभी नहीं।

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

क्या header names case-sensitive होते हैं?

नहीं। RFC 9110 field names को case-insensitive परिभाषित करता है, और HTTP/2 व HTTP/3 उन्हें lowercase में भेजते हैं। Values अलग बात है: कुछ case-insensitive हैं, जैसे media types और charset parameter (UTF-8 बराबर utf-8), और कुछ नहीं, जैसे access tokens, cookie values और, जब तक उनका documentation कुछ और न कहे, custom values।

Accept और Content-Type में क्या फ़र्क है?

Content-Type इसी message में मौजूद body का वर्णन करता है; Accept बताता है कि client response में क्या चाहता है। JSON भेजने और JSON वापस चाहने वाली request में दोनों होते हैं: Content-Type: application/json और Accept: application/json। GET request में आम तौर पर body नहीं होती, इसलिए उसमें Accept हो सकता है, पर Content-Type की कोई वजह नहीं।

Request के headers कहाँ देखूँ?

Browser में DevTools खोलें, Network panel में request चुनें और उसका Headers tab खोलें, जो request और response headers अलग-अलग दिखाता है। API client उन्हें response के एक tab में दिखाता है, curl -i response headers print करता है और curl -v दोनों दिशाएँ। Mutqan Request Header Inspector दिखाता है कि आपका browser असल में क्या भेजता है।

संदर्भ

  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
  • RFC 9111: HTTP CachingIETF · 2022Cache-Control, Expires, ETag और वैलिडेटर कैसे तय करते हैं कि रिस्पॉन्स स्टोर और पुन: उपयोग हो सकता है या नहीं।
  • OWASP Cheat Sheet Series: HTTP HeadersOWASP Foundationकौन-से सुरक्षा हेडर भेजें (HSTS, CSP, X-Content-Type-Options, फ़्रेम सुरक्षा) और कौन-से हटाएँ (Server, X-Powered-By)।
  • HTTP headers — MDNMDN Web Docs (Mozilla)रिक्वेस्ट और रिस्पॉन्स हेडर का संदर्भ: सिंटैक्स, डायरेक्टिव और ब्राउज़र सपोर्ट।
टूल्स

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

HTTP हेडर पार्सर

कच्चे HTTP रिक्वेस्ट/रिस्पॉन्स हेडर को व्याख्या सहित एक संरचित तालिका में बदलें।

वेब

API हेडर वैलिडेटर

API रिस्पॉन्स हेडर की शुद्धता, सुरक्षा और caching की सर्वोत्तम प्रथाओं के लिए जाँच करें।

API टेस्टिंग

Content-Type वैलिडेटर

Content-Type हेडर जाँचें और देखें कि रिस्पॉन्स बॉडी सचमुच घोषित मीडिया टाइप से मेल खाती है या नहीं।

वेब

कैश हेडर एनालाइज़र

Cache-Control, Expires, ETag, Last-Modified, Vary और Age हेडर जाँचें और समझें कि ब्राउज़र तथा CDN रिस्पॉन्स को कैसे कैश करेंगे।

वैलिडेशन

Base64 डिकोडर

Base64 या Base64url स्ट्रिंग को टेक्स्ट में डिकोड करें, पैडिंग अपने आप ठीक होने के साथ।

एन्कोडिंग

और गहराई से

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

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