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

HTTP और HTTPS

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

HTTP (Hypertext Transfer Protocol) वे नियम हैं जिनसे web पर client और server messages का आदान-प्रदान करते हैं। Client एक request भेजता है, जैसे GET /orders/1042, और server response लौटाता है, जैसे 200 OK के साथ order का JSON। जो भी page, image, API call या form submission आप टेस्ट करते हैं, वह ऐसी ही request और response के रूप में चलता है।

HTTPS वही HTTP है जो TLS connection के अंदर भेजा जाता है। TLS messages को encrypt करता है, रास्ते में उनमें हुआ कोई भी बदलाव पकड़ लेता है, और server के certificate से साबित करता है कि client सच में असली shop.example.com से बात कर रहा है। "ब्राउज़र कैसे काम करता है" lesson ने दिखाया था कि page load में यह कहाँ होता है; यह lesson बताता है कि हर protocol क्या वादा करता है और क्या नहीं।

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

कई failures जो application के bugs लगती हैं, असल में HTTP या HTTPS का व्यवहार होती हैं: users का अचानक log out हो जाना क्योंकि उनकी अगली request किसी दूसरे server पर पहुँची, mobile app का connect न कर पाना जबकि browser कर लेता है, certificate expire होने वाले दिन checkout का रुक जाना, या card details plain HTTP पर भेजने वाला form। जो tester यह model समझता है, वह कारण और उसकी owner team का नाम बता सकता है।

Users के लिए HTTPS passwords, session cookies और personal data को network path पर मौजूद किसी भी व्यक्ति से बचाता है, जैसे public Wi-Fi चलाने वाला। Testers के लिए HTTP वह layer है जिस पर हर web और API test टिका है।

Client और server: request–response का लेन-देन

HTTP में बात हमेशा client शुरू करता है। वह request भेजता है: GET या POST जैसा method, /orders/1042 जैसा target, header fields और कभी-कभी body। Server requests का इंतज़ार करता है और हर request का जवाब response से देता है: status code, header fields और आम तौर पर body।

Client और server भूमिकाएँ हैं, machines नहीं। Browser, mobile app, curl और आपके automated tests, सब clients हैं; checkout service भी, जब वह payment API को call करती है, हालाँकि अपने users के लिए वह server है। दोनों के बीच अक्सर intermediaries होते हैं — proxies, load balancers, API gateways और CDNs (content delivery networks) — जो request आगे भेजते हैं या cache से ही जवाब दे देते हैं। RFC 9110 resource के मालिक server को origin server कहता है, और जो response आप देखते हैं वह हमेशा उसी ने नहीं बनाया होता।

GET /orders/1042 HTTP/1.1
Host: shop.example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 1042, "status": "shipped", "items": 3}

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

Stateless: हर request अपने आप में पूरी

RFC 9110 HTTP को stateless परिभाषित करता है: हर request को अलग से समझा जा सकता है, और protocol में ऐसा कुछ नहीं जो आपकी तीसरी request को पहली से जोड़े। इसी वजह से कोई site load balancer के पीछे कई servers पर requests बाँट पाती है।

जिन applications को continuity चाहिए — signed-in user, cart, कई steps वाला form — वे इसे HTTP के ऊपर बनाती हैं: client हर request के साथ एक identifier भेजता है, आम तौर पर cookie या Authorization header में, और server अपने storage में उससे मेल खाती state ढूँढता है। Tester के लिए इससे ठोस test ideas निकलते हैं:

  • Refresh, share किया गया link और दूसरा tab, हर एक नई request भेजता है, जिसे पिछले steps से सिर्फ़ वही जोड़ता है जो वह साथ ले जाती है, जैसे cookie। Checkout का step 3 सीधे private window में खोलें: application को आपको sign-in पर भेजना चाहिए या step दोबारा बनाना चाहिए, crash होना या किसी दूसरे user का data दिखाना नहीं।
  • अगर कोई server instance session data अपनी memory में रखता है, तो अगली request ऐसे instance पर पहुँच सकती है जिसने आपको कभी देखा ही नहीं, और users का session या cart अचानक गायब हो जाता है। Flow कई बार दोहराएँ और पूछें कि sessions कहाँ store होते हैं।
  • Server को हर request पर जाँचना चाहिए कि उसे कौन भेज रहा है और उस user को क्या करने की अनुमति है; वह किसी पिछली request के भरोसे नहीं रह सकता। अपने test environment में, अपने test account की कोई request उसकी cookie या token के बिना दोबारा भेजें: server को उसे reject करना चाहिए।
  • Server double click और दो असली orders में फ़र्क नहीं कर सकता। Form जल्दी-जल्दी दो बार submit करें और गिनें कि कितने orders बने; duplicates रोकना application का काम है, HTTP का नहीं।

HTTPS: TLS के अंदर वही HTTP

https:// address का मतलब है कि HTTP messages TLS (Transport Layer Security) connection के अंदर चलते हैं, default रूप से port 80 की जगह port 443 पर। Messages नहीं बदलते; TLS तीन guarantees जोड़ता है: confidentiality (रास्ते में कोई उन्हें पढ़ नहीं सकता), integrity (बदले गए bytes पकड़े जाते हैं और connection fail हो जाता है) और server authentication (server सच में वही host है जो address में है)। Client भी अपने certificate से अपनी पहचान साबित कर सकता है, जो कुछ service-to-service APIs में ज़रूरी होता है; इसे mutual TLS कहते हैं।

पहले HTTP byte से पहले दोनों पक्ष TLS handshake करते हैं। यह एक key pair पर टिका है: public key, जिसे कोई भी देख सकता है, और private key, जो सिर्फ़ server के पास रहती है। Private key से sign किया गया data public key से जाँचा जा सकता है, इसलिए सही signature साबित करता है कि sign करने वाले के पास private key है। TLS 1.3 में handshake में एक round trip लगता है: client keys प्रस्तावित करता है और बताता है कि उसे कौन-सा host चाहिए; server अपनी पसंद, अपना certificate और एक signature भेजता है जो साबित करता है कि certificate की private key उसके पास है; दोनों एक जैसी session keys निकालते हैं, और तभी request encrypted होकर भेजी जाती है।

Certificate एक public key को host names से जोड़ता है, जो उसके Subject Alternative Name field में लिखे होते हैं, और उस पर certificate authority (CA) का signature होता है। Server अपना certificate और वे intermediate certificates भेजता है जो उसे ऐसे root CA से जोड़ते हैं जिस पर client पहले से भरोसा करता है, क्योंकि वह root operating system या browser में stored है। Client ये चीज़ें जाँचता है:

  • Name: host certificate में listed होना चाहिए। Wildcard *.example.com shop.example.com को cover करता है, लेकिन न example.com को और न api.shop.example.com को।
  • Dates: certificate अपनी validity period के अंदर होना चाहिए। Expired certificate सभी clients को एक साथ रोक देता है।
  • Chain: trusted root तक हर कड़ी मौजूद होनी चाहिए। Intermediate का गायब होना एक classic defect है: desktop browser यह कमी ख़ुद भर सकता है, जबकि apps और scripts fail हो जाते हैं।
  • जो दिखता रहता है: रास्ते में observer को IP address, messages का timing और size, और आम तौर पर host name दिखता है, लेकिन path, query, headers, cookies या body नहीं।
  • जो HTTPS cover नहीं करता: यह सिर्फ़ रास्ते में data बचाता है। Server सब कुछ देखता है, और broken access control या injection flaws encrypted connection पर भी उतनी ही आसानी से काम करते हैं।
Plain HTTP request को रास्ते में हर किसी के लिए पढ़ने लायक भेजता है; HTTPS पहले TLS handshake करता है जिसमें server certificate से अपनी पहचान साबित करता है, फिर वही request encrypted भेजता है। वैचारिक मॉडल

  • Plain HTTP, port 80

    • Browser client
    • Server shop.example.com
    1. 1 Browser से Server तक: TCP connection खोलता है
    2. 2 Browser से Server तक: Request plain text में भेजता है Path, headers, cookies और body रास्ते में पढ़े जा सकते हैं GET /account HTTP/1.1
    3. 3 Server से Browser तक: Response plain text में भेजता है जवाब रास्ते में कोई भी इसे बदल भी सकता है HTTP/1.1 200 OK

    परिणाम: Wi-Fi operator, proxy या रास्ते का कोई भी router हर byte पढ़ और बदल सकता है। फ़ेल

  • HTTPS: TLS 1.3, port 443

    • Browser client
    • Server shop.example.com
    1. 1 Browser से Server तक: TCP connection खोलता है
    2. 2 Browser से Server तक: Keys प्रस्तावित करता है और host बताता है Supported TLS versions, key share और host name ClientHello
    3. 3 Server से Browser तक: अपनी पसंद और अपना certificate भेजता है जवाब साथ में signature, जो साबित करता है कि private key उसके पास है ServerHello … Certificate … Finished
    4. 4 Browser आंतरिक रूप से: Certificate जाँचता है Name host को cover करता है, dates valid हैं, chain trusted root पर ख़त्म होती है पास
    5. 5 Browser से Server तक: Handshake पूरा करता है अब दोनों के पास एक जैसी session keys हैं Finished
    6. 6 Browser से Server तक: वही request encrypted भेजता है Network पर: न पढ़े जा सकने वाले TLS records GET /account HTTP/1.1
    7. 7 Server से Browser तक: Response encrypted भेजता है जवाब HTTP/1.1 200 OK

    परिणाम: Observer को IP address, timing, sizes और आम तौर पर host name दिखता है, लेकिन path, headers, cookies या body नहीं। पास

सरल किया गया TLS 1.3 handshake। TLS 1.2 में request से पहले एक round trip और लगता है; HTTP/3 में handshake UDP पर QUIC के अंदर होता है, अलग TCP connection के बिना।

HTTP versions संक्षेप में

HTTP के सभी मौजूदा versions RFC 9110 में परिभाषित semantics साझा करते हैं: methods, status codes और header fields का अर्थ हर जगह एक है, यानी 404 हर version में 404 ही है। बदलता यह है कि messages ले जाए कैसे जाते हैं:

  • HTTP/1.1: plain-text messages। एक connection कई requests के लिए दोबारा इस्तेमाल होता है, लेकिन practice में एक बार में एक ही request ले जाता है, इसलिए browsers हर host के लिए कई connections खोलते हैं। HTTP/1.0, जो default रूप से हर request के लिए नया connection खोलता था, आज कम ही दिखता है।
  • HTTP/2: वही messages binary frames में, कई requests एक ही connection पर एक साथ (multiplexing) और compressed headers के साथ। Header names हमेशा lowercase होते हैं, और browsers HTTP/2 सिर्फ़ HTTPS पर इस्तेमाल करते हैं।
  • HTTP/3: वही model QUIC पर, जो UDP पर चलने वाला transport है और जिसमें TLS 1.3 built-in है, इसलिए कोई packet खोने पर सिर्फ़ उसी request में देरी होती है जिसका वह हिस्सा है। Browsers अक्सर Alt-Svc response header से जानते हैं कि server इसे support करता है, और network UDP block करे तो HTTP/2 पर लौट आते हैं।
  • Testing में: DevTools के Network panel में Protocol column जोड़ें; Chrome हर request के लिए http/1.1, h2 या h3 दिखाता है। व्यवहार version पर निर्भर नहीं होना चाहिए; अगर हो, तो proxy, CDN setting या header names को case-sensitive तरीके से compare करने वाले code पर शक करें।

Worked example: release से पहले HTTPS check

एक shop नया sign-in page और अपने mobile app के लिए एक API release करने वाली है। Staging पर tester https://staging.shop.example.com और https://api-staging.shop.example.com जाँचता है और हर नतीजा दर्ज करता है:

  • http://staging.shop.example.com/login 301 और Location: https://staging.shop.example.com/login के साथ जवाब देता है। Pass: plain HTTP सिर्फ़ redirect करता है।
  • HTTPS responses में Strict-Transport-Security: max-age=31536000 है। यह HSTS header (RFC 6797) browser से कहता है कि इस host के लिए एक साल तक सिर्फ़ HTTPS इस्तेमाल करे; plain HTTP पर आए इस header को browsers ignore करते हैं। Pass।
  • Certificate *.shop.example.com को cover करता है, उसकी chain trusted root तक जाती है और वह 41 दिन में expire होगा। यह defect नहीं है, लेकिन tester पूछता है कि इसे कौन renew करता है और team को चेतावनी कैसे मिलती है।
  • Console blocked mixed content दिखाता है: page chat widget का script http:// address से load करता है, और browsers HTTPS pages पर insecure scripts block करते हैं, इसलिए chat button गायब है। Defect।
  • App API तक नहीं पहुँच पाता, हालाँकि वही URL desktop browser में बिना warning खुलता है। curl fail होता है, और openssl s_client -connect api-staging.shop.example.com:443 -showcerts सिर्फ़ server का अपना certificate दिखाता है: intermediate गायब है। Defect, इन सबूतों के साथ report किया गया:
Title:    api-staging अधूरी TLS chain भेजता है; app और curl उसे reject करते हैं
URL:      https://api-staging.shop.example.com/v1/health
Clients:  Android app 3.8.0 (staging build); Ubuntu पर curl
curl:     curl: (60) SSL certificate problem: unable to get local issuer certificate
Android:  SSLHandshakeException: Trust anchor for certification path not found
Browser:  वही URL desktop Chrome में बिना warning खुलता है
Chain:    openssl s_client -showcerts 1 certificate दिखाता है (server का अपना)
Expected: server अपना certificate और intermediate भेजे; clients certificate
          verification चालू रखकर connect करें
Note:     curl -k या app में trust-all setting से इसका workaround न करें

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

आम गलतियाँ

  • Padlock को "यह site secure है" समझ लेना। HTTPS रास्ते में data बचाता है; access control, input validation या server data के साथ क्या करता है, इसके बारे में कुछ नहीं कहता।
  • Tests चलाने के लिए certificate verification बंद करना (curl -k, verify=False, trust-all client) और फिर बंद ही छोड़ देना। तब tests वे certificate defects नहीं पकड़ सकते जिनसे users टकराएँगे, और यह setting किसी release में पहुँच सकती है।
  • HTTPS सिर्फ़ desktop browser में जाँचना। Browsers गायब intermediate certificate ख़ुद भर सकते हैं; mobile apps, scripts और partner systems आम तौर पर नहीं।
  • किसी flow को सिर्फ़ क्रम से click करते हुए टेस्ट करना। Refresh, deep links, दूसरा tab और दोबारा भेजी गई request ही वे जगहें हैं जहाँ state defects दिखते हैं।
  • सिर्फ़ दिया गया https:// address, और सिर्फ़ आज के दिन, जाँचना। Users http:// से और www के साथ या बिना वाले address से भी आते हैं, और हर एक को HTTPS site पर पहुँचना चाहिए; आज valid certificate अपनी expiry date पर सभी clients को रोक देगा।

QA का नज़रिया

हर नए environment पर, और domains, certificates, load balancers, CDNs या proxies को छूने वाली हर release से पहले, HTTP और HTTPS checks चलाएँ। इनके owners कम ही feature developers होते हैं: certificates, redirects और HSTS आम तौर पर platform या DevOps team के पास होते हैं, और session storage back-end developers के पास। HTTP-से-HTTPS redirect और certificate की expiry date को smoke test में जोड़ें, ताकि हर deployment के बाद दोनों जाँचे जाएँ।

Report में scheme और port समेत पूरा URL, client और उसका version (browser, app build, curl), protocol (h2, h3), रास्ते में कोई VPN या proxy, समय, और certificates के मामले में host names, issuer chain और expiry date दर्ज करें। जल्दी पूछें: certificates कौन renew करता है और चेतावनी किसे मिलती है? क्या सभी http:// addresses redirect होते हैं? कई server instances चलने पर session state कहाँ रखी जाती है? क्या हमारे test clients certificates वैसे ही verify करते हैं जैसे असली clients?

अभ्यास

Payment page का HTTP और HTTPS setup review करें

आपका काम

Release से पहले आप एक payment page के staging environment का review करते हैं और नीचे दी छह observations इकट्ठा करते हैं। हर एक के लिए तय करें कि वह defect है, उठाने लायक risk है या expected behaviour, उसके पीछे इस lesson का कौन-सा idea है, और आपका अगला कदम क्या होगा।

सामग्री
Payment page: https://pay-staging.example.com/checkout

1. http://pay-staging.example.com/ 200 लौटाता है और home page दिखाता है।
2. Certificate: SAN *.example.com और example.com, chain trusted root पर ख़त्म होती है,
   18 दिन में expire होगा।
3. /checkout पर card form http://pay-staging.example.com/api/charge पर post करता है।
4. 3 में से step 2 पर refresh के बाद लगभग आधी बार order summary खाली दिखता है।
   Load balancer के पीछे दो application servers चलते हैं।
5. DevTools Protocol column: पहली request के लिए h2, बाद की ज़्यादातर के लिए h3।
6. Automated API test suite certificate verification बंद रखकर चलता है।
चरण
  1. पहचानें कि हर observation HTTP या HTTPS के किस नियम से जुड़ी है।
  2. उसे classify करें: defect, risk या expected behaviour।
  3. Defects और risks के लिए अगला कदम लिखें: सबूत के साथ bug report, या एक सवाल और वह व्यक्ति जिससे आप पूछेंगे।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

1. Defect (HTTPS): plain HTTP redirect करने की जगह site serve करता है, इसलिए address टाइप करने वाला हर व्यक्ति बिना encryption के शुरू करता है। Expected: उसी path पर https:// की ओर 301 या 308। Request और response के साथ report करें।

2. Risk (certificates): wildcard pay-staging.example.com को cover करता है और chain पूरी है, लेकिन 18 दिन में होने वाली expiry के लिए एक owner चाहिए। Platform team से पूछें कि renewal automatic है या नहीं और alert किसे जाता है।

3. Defect, Critical severity (HTTPS): card details page से plain text में निकलेंगी। Browsers ऐसे submission पर warning देते हैं या उसे block करते हैं, लेकिन form को https:// पर ही post करना चाहिए। तुरंत report करें।

4. Defect (stateless): summary शायद एक server की memory में रखा है, और लगभग आधे refreshes दूसरे server पर पहुँचते हैं। 20 refreshes में से कितने fail हुए, समय के साथ दर्ज करें, और back-end developers से पूछें कि session state कहाँ store होती है।

5. Expected behaviour (versions): browsers अक्सर HTTP/2 से शुरू करके Alt-Svc header के बाद HTTP/3 पर चले जाते हैं। Report तभी करें जब दोनों में व्यवहार अलग हो।

6. Test setup में risk (certificates): suite expired certificate या टूटी chain नहीं पकड़ सकता। कहें कि test clients staging CA पर भरोसा करें और verification फिर से चालू किया जाए।

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

क्या HTTPS, HTTP से अलग protocol है?

नहीं। HTTPS, TLS के अंदर ले जाया गया HTTP है: वही methods, headers और status codes, https scheme और default port 443 के साथ। HTTP messages के बारे में आप जो भी सीखते हैं वह दोनों पर लागू होता है; HTTPS उनके चारों ओर encryption, integrity और server authentication जोड़ता है।

SSL और TLS में क्या फ़र्क है?

SSL पुराना protocol है जिसकी जगह TLS ने ली। SSL के सभी versions, और TLS 1.0 व 1.1 भी, असुरक्षित होने के कारण deprecated हैं; आज के server को सिर्फ़ TLS 1.2 और 1.3 स्वीकार करने चाहिए। यह नाम "SSL certificate" जैसे आम शब्दों में बचा है, जिसका मतलब वही certificate है जो TLS के साथ इस्तेमाल होता है।

क्या मुझे हर HTTP version टेस्ट करना होगा?

आम तौर पर नहीं। Semantics एक जैसे हैं, इसलिए व्यवहार एक बार टेस्ट करें और इस्तेमाल हुआ protocol दर्ज करें। जहाँ clients या networks अलग हों वहाँ targeted checks जोड़ें, जैसे UDP block करने वाला office network, जहाँ browsers HTTP/3 से HTTP/2 पर लौट आते हैं।

हमारा staging server self-signed certificate इस्तेमाल करता है। टेस्ट कैसे करें?

Verification बंद करने की बजाय test devices और clients को उस certificate पर, या उसे जारी करने वाले internal CA पर, भरोसा करवाएँ। याद रखें कि इससे production chain टेस्ट नहीं होती: public certificate, उसके intermediates और उसकी expiry उस environment में जाँचें जो उन्हें इस्तेमाल करता है।

संदर्भ

  • RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
  • RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018TLS 1.3 हैंडशेक और रिकॉर्ड प्रोटोकॉल जो HTTPS ट्रैफ़िक की रक्षा करते हैं।
  • RFC 6797: HTTP Strict Transport Security (HSTS)IETF · 2012Strict-Transport-Security हेडर जो ब्राउज़र को किसी होस्ट के लिए केवल HTTPS इस्तेमाल करने को कहता है।
  • Overview of HTTP — MDNMDN Web Docs (Mozilla)HTTP कैसे काम करता है: एक stateless client–server प्रोटोकॉल, जिसमें client request भेजता है और server response संदेश से जवाब देता है।
टूल्स

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

URL पार्सर

किसी URL को protocol, host, port, path, क्वेरी पैरामीटर, fragment और क्रेडेंशियल में तोड़ें।

वेब

रीडायरेक्ट चेकर

रीडायरेक्ट चेन (301/302/307/308) ट्रेस करें और हर हॉप, स्टेटस तथा अंतिम URL देखें।

वेब

सिक्योरिटी हेडर एनालाइज़र

पेस्ट किए गए हेडर या किसी सार्वजनिक URL से HTTP सुरक्षा हेडर (CSP, HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy, COOP/CORP) को ग्रेड दें।

वैलिडेशन

API एंडपॉइंट टेस्टर

तुरंत जाँचें कि कोई API endpoint पहुँच में है या नहीं: स्टेटस, रिस्पॉन्स टाइम, साइज़, content type और TLS।

API टेस्टिंग

और गहराई से

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

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